Is Seagate Max LBA feature supported as solution for too large drives? How to replace drives without replacing the parity drive?

[Falcosc]

I use multiple drives with different sizes in my array.

 

My spare drive is larger than any other drive in my array.

I don't want to upgrade my parity drive size because if the parity drive fails I don't want to be forced to buy an unnecessary large replacement drive.

 

If any of my drives fail, I know about the issue that I can not use a replacement drive which is larger than the parity drive.

Which means in case of a data drive failure, I would need to replace 2 drives:

1. update the parity drive to allow larger data drives
2. replace the broken data drive

 

Because you can not replace the parity drive in a degraded array so easily, I want to know more about the issues around too large hard drives before I have to deal with this issue.

 

So I have multiple questions:

1. Is it possible to assign partitions instead of disks to work around the drive too large issue?
2. I have a Seagate drive, is the max LBA feature supported by unraid? https://www.seagate.com/manuals/software/seatools-bootable/using-seatools/#set-max
3. If you are not sure about max LBA support, which hard disk parameters are queried during the disk size check? I could try to verify if these parameters get altered after I define a max LBA via seatools

[JorgeB]

25 minutes ago, Falcosc said:

Is it possible to assign partitions instead of disks to work around the drive too large issue?

No.

 

Though I don't recommended because it doesn't work with all controllers setting a HPA would work for what you want:

 

[Falcosc]

Thank you for your quick response.

 

Cool, that sounds promising, because somebody already tested a drive assignment based on an altered max drive size. That makes me confident that this could work.
Unfortunately, I don't have a gigabyte board.

But if seagates solution is implemented similar like HPA, it would be more reliable because it is set on the hard disk and not on the bios

I could test Seagate max LBA by manually test how the drive does response to my requests:

• Which values/parameters are queried by unraid?

Edited May 27, 2022 by Falcosc

[JorgeB]

29 minutes ago, Falcosc said:

Unfortunately, I don't have a gigabyte board.

You don't need a Gigabyte board, those boards had an issue that sometimes created a HPA without you wanting.

[Falcosc]

Yes, I understood the issue of BIOS related limits.

I would like to evaluate seagates solution which is written directly to the drive controller but don't have an unraid server on hand to test it directly in unraid.

 

Could I do some test without unraid by checking how linux does see my max LBA seagate drive? I would need to know which parameters are used by unraid

 

On my unraid server I don't have empty SATA ports to test it. I could use a USB to SATA controller to plug my too large seagate drive into my array, but my licence does not allow additional drives. And I don't have a spare testbench with 3 drives to test it outside of my unraid server. So I need some help with the evaluation of the seagate max LBA feature.

I could use my main computer for testing unraid support for seagate max LBA, but I have some limits on my main rig:
- is it possible to create an array with 2 drives? 1 data + 1 parity?
- I only have one external SATA connector, so I would need to connect the 2nd drive via USB: are USB 3.0 disks supported?

If both is supported by unraid, I could test HDD swap with to large drives using seagate seatool and I could share the results.

If seagates feature is compatible, this would be great. Not only for my usecase, but also for use cases with mixed vendors where the drive size is only off by some megabytes

Edited May 27, 2022 by Falcosc

[JorgeB]

5 minutes ago, Falcosc said:

is it possible to create an array with 2 drives? 1 data + 1 parity?

Yes.

 

5 minutes ago, Falcosc said:

I only have one external SATA connector, so I would need to connect the 2nd drive via USB: are USB 3.0 disks supported?

Yes, they are not recommended but for testing it's fine.

[Falcosc]

Thank you, I will test this on my rig and share the results.
 

Why isn't this a common issue? I thought if you mix WD, Seagate or Toshiba with the same advertised size, I would expect real size differences in the kb or mb range. Or does unraid some clever under provisioning to avoid this mix vendor size difference issues?

[JorgeB]

11 minutes ago, Falcosc said:

I would expect real size differences in the kb or mb range.

No, for many years disks with same advertised capacity have the same exact number of available sectors.

[MAM59]

