From the standpoint of a software developer, I can tell you that is a disaster waiting to happen.

 

First rule of development is that end users are brain-dead morons.  Any choice left to a user to decide intelligently is doomed to failure.  Let them have all the choices they want with respect to bell and whistles, but when it comes to a choice where if you chose wrong you lose data or you get crappy performance, giving that choice to users is like giving a loaded gun to gorilla.

 

That's you and me you're talking about there!  

 

First, I believe it would not be hard to allow both 63 and 64 partitions in the same system... unRAID can check and handle both.

 

I don't agree here.  It could handle it in a sub-optimal way.  Better to get it right, and not allow this to occur.

 

But as has been pointed out, you have a disaster waiting when you have to rebuild a failed 63 drive with a drive that should be a 64 drive and vice versa (replacing a 64 drive with an EARS with the jumper).  

 

Correct.  Not a disaster, but a support nightmare.  User's wouldn't know whether their sectors were aligned or not aligned.  Some of the disks would need the jumper and others need it removed.  Joe L. would be responding to support emails all day and all night if we allowed this!

 

The second issue is which to use (63 or 64) for new drives added to the system.  64 can be used for EVERY new drive... EXCEPT a WDEARS with the jumper

 

This can be used for EVERY new drive - EVEN EARS with the jumper installed.  The jumper installed is just a performance issue.  This is no different than now.

 

(WARNING:  This is based on the current crop of drives... other manufacturers may also have issues with drives that are not yet on the market... hence why I say wait for them to shake out).  The only option is to give the user a choice.  If you have a choice, you need a way to fix the choice being chosen wrong.

 

Although new drives may have more sophisticated kludges of handling the 63 sector alignment issue, they will have to provide a non-kludged, linear sector model.  The more difficult question is what happens when/if they expose 4K sectors.  But I think this will not happen with the 3T drives.  Maybe with the 4T.

 

You don't have to give the user a choice.  You tell them what to do, and if they screw up, a way to recover.

 

What I would do is add a "copy disk" option.  Given a precleared disk of the appropriate size, it could be added to the array, with a different starting sector for the partition than the failed disk, and drive contents copied on a file-by-file basis, while maintaining parity.  Most importantly, this could be done with a failed disk, to facilitate replacing a 63 with a 64.

 

I like this as a transition feature, EXCEPT that it would not be restartable.  You'd have to be updating parity in conjunction with the rebuild.  So you'd get ONE chance.  I would prefer to have it rebuild onto a non-array disk, and then add the disk to the array / remove the old disk from the array, and then rebuild parity.  That approach provide full restartability.

 

Then you are stuck with good parity, a clean new disk that has the same contents as the failed disk.  To maintain parity, you need to be able to zero out the failed disk and remove it from the array.  (A feature that is in and of itself quite useful).

 

