ToolBin icon indicating copy to clipboard operation
ToolBin copied to clipboard

FormatUnit has no effect

Open JSinghDev opened this issue 2 years ago • 6 comments

I was trying to change my ST4000NM005A SAS drive from 512e to 4kn and I ran the command: SeaChest_Format_x64_windows_R.exe -d arc:0:0:4 --formatUnit 4096 --fastFormat 1 --confirm ...

This has no effect and the drive still shows 512 as logical sector size rather than 4096

JSinghDev avatar Dec 10 '21 22:12 JSinghDev

Can you share the output of the following options? SeaChest_Format_x64_windows_R.exe -d yourDevice -i --showSupportedFormats Also, can you share the output from this with -v 4 added to the end? SeaChest_Format_x64_windows_R.exe -d yourDevice -i --showSupportedFormats -v 4 This second run will be verbose and contain a lot more information, so I recommend redirecting it to a file, but it will tell the raw byte response from the drive so I can verify what it is reporting for these commands.

vonericsen avatar Dec 13 '21 19:12 vonericsen

Ok, I faced a lot of weird reporting from Seachest_Format and SeaChest_Lite. On one of the drives I ran SeaChest_Lise --setSectorSize 4096 and after a restart the disk showed Logical Sector size: 4096 and Physical Sector size: 32768 which was weird.

Then I ditched windows and created a SeaChest boot drive. Then I used the Seachest_Format --formatUnit 4096 --fastFormat 1 ... command After the command the drive always showed 512 as the logical sector size but after reboot it showed 4096.

PS: I am using the Adaptec ASR71605 in HBA mode as the SAS controller.

I am attaching the relevant outputs (using the SeaChest Boot Drive) After.txt AfterReboot.txt Before.txt EraseResults.txt

JSinghDev avatar Dec 15 '21 09:12 JSinghDev

@JSinghDev, Thanks for all the output.

This scenario is definitely odd. I don't see anything in the output that you provided that seem suspect to cause this. Once the drive completes the format, it is supposed to report the new sector size, which has been my experience. A reboot is recommended afterwards anyways just to make sure all OS, drivers, etc can properly pick up the change....but SeaChest reads the information directly from the drive, which should report the new size immediately once it has finished (otherwise it reports format in progress until completed).

Can you confirm a couple things for me?

  1. Is this controller configured in RAID mode?
  2. Is this drive setup as a "passthrough" drive? (Assuming in RAID mode, not JBOD mode)
  3. When you ran the fast format, how long did you wait before trying anything else? and about how long did it take SeaChest to output the "Successfully started format unit!"?

I have an older 8405 HBA and some other newer ones (don't remember models) that I can do a little testing with to see if I can repeat this, but it will take a bit before I can get that setup.

vonericsen avatar Dec 15 '21 21:12 vonericsen

  • All of my drives are brand new 4TB 512e/4kn drives.
  • The controller is running in HBA mode and not in RAID mode. The back plane is SGPIO and there is no SAS expander.
  • The command didn't take long, about 30 seconds in fast format.

I would like to add another thing that I saw with one of the drives when I was facing this issue. I ran the formatUnit command with fastFormat 0. Furthermore, when I realized the mistake, I cancelled the command and the drive went into a faulted state (03h I guess). After that, when I ran the SeaChest_Format - d .... -i command, it showed that the device did not show the formatUnit command in the supported features list, so I could not rerun the command. I tried rebooting, but it was the same. This was in windows

I finally resolved that issue by going into the controller setup during boot and performing the low level format from there. Then post completion, the drive was behaving normally. I do not know if this is normal behavior, so I am just describing what I saw.

JSinghDev avatar Dec 16 '21 05:12 JSinghDev

Thanks for the extra detail @JSinghDev!

When you interrupted the format the first time, this puts the drive into "Format Corrupt" state. In this mode a lot of commands that SeaChest uses to detect drive features do not complete properly (even if the drive does support the command). This is because in format corrupt state certain commands are not available, but you should be able to send a new format to clear it and get it back to normal. This part makes sense.

When you did the fast format under Linux is where things seem odd to me since it seemed to take a reboot to show the new sector size. I don't know why this would be the case and nothing in what you've shared gives any indication of the drive or software having an issue, which is the odd part.

The next step will be for us to try and repeat the problem as best we can to debug it.

vonericsen avatar Dec 18 '21 01:12 vonericsen

I reread this thread and I think the reason format unit was not showing in the features is due to the drive being format corrupt (interrupting fast format mode 0). The way the software looks for that to add to the list relies on a command I have recently observed reporting "format corrupt", so I added an additional message to the features list if this is seen. I accidentally tagged #22 for this instead of #21 when I pushed it, hence this comment being added now.

The format unit command should always be supported by a SAS/SCSI drive, but that code also gets run for SCSI translators which are not known to support all translations, especially on USB, so I will need to figure out a better long term solution in the future, but I think this will help a little for now. When this shows up in the output, it should inform that a format is necessary to use the drive.

The format done in the controller's BIOS was probably this same format unit command to get the drive back to a fully functioning state again.

vonericsen avatar May 24 '22 15:05 vonericsen