4 hours ago, Falcosc said:

Which means in case of a data drive failure, I would need to replace 2 drives:

1. update the parity drive to allow larger data drives
2. replace the broken data drive

which also means: it will not work!

If you wait until the 1st data disk fails, you will not be able to swap the parity driven before you have replaced and restored the the data disk.

This is because you need the "old" parity" to recreate the missing data.

But since you supposly only bigger drives then, you cannot put in a new data disks (catch22).

 

You should update the parity BEFORE anything fails.

The additional sectors will not be used until you update a data disk too, but that is not really important now.

 

I would stay away from these artificial "max LBA" tuning trick, what will you do with such a drive once the parity has been updated? removing the LBA also means removing the data. So you have to start from scratch too and do not save any time.

 

4 hours ago, Falcosc said:

I don't want to upgrade my parity drive size because if the parity drive fails I don't want to be forced to buy an unnecessary large replacement drive.

 

As said above already, parity drives are only used up the size of the largest data disk. It does not matter if it is much larger, it just needs to fulfill this minimum requirements.

Edited May 27, 2022 by MAM59

[Falcosc]

23 minutes ago, MAM59 said:

you will not be able to swap the parity driven before you have replaced and restored the the data disk.

Thanks for clarification, so instead of doing very inconvenient unsupported manual steps, it is just impossible to use a larger disk on a data drive fail.

So anybody should have a spare disk on hand which is smaller or equal to the parity drive.

I want to talk about the use case to convert an unfitting disk to align with that requirement.

 

I treat max LBA just as a way for permanently converting a HDD to a smaller size

Removing LBA is the same process as physical replacing the HDD, that should be clear I don't want to sell LBA for this, no I just need the permanent convention to the smaller size

 

Maybe I will upgrade my parity drive in 5-10 years, but this thread was created to find a solution for the worst case scenario where a data drive does fail before I plan to upgrade the array size.

 

My test rig is running. I'm glad that I did select two old 1 TB drives for testing because I forget that I need to wait for a full rebuild of the parity drive before the test array can be used.

 

 

If your server setup is very easy to maintain, you could just use the larger spare drive to replace the parity disk today and use the old parity disk as spare for the data disks.

Edited May 27, 2022 by Falcosc

[JonathanM]

5 hours ago, Falcosc said:

 

I don't want to upgrade my parity drive size because if the parity drive fails I don't want to be forced to buy an unnecessary large replacement drive.

You aren't. If you replace a 1TB parity drive with a 4TB drive, and the 4TB fails, you can rebuild parity with a 1TB drive as long as the largest data drive is still 1TB, as it was when the parity was a 1TB originally.

 

Your premise is flawed, there is no reason to artificially limit the size of the parity drive or any drive. The only requirement for a replacement drive is that it equals or exceeds any single data drive. If you have multiple 1TB drives with a 1TB parity, and one of the data drives fails and all you have is a 4TB replacement, there is already a procedure in place to handle that exact situation. The 4TB will become the new parity drive, and the existing parity drive will be rebuilt to replace the failed data drive.

[Falcosc]

12 minutes ago, JonathanM said:

If you have multiple 1TB drives with a 1TB parity, and one of the data drives fails and all you have is a 4TB replacement, there is already a procedure in place to handle that exact situation. The 4TB will become the new parity drive, and the existing parity drive will be rebuilt to replace the failed data drive.

That is exactly what I need, I couldn't find that. And MAM59 did even tell us that it is impossible to do that.

Do you have a link to the documentation?

 

By the way, you guessed the size of my spare drive
I have an array of 2TB drives with an 3TB Parity drive

Edited May 27, 2022 by Falcosc

[JonathanM]

https://wiki.unraid.net/The_parity_swap_procedure

[Falcosc]

Thanks, so this is the part which I thought has to be done manually by hand:

Quote

The 'Parity Swap' procedure will copy the parity info from the current 2TB parity drive to the 4TB drive, zero the rest, make it the new parity drive

Cool that you have a button for that usecase:

Quote