Zeroing out the old disk would not allow parity to be maintained because you are not doing a bit for bit disk copy. (I'll take that last comment as a compliment )

 

The idea of resizing a 63 to a 64 is also possible.  For example, ParitionMagic will resize and relocate parititions.  You don't have to move every sector though, you just have to have enough free space to move the files AS FILES that are in the way, flush the data, and then move/update the directories, inodes, etc.

 

Do you think there is an existing COTS product that would do this transformation?  I don't think Partition Magic is even on the market anymore - and I don't think it ever understood RFS formats - but I'm not sure.  If we had a tool that could inch the RFS partition forward by one sector (or backwards by 3), that would be awesome!  But just because it is technically feasible does not mean it will ever get done.  We may still be looking at brute force methods.

I am not suggesting the elimination of the MBR.  I am suggesting that instead of only parity protecting the first (and only) partition on the disk that parity protect every sector on the disk.

 

This is completely invisible to the user.  That's how I thought it worked until you explained.  But I suppose parity protecting the entire disk (esp the MBR) may present problems we don't fully understand.  At the end of the day I don't care about protecting the non-RFS parts of the disk, so long as unRAID protect my data.

 

That way, as far as parity and all its routines care, the contents and MBR /GUID structures do not matter.  That change could be made today and nobody would need to change any partitioning.   (It may require some changes to emhttp, as it force writes the MBR currently along with the MBR style partition table.  That can stay, for now... but when it changes it (emhttp) will be able to start the partition anywhere. (theoretically) using any partitioning scheme.

 

Again, this is at a layer beheath the user, and I can't say it would make for an easier or harder time for Tom.  That's his decision.  I do not believe that Tom needs to provide any flexibily in the format of the disks in the array, so long as it is in a standard format that can be accessed from non-unRAID machines (windoz and linux).

 

If a "standard" partitioning scheme is used, a window's PC, or at least a newer windows PC should be able to deal with the partition.

 

Linux has never needed a partition... You can "dd" a full partition holding a file-system and put it in a file as an example.  I do that frequently when backing up a window's PC when no other backup tools are available.

 

So... by using a GUID we can still get to the data by mounting an individual disk on either windows or Lniux.

 

Got it.

 

As far as migrating the file-system...  Tricky to do in place.  possible, but tricky.  It involves moving the entire partition upward.  That is complicated since the partition currently uses all the space, so therefore, you must first shrink the existing file-system by one sector (not too hard as long as it is not full) and then copy every sector up one.  (copy the second to last sector to the last sector, then the third from last tot he second to last, etc...) It will be a VERY LONG process.   Probably longer than re-constructing a disk.

 

This is the $64,000 question.  How to do this without a month's worth of user effort.  But even a month's worth of user effort is justified if that allows us to move into the 2.2T+ disk sizes without have to do ANOTHER 1 month reshuffle later (see next response).

 

When you finish moving the data that represents a partition, the partition table itself must point to the new start.  That is probably easy compared to the rest.

 

With the gdisk ability to convert from MBR to GPT, if Tom implemented the sector alignment with MBR intact, would the move to GPT be as simple as running gdisk?

No,  all of the routines in emhttp dealing with upgrading disks, determining native unRAID disks vs. pre-cleared disks vs. foreign disks need to be updated.  It is a HUGE job.  Everything is hard coded to expect an MBR, including the preclear_disk.sh utility I wrote. It too would need the corresponding changes to deal with a GUID partition table.

 

My question about being able to use gdisk to replace the MBR with the GPT was more about impact on the disk itself.  The gdisk command would not, if I understand right, affect the existing RFS partition that is on the disk. So if Tom implemented the 64 bit alignment feature with MBR disks, and then later wanted to support GPT, he could add that feature, and users would not have another month's worth of disk shuffling to do. That was my question and point.

This can be used for EVERY new drive - EVEN EARS with the jumper installed.  The jumper installed is just a performance issue.  This is no different than now.

 

Which is my point from the very beginning.  It is a solution looking for a problem that is a moderate performance issue -- at worst.

This can be used for EVERY new drive - EVEN EARS with the jumper installed.  The jumper installed is just a performance issue.  This is no different than now.

 

Which is my point from the very beginning.  It is a solution looking for a problem that is a moderate performance issue -- at worst.

 

My understanding is that this cuts performance in half.

 

And this is preparing us to go to the 3T drives, which will ALL have this same alignment issue.

Zeroing out the old disk would not allow parity to be maintained because you are not doing a bit for bit disk copy.

 

This has been discussed before.... you can zero out a disk, maintaining parity, then remove the disk from the array config while retaining parity.  Perhaps you misunderstood my suggestion.. I do not mean to zero out while copying... you have to do the complete file-based copy first.  Only after that complete successfully, do you go back and zero out the old drive on a sector basis so it can be removed.

 

I like this as a transition feature, EXCEPT that it would not be restartable.  

 

Sure it would.  You would have to restart from the beginning to make sure it is all copied, but remember, this is a FILE-BASED copy to a precleared new drive, not a rebuilding by SECTOR.

 

I reiterate that it would be possible, and not particularly complicated, for unRAID to allow 63 and 64 disks to exists in the same system.  All that has to be cone is change the code that looks for the signature to look in 2 places and allow the drive to be used if either is found.  You have to deal with the situation of parity being 64, and then 1-sector larger than a data drive of the same make/model using 63, but that's doable.  

 

What you CAN'T do is rebuild a 63 disk to a 64 disk and vice versa, on a sector basis... but you CAN do it on a FILE basis using a file-based copy to a new drive.

My understanding is that this cuts performance in half.

 

For lots of small files, yes.  But for large media files, the impact is smaller.

This can be used for EVERY new drive - EVEN EARS with the jumper installed.  The jumper installed is just a performance issue.  This is no different than now.

 

Which is my point from the very beginning.  It is a solution looking for a problem that is a moderate performance issue -- at worst.

exactly... For most unRAID users, the performance difference is not noticeable...  When playing media we are not  randomly accessing blocks of data.  Instead, we are mainly linearly accessing massive numbers of contiguous blocks of data.   The sector alignment issue does not show itself since the drive's cache combined with sector read-ahead and buffering eliminates most if not all of the performance difference.

 

If you are anal about individual read/write throughput and lose sight of your actual usage it probably translates into a 10 to 20% difference in disk speed... and absolutely no difference in how you use the server to store your files and play your movies.

Perhaps you misunderstood my suggestion.. I do not mean to zero out while copying... you have to do the complete file-based copy first.  Only after that complete successfully, do you go back and zero out the old drive on a sector basis so it can be removed.

 

I did misunderstand.  This would work as advertised.  My way would be faster (for Tom to implement), but not as safe.  Both ways are way slower than the normal drive rebuild process.

 

I reiterate that it would be possible, and not particularly complicated, for unRAID to allow 63 and 64 disks to exists in the same system.  All that has to be dcone is change the code that looks for the signature to look in 2 places and allow the drive to be used if either is found.  You have to deal with the situation of parity being 64, and then 1-sector larger than a data drive of the same make/model using 63, but that's doable.  

 

What you CAN'T do is rebuild a 63 disk to a 64 disk and vice versa, on a sector basis... but you CAN do it on a FILE basis using a file-based copy to a new drive.

 

I like this as a transition strategy, but not as an operational model.  Perhpas unRAID could mark 63 disks read-only and only allow the "copy disk" option on them.  Leaving arrays in the hybrid model is worse than the choice method described earlier IMO.

I like this as a transition strategy, but not as an operational model.  Perhpas unRAID could mark 63 disks read-only and only allow the "copy disk" option on them.  Leaving arrays in the hybrid model is worse than the choice method described earlier IMO.

 

I don't see why that should be so.  What is wrong with the hybrid mode?  The ONLY problem is rebuilding a disk when the offset would be sub-optimum for the new disk, and create a performance issue.

 

A 63-disk and a 64-disk can both participate in parity, and be written to.  Parity doesn't care.

If you are anal about individual read/write throughput and lose sight of your actual usage it probably translates into a 10 to 20% difference in disk speed... and absolutely no difference in how you use the server to store your files and play your movies.

 

Are we saying that users should just ignore the jumpers altogether and accept reduced performance on the 4k sector drives?  And because of that, we stay with the 63 sector alignment going forward into the 3T+ world because we don't need sector alignment.  And the 2T Samsung drives should not be avoided becuase the performance hit doesn't matter?

 

 

I like this as a transition strategy, but not as an operational model.  Perhpas unRAID could mark 63 disks read-only and only allow the "copy disk" option on them.  Leaving arrays in the hybrid model is worse than the choice method described earlier IMO.

 

I don't see why that should be so.  What is wrong with the hybrid mode?  The ONLY problem is rebuilding a disk when the offset would be sub-optimum for the new disk, and create a performance issue.

 

A 63-disk and a 64-disk can both participate in parity, and be written to.  Parity doesn't care.

 

You know, as this sinks slowly into the aging cerebellum - it starts to sound more and more appealing.  Any new disk would be aligned at 64 sectors, but existing 63 sector aligned disks would not require the month long conversion effort.  As you upsize disks through the normal course of time, you will periodically be confronted with a longer rebuild time as the partitioning is modified.  But after that, you'd be back to the normal rebuild process where the disk is reconstructed sector by sector.

 

(If you are anal, you can do the month-long process and have a pure 64 sector aligned array.)

 

I like it!

If you are anal about individual read/write throughput and lose sight of your actual usage it probably translates into a 10 to 20% difference in disk speed... and absolutely no difference in how you use the server to store your files and play your movies.

 

Are we saying that users should just ignore the jumpers altogether and accept reduced performance on the 4k sector drives?  And because of that, we stay with the 63 sector alignment going forward into the 3T+ world because we don't need sector alignment.  And the 2T Samsung drives should not be avoided becuase the performance hit doesn't matter?

Basically yes...   We've seen many people who say "They did not know about the jumper and have been running for months without it just fine..." and then they add the jumpers and all kinds of errors start occurring.

Basically yes...   We've seen many people who say "They did not know about the jumper and have been running for months without it just fine..." and then they add the jumpers and all kinds of errors start occurring.

 

The WD jumper is a kludge, and obviously causes horrible headaches.  I've avoided them as I konw you have to.  But a 20% reduction in performance is equivalent to taking a 7200 RPM drive down to 5760 RPM, and a 5400 RPM drive down to 4320 RPM.  And even if the effect is less, do we really want to live with a performance penalty for the long run, if it can be easily avoided?

 

I like it!

 

Just one more comment on the mixed mode option, it does require quite a bit more effort on Tom's part than the model I originally came up with, which put most of the effort on the user.  I'd rather have the simple option quick, than have to wait a very long time for the better option.

The WD jumper is a kludge, and obviously causes horrible headaches.  I've avoided them as I konw you have to.  But a 20% reduction in performance is equivalent to taking a 7200 RPM drive down to 5760 RPM, and a 5400 RPM drive down to 4320 RPM.  And even if the effect is less, do we really want to live with a performance penalty for the long run, if it can be easily avoided?

 

It can easily be avoided... use the jumper properly.

 

I like it!

 

So:

-  allow both 63 and 64 disks to live together.

-  create a "copy disk" option that rebuilds a disk by file, and not by sector.

-  create a "remove disk" function that zeros out a disk while retaining parity.

-  start using 64 (or 58, or 32, etc.) for new drives.

-  when a 63 disk fails, and you insert a new disk to be rebuilt, tell the user they should use a file-based copy, rather than standard rebuilding.... then use the "copy disk" followed by zeroing out and removing the failed 63 disk (removing in the case of a failed disk that is now missing, would be zeroing the simulated missing disk, and removing it from the array, not necessarily physically).

Just read through this and think there might be one option not explicitly mentioned. Maybe it could be as simple as all new arrays (not new drives in an existing arrary) allign partitons at sector 64. Non advanced format drives would still work just fine, they don't care what the starting sector is because every sector is essentially alligned to a physical sector. When adding a drive to an existing array the partition should be alligned to what ever that array is using 63 or 64. I should think that software wise this would be a simple and reliable solution.

 

The idea of converting anything on the fly during a rebuild scares me, as do the issues with an array of mixed partition allignments.

 

The downsides I can think are:

- You could not move a drive between 63 and 64 alligned array without clearing it.

- You would need to know if you have a 63 or 64 alligned array to set the WD jumper correctly when adding a new drive. Even if you don't get this right the penalty is not huge, as has previously been pointed out.

 

On the plus side: If you are building a new array leave the jumber off WD drives and use any drive you want, including Samsung F4s. Everyting will perform optimally. Very simple for new users.

 

>2TB drive support is a whole other subject and unrelated to allignment on existing drives.

Just read through this and think there might be one option not explicitly mentioned. Maybe it could be as simple as all new arrays (not new drives in an existing arrary) allign partitons at sector 64. Non advanced format drives would still work just fine, they don't care what the starting sector is because every sector is essentially alligned to a physical sector. When adding a drive to an existing array the partition should be alligned to what ever that array is using 63 or 64. I should think that software wise this would be a simple and reliable solution.

 

The idea of converting anything on the fly during a rebuild scares me, as do the issues with an array of mixed partition allignments.

 

The downsides I can think are:

- You could not move a drive between 63 and 64 alligned array without clearing it.

- You would need to know if you have a 63 or 64 alligned array to set the WD jumper correctly when adding a new drive. Even if you don't get this right the penalty is not huge, as has previously been pointed out.

 

On the plus side: If you are building a new array leave the jumber off WD drives and use any drive you want, including Samsung F4s. Everyting will perform optimally. Very simple for new users.

 

>2TB drive support is a whole other subject and unrelated to alignment on existing drives.

 

 

63 aligned arrays may become obsolete if and when only advanced format drives are available for purchase and this does not support a transition plan from 63 to 64.

 

If we assume that drives that operate with a 63 byte alignment, e.g., WD EARS with jumper, will continue to be available then this is a simpler plan.

 

Perhaps the standard interface should be simple and an advanced interface that allows transition could be installed.

 

 

 

 

 

Easiest is a plan that no longer mandates a specific partition scheme...  It will not be an easy transition...