Need Community input on 4K-sector drives

[eek]

Is there anything wrong with putting a line in the sand that says as of unraid 5.x.x all new partitions start at sector 64 ?

 

I know I rarely post but it does seem the safest option once we've tested the impact of running a data disk with a partition starting at sector 64.

 

Of course it would need to be a very robust release as once you move to this release you would not be able to go back. It should also probably have major number version just to avoid complaints like I've downgraded from 5.1.4 to 5.1.3 what happened?

 

 

[WeeboTech]

Is there anything wrong with putting a line in the sand that says as of unraid 5.x.x all new partitions start at sector 64 ?

 

I know I rarely post but it does seem the safest option once we've tested the impact of running a data disk with a partition starting at sector 64.

 

Of course it would need to be a very robust release as once you move to this release you would not be able to go back. It should also probably have major number version just to avoid complaints like I've downgraded from 5.1.4 to 5.1.3 what happened?

 

Unless the last 4.x was modified to detect the unRAID disk signature in both positions.

Since it's only a read/detect/enable mount it might be feasible.

[prostuff1]

Unless the last 4.x was modified to detect the unRAID disk signature in both positions.

Since it's only a read/detect/enable mount it might be feasible.

 

This seems like a good option to me.  Have a 4.6.1 release which can detect, enable, and mount disk starting at sector 64.  Remove the format button from the web interface so no one can use it, but allow it to be run from a command prompt (maybe).

[Joe L.]

Unless the last 4.x was modified to detect the unRAID disk signature in both positions.

Since it's only a read/detect/enable mount it might be feasible.

 

This seems like a good option to me.  Have a 4.6.1 release which can detect, enable, and mount disk starting at sector 64.  Remove the format button from the web interface so no one can use it, but allow it to be run from a command prompt (maybe).

The "Format" button is not the issue.  It uses the partition already created and affiliated with the "md" device.  it is the creation of the partition on the disk, and specifically the starting sector that is the issue.  So... you can leave the existing partitioning/formatting functionality in the 4.6.1 version, just do not reject a reiserfs partition starting on sector 64 as un-formatted.

 

Joe L.

[WeeboTech]

you can leave the existing partitioning/formatting functionality in the 4.6.1 version, just do not reject a reiserfs partition starting on sector 64 as un-formatted.

I think this is a good plan.

[purko]

Is there anything wrong with putting a line in the sand that says [...] all new partitions start at sector 64 ?

^^ That makes good sense.  

 

-- unRAID will recognize and mount either 63 or 64 partition, but

-- unRAID will format disks from sector 64 only, regargless of what kind of disk it is.

 

[greybeard]

I think the questions are:

 

1. Should

recognize and mount either 63 or 64 partition

be a 4.6.1, 5.0 or 5.1 feature?

 

2. Should

all new partitions start at sector 64

be 5.0, 5.1 or 5.x (x>1) feature?

 

The answers need to be coridnated and GPT support needs a plan too.

[lionelhutz]

My understanding is that After the MBR, there are a bunch of zeroed sectors that could be used...

Not entirely true.  Different bootloaders use some sectors between the MBR and 63, and

you can't be sure how many.  Remember, we can insert a disk into unRAID that's already been

formatted and contains data.  It may be a boot disk from somewhere, and we want to be able to

later put it back where it came from   So we can't mess with its first 62 sectors.

 

 

Exactly how many users are installing properly formatted ReiserFS disks from somewhere else into an unRAID box? There might be an advanced user doing it for some reason special to him but that is not the intent of unRAID at all. All-in-all, I see this as a complete non-issue.

 

I also agree that starting the partition earlier than sector 63 could be a valid way to get around that trailing GPT table issue that Tom raised. Another backwards compatibility issue does arise though. It's possible the new disks could then format to be slightly larger so you could not go backwards and expect to replace a failed GPT 4k formatted disk by using the old MBR formatting.

 

It would be great to say that as of 5.0 all new disks are formatted with a new partition scheme. However, I believe one of these ways is how to approach this;

 

