Question regarding "setSectorSize"

[jumbi77]

Hello guys, I have some Exos 28TB drives and set the sector size to 4kn:

SeaChest_Format -d /dev/sg<x> --setSectorSize 4096 --poll

After a few minutes, the command executes successfully. It also prints that the drive may not be go to sleep state right away because it may run some background activities.

I am interested in what those background activities are:

1a) Does the drive reformat every single sector in the background? If yes, does it operate the activity for like 30-40 hrs? (approx. same duration like --longDST)

1b) I shut down the system a few hours after the successful command, was this okay? And if 1a) is true, does the drive finish the complete reformat after reboot again?

1c) Can I see/print the progress of the background activity? How do I know when the reformat to 4kn is really 100% finished?

1d) After that, I want to run SeaChest_SMART <..> --longDST to check every sector or should I run SeaChest_GenericTests <..> --longGeneric?

Much thanks!

[jumbi77]

Politely ask @vonericsen if you may know the answer to my questions above? In any case much thanks in advance!

[vonericsen]

Hi @jumbi77,

Sorry I did not see this question until now!
I did write up a bit about this on here under the About Fast Format Background Activity

A short answer for your questions:
1a) It can take longer depending on what other things the drive receives while it runs. While a longDST is run in "background" mode as well, it has a higher priority than this automatic background activity. Both of these will "pause" when the drive receives other requests to service those, then continue running. So they will take longer as the drive is requested to read, write, report logs, etc.

1b) Yeah, this is fine. Background activity will resume once the drive spins up and becomes idle again.

1c) No, it is not possible to query for progress of this background activity at this time. You do not need to wait for this to complete before using your drive. Writing to the drive from LBA 0-MaxLBA moves this to the foreground as it is handled as the drive writes data and only runs in the background for sectors not receiving new data.
The goal was to allow a customer to set the sector size they want and then immediately write their data to the drive without needing to wait for a full format of every sector which would mean writing every sector to zero (or another pattern if it was allowed in the format).

1d) Both longDST and longGeneric read every sector on the drive, but there are some differences.

• Long DST: This is managed by the drive firmware. It also assesses SMART and mechanical and electrical operation of the drive during this test, something that cannot be done in long generic by software. With LongDST, the drive will stop and report a failure on the first bad LBA that is read.
• Long Generic: This is managed by software by issuing read commands to every sector on the drive and checking the completion results (did it give an error indicating a bad sector). This can be run like long DST to stop on the first error, or it can continue running and report a list of all bad sectors identified at the end of the test. The error limit is also configurable from the command line, so you can allow 1 error, 5 errors, etc. The default uses a max limit to log as many as it possibly can. I think this is 65536 (max of a unsigned 16bit integer) but I cannot remember as I type this off the top of my head.

You do not need to wait for the background activity to complete before running either of these tests. The drive is not writing to the LBA space but updating other information that it needs for reliability across the drive after changing the sector size.

[jumbi77]

Wow, that is an excellent explanation, much thanks! No further question, and good to know that everything is fine :)

[jumbi77]

@vonericsen Just some follow up questions regarding --setSectorSize:

1. What is when a user run the --setSectorSize command again after first execution was successful but maybe the background activity was not yet complete ?
2. The same like 1) but after the background activity was complete ?
3. Before execution of --setSectorSize and running --showSupportedFormats the asterisk, which marks the "current device format", was in row for 512, after successful execution of --setSectorSize I got two asterisks in row for 512 and 4096. Does this mean the drive is in progress reformatting? Maybe this monitors the background activity ?

Much thanks in advance

[vonericsen]

What is when a user run the --setSectorSize command again after first execution was successful but maybe the background activity was not yet complete ?

The drive will cancel any pending background activity that is not completed, run the sector size change, then start any new activity it needs to do. The firmware decides when it needs background tasks for various reasons and after a sector size change it will basically schedule something new to go run as soon as it is idle again.

The same like 1) but after the background activity was complete ?

There isn't much difference as the firmware will schedule new background activity as it needs to. From my understanding of current firmware implementations to switch sector sizes, this happens with each sector size change so it just gets scheduled again.
This could change in the future, but I do not usually know that until I get a bug report or some odd question on a new product/new firmware. Then I usually have to find someone to help me uncover what the changes have been.

Before execution of --setSectorSize and running --showSupportedFormats the asterisk, which marks the "current device format", was in row for 512, after successful execution of --setSectorSize I got two asterisks in row for 512 and 4096. Does this mean the drive is in progress reformatting? Maybe this monitors the background activity ?

This sounds like a bug we need to go find. I'll see if I can figure out what may have caused this.
I know over USB we had to implement a weird workaround and that may trigger this, so if you were using a USB adapter that may be part of it, but I will need to debug this a bit to figure out why it showed twice.

One of the issues is that just because the drive sector size changed doesn't mean that any cached information about the sector size in an adapter, a driver, or somewhere in the OS has also changed and there is not really a way to say "hey, the sector size changed", or at least it is not easy to figure out.
The easiest thing to do is a reboot/power cycle of the system.
I have researched what is possible in Linux to refresh this and found some success with some methods, but we haven't had the time to implement that yet....even when we do there may be other issues we will run into that I didn't find during this early testing. This has happened to us before....there are so many layers and parts across a modern computer, it can be tough to get them all in sync, so reboots are typically the best to do since that refreshes everything from the BIOS/UEFI and up to a fully booted system.