13. You should now have a Copy button, with a statement indicating "Copy will copy the parity information to the new parity disk".

 

I did just not think about the possibility to use the old parity drive as new data drive. I only concluded this after I was phrasing my response to MAM59.

 

I will try this procedure with my test setup.

 

Edited May 27, 2022 by Falcosc

[MAM59]

20 minutes ago, Falcosc said:

That is exactly what I need, I couldn't find that. And MAM59 did even tell us that it is impossible to do that.

no! You got me wrong (or my english is too bad).

 

I only said it will not work if you try to swap both data and parity disks at the same time or the data drive first.

 

first swap the parity (and use a large and fast drive, you will not like to do this job very often), rebuild or copy parity, then pull out the data disk and insert&assign a new one. Data rebuild will start automatically and when finished the old data is back and additional free space of the new data disk will be cleared and the free size added to the array.

You can then repeat the data disk swap over and over again to replace failed drives or swap to larger drives.

But do it step by step (one disk at a time only).

 

 

[Falcosc]

The cool thing about https://wiki.unraid.net/The_parity_swap_procedure is that you don't have to switch the parity drive today. You can just wait for the first failure and swap parity and data by copying the parity drive.

 

  

Max LBA changes are supported, but you have to extract the count from the old drive and can not directly calculate it based on the displayed size because there is some overhead. And if you use Seatool GUI you do enter the index, so 1953525167 need to be used there

 

Old drive:
May 27 04:36:22 unraid emhttpd: ST1000VX_000-1ES162_Z4Y2FLNG-0:0 (sdc) 512 1953525168
new drive:
May 27 08:40:26 unraid emhttpd: ST4000VN_008-2DR166_WDH1TJTV-0:0 (sdc) 512 1953525168

After rebuild, I will try the party swap procedure

...

 

Success, the documentation does still work. But I didn't do data integrity tests, I can only tell that the array was green after the process.

Edited May 30, 2022 by Falcosc

[Falcosc]

Beside the intended way, I did actually find another use-case for MAX LBA.

 

I do buy broken HDDs which only have relocated sectors and no real issues.

Then I do 5 full formatting runs to check if the number stays stable in a 48h stress test.

 

But one of 3 Disks was actually broken. During the first run, I did discover the place where the sectors get relocated by monitoring the formatting progress and monitoring at which point in time new sector relocations did happen.

 

I did add timestamps to windows format tool output with PowerShell

write-output "exfat" "j" | format J: /FS:exfat | Foreach{if ($lastline -ne $_){"{0} - {1}" -f (Get-Date),$_}; $lastline = $_}

And I did use cristaldisk info with option->Autorefresh: 1min

At CrystalDiskInfo8_12_4\Smart\ST4000VN008-2DR166ZM4105DY\ReallocatedSectorsCount.csv you will find the sector count change timestamps

 

By comparing the timestamps, you can calculate at which place on the Disk the errors happen.

Then I did create a healthy partition in front of the error to be able to create a tiny 100gb partition directly over the broken part. Formatting the broken space is way faster, and then I did identify that the disk had real trouble with this section, and each run did create new relocations. After the 3rd run, it was clear that this part is physically broken.

Be careful with formatting the broken part of the disk, the relocated sector count has a limit monitored in % in the smart table. It did go from 99% to 87% in a half hour. So remember to stop the process as soon as you feel confident that this is an unrecoverable problem.

 

At the end of the story I did use max LBA to exclude the broken part of the disk since it was only effecting the very last 100GB.

After doing this I have a 3,9TB HDD which is already at the 7th full formatting path.

Using the windows tool to have one write 0 pass and 2 write random passes

format J: /FS:exfat /P:3

 

 

I don't recommend putting more than one of these questionable disks in your array, but since I have backups, I am happy to experiment how unraid does handle real hard disk failures by raising my array risk factor with drives saved from landfill.

I hope this does offset the power used for the 48hour stress test and all the unnecessary power on hours during unraid array feature experimentation sessions.

Edited May 30, 2022 by Falcosc