Follow the posters who have suggested to first get a solid working 5.0 release out and then add this new disk formatting once enough 5.0 systems are working to prove that it is solid. Don't do any further development to the 4.6 series. Someone with an odd hardware compatibiity issue would simply have to stay at 4.6 until they correct it.

 

The 4.6 series would be upgraded to recognize and mount a drive with the new formattingn in case something appears in the newly released "stable" 5.0 that requires users to downgrade. The 4.6 series wouldn't need to perform the new formatting, just use existing disks. I don't really like this approach if it adds a lot of extra work that hurts the 5.0 development.

 

Peter

 

[purko]

Exactly how many users are installing properly formatted ReiserFS disks from somewhere else into an unRAID box?

Exactly, many.  I've been doing it all along.

When you insert a new disk in unRAID, you have to either:

-- zero the disk and keep the parity, or

-- keep the disk and all the data on it and rebuild the parity.

Why would you want to lose the second option?

 

[lionelhutz]

Exactly how many users are installing properly formatted ReiserFS disks from somewhere else into an unRAID box?

Exactly, many.  I've been doing it all along.

When you insert a new disk in unRAID, you have to either:

-- zero the disk and keep the parity, or

-- keep the disk and all the data on it and rebuild the parity.

Why would you want to lose the second option?

 

 

Really, you install system disks from other computer systems into your unRAID box all the time? And you also think that many unRAID users do that?

 

One feature of unRAID is the ability to install a new disk and keep parity intact during the whole process. However, there has always been the ability to add a properly formatted disk to an existing array by rebuilding parity. So, add a properly formatted disk and you will have the ability to use it in an unRAID array without clearing it first. unRAID has always been like this and will continue to be like this in the future. The properly formatted disk may not be usable as a system or boot disk, but disks were never intended to be bootable under unRAID.

 

Moving system disks from other machines in and out of your unRAID array is not how unRAID is intended to work. Sorry, but I find it somewhat dumb to cry wolf when you use a product in a way it wasn't intended and then find your use is broken due to a product upgrade. You should accept that possibility if you chose to apply a product in some odd way other than it's intended purpose. In other words, it's not fair to expect Tom and all other unRAID users to compromise just to have the ability to add system disks to an unRAID array.

 

Peter

 

[WeeboTech]

We've presented some food for thought here. Let's not get too far off the core with how many people are importing and exporting disks. Every preclear is an import.

No matter what happens, some version 4.x or 5.x will need to accept partitions @63 and @64.

Since the industry usually chooses to start ssd's after 63. i.e 64 and above, I'm not fond of starting the partition earlier.

 

I don't think it will take too much to have emhttp check it's current sectors for the signature and if that fails, check the alternate position.

 

As far as formatting them @64, I'm for later versions of unRAID or adjusting the preclear to do this.

If emhttp can accept the disks in either position, we can always manually format them until the dust settles.

 

[lionelhutz]

...adjusting the preclear to do this.

If emhttp can accept the disks in either position, we can always manually format them until the dust settles.

 

 

An interesting idea. Update emhttp to use both formats. Then, users here could do some testing of the new drive format if Joe would be willing to create a new version of his excellent preclear script which formats the drives using GPT and the new partition style that Tom choses? Maybe the emhttp update could be slid into a 5.x beta release with the new disk formatting part being added later.

 

Peter

 

[purko]

Exactly how many users are installing properly formatted ReiserFS disks from somewhere else into an unRAID box?

Exactly, many.  I've been doing it all along.

When you insert a new disk in unRAID, you have to either:

-- zero the disk and keep the parity, or

-- keep the disk and all the data on it and rebuild the parity.

Why would you want to lose the second option?

 

 

Really, you install system disks from other computer systems into your unRAID box all the time? And you also think that many unRAID users do that?

 

One feature of unRAID is the ability to install a new disk and keep parity intact during the whole process. However, there has always been the ability to add a properly formatted disk to an existing array by rebuilding parity. So, add a properly formatted disk and you will have the ability to use it in an unRAID array without clearing it first. unRAID has always been like this and will continue to be like this in the future. The properly formatted disk may not be usable as a system or boot disk, but disks were never intended to be bootable under unRAID.

 

Moving system disks from other machines in and out of your unRAID array is not how unRAID is intended to work. Sorry, but I find it somewhat dumb to cry wolf when you use a product in a way it wasn't intended and then find your use is broken due to a product upgrade. You should accept that possibility if you chose to apply a product in some odd way other than it's intended purpose. In other words, it's not fair to expect Tom and all other unRAID users to compromise just to have the ability to add system disks to an unRAID array.

Who gave you the right to lecture me how unRAID is intended to work?

It's always been a feature to insert a disk and preserve all the data on it.

You want to break this, and you're calling me dumb?  Give me a break!

 

[Joe L.]

...adjusting the preclear to do this.

If emhttp can accept the disks in either position, we can always manually format them until the dust settles.

 

 

An interesting idea. Update emhttp to use both formats. Then, users here could do some testing of the new drive format if Joe would be willing to create a new version of his excellent preclear script which formats the drives using GPT and the new partition style that Tom choses? Maybe the emhttp update could be slid into a 5.x beta release with the new disk formatting part being added later.

 

Peter

 

While I can easily modify the preclear_script with an option to start the partition at sector 64 instead of the first sector of the second cylinder (63) I cannot forsee what unRAID will eventually use when a transition to GPT partitions occur.  (I'd have to trade in my crystal ball for one that can work an undetermined time into the future)

 

Nor do I currently know much about GPT partition tables and how they have a mirror GPT table at the end of the disk.  This would seem to indicate that they could not be easily retrofitted to an existing file system as there is no room at the end of the disk. The file system would need to be made smaller.  (I know the acronym, but not the internal structure.  I have read they have several crc checksums.  Might be very tricky with the current script to create the bits needed in a shell script)

 

The GPT partitions are only needed by those wanting to use 3TB (and larger) disks.   In my personal opinion that can wait until after the 4K alignment performance issues are addressed.

 

Oh yes... I already made the changes to preclear_disk.sh to start at sector 64.  It will be the "-A" option.  I made those changes about a week ago.    makes no sense to release it though since it would just be a foreign disk to unRAID.

 

 

[greybeard]

Oh yes... I already made the changes to preclear_disk.sh to start at sector 64.  It will be the "-A" option.

 

Nice! Looking forward to when it will be useful, maybe even the default at some future time.

 

Have you thought about incorporating the change to skip the preread for passes 2-n in a multipass preclear? Would be nice not to have add that modification to the script when new versions are released.

[Joe L.]

Oh yes... I already made the changes to preclear_disk.sh to start at sector 64.  It will be the "-A" option.

 

Nice! Looking forward to when it will be useful, maybe even the default at some future time.

 

Have you thought about incorporating the change to skip the preread for passes 2-n in a multipass preclear? Would be nice not to have add that modification to the script when new versions are released.

It's in there too.  The pre-read only is done on the very first cycle. the post-read of every other is treated as the pre-read for the subsequent cycle.:

  if [ "$pre_read_flag" = "y" -a $cc = 1 ]

  then

  pretmr=$(timer) #get preread start time

  read_entire_disk $theDisk preread display_progress

  fi

[lionelhutz]

It's always been a feature to insert a disk and preserve all the data on it.

 

Honestly, I have no idea what point you are trying to make.

 

I can install a properly formatted drive into unRAID and it is recognized and I can keep the data if I want. In the future, unRAID will still recognize a drive that has the proper formatting and allow me to keep the data. The only difference will be that future versions will have 2 or more different acceptable formatting options.

 

However, I think it's completely unreasonable to expect Tom to support a system disk with a bootable operating system from some other computer. I personally think that properly formatting a replacement advanced format 2T drive when it is replacing a failed 2T drive is more important than supporting a system disk with a bootable operating system. A GPT format appearsto require a starting partition sector <63 to make this happen.

 

You might not agree. It doesn't matter either way though because Tom will make the final decision.

 

Peter

 

[lionelhutz]

While I can easily modify the preclear_script with an option to start the partition at sector 64 instead of the first sector of the second cylinder (63) I cannot forsee what unRAID will eventually use when a transition to GPT partitions occur.  (I'd have to trade in my crystal ball for one that can work an undetermined time into the future)

 

When I posted "the partition style that Tom choses." I meant that you would first have to know the new disk formatting that has been chosen, not to try guessing by using a Ouija board.

 

The GPT partitions are only needed by those wanting to use 3TB (and larger) disks.   In my personal opinion that can wait until after the 4K alignment performance issues are addressed.

 

You do bring up a good point. It's also possible to use sector 64 now and to only use GPT partitions on disks >2T in size. Also, the GPT and >2T disks could be addressed at an even future date. We could continue to use your script since it's ready to go too.

 

Peter

 

[greybeard]

Oh yes... I already made the changes to preclear_disk.sh to start at sector 64.  It will be the "-A" option.

 

Nice! Looking forward to when it will be useful, maybe even the default at some future time.

 

Have you thought about incorporating the change to skip the preread for passes 2-n in a multipass preclear? Would be nice not to have add that modification to the script when new versions are released.

It's in there too.  The pre-read only is done on the very first cycle. the post-read of every other is treated as the pre-read for the subsequent cycle.:

  if [ "$pre_read_flag" = "y" -a $cc = 1 ]

  then

  pretmr=$(timer) #get preread start time

  read_entire_disk $theDisk preread display_progress

  fi

 

Thanks!

[greybeard]

I have to wonder how sector reallocation in a 4k physical, 512b logical drive works.

 

Does error detection and correction work at the logical 512b level or when there is a pending reallocate does the entire 4k physical sector have to be written to in order to complete the reallocated sequance?

 

I would hope it is at the logical 512b level but the implications of that is the drive firmware would need to merge data from the logical sector being written with data from the 4k sector it maps to. Then what happens if there are two logical 512b sectors pending reallocation in the same 4k physical sector? Does the drive reallocate what it can and then wait for a write of the second unreadable logical 512b sector? Would it know the reallocation is partially done and just fill in the blank?

 

When you think about it, emulating 512b sectors is not so simple when it comes to error recover.

 

Probably doesn't really make any difference so long as it works but I do like to understand how things work.

[BRiT]

I'm guessing the drive itself operates at the physical level, so when a sector requires reallocation, it's reallocating the entire 4K physical sector since that's the smallest physical unit it can address.

[greybeard]

I'm guessing the drive itself operates at the physical level, so when a sector requires reallocation, it's reallocating the entire 4K physical sector since that's the smallest physical unit it can address.

 

And that is not so easy to do when data is being written to the drive in 512b blocks. It would take from 1-8 blocks to reconstruct a 4k sector, sent to the drive in who knows what order. I am sure it is possible but it is a level of complexity that did not exist in 512 sector drives. At this point I can only assume it is all handled in the drive and the host OS does not need to do anything special when a physical sector goes bad.

[kenoka]

...I seem to be suffering from the mvsas driver issue...

 

I think the Supermicro card might be heat-sensitive.  If you are using this card, and can make errors happen, as an experiment, try running fan over the card and see if that helps.

 

Okay, it's worth a shot. I've put in an 80mm fan. I hope it works, because I'm pretty sick of having to hard reboot the server and going through parity checks.

[kenoka]

The GPT partitions are only needed by those wanting to use 3TB (and larger) disks.   In my personal opinion that can wait until after the 4K alignment performance issues are addressed.

GPT can definitely wait. GPT isn't necessary to support 3TB disks, only 2.2+TB disks that are using 512B sectors. Disks using 4K sectors could have 8+TB using the existing system.

 

You need UEFI to boot to a disk > 2^32 sectors, because that's the limit on both BIOS and MBR. BIOS and MBR can support disks larger than 2.2 TB, but they need to have larger sectors so that they can address more memory per sector.

 

So just adding native support for 4K sectors should see us through a couple more generations of drives. By that time, UEFI and GPT should be standard across the industry, and those standards will probably take us forward for a decade or two.

[bubbaQ]

GPT can definitely wait. GPT isn't necessary to support 3TB disks, only 2.2+TB disks that are using 512B sectors. Disks using 4K sectors could have 8+TB using the existing system.

 

No, they cannot.  The 4K sectors are not exposed by the drive to the OS.