What is the technical limitation to maximum number of data drives?

[ogi]

I was just wondering today why the limitation to data drives in the array is 24 ... is there a technical limitation that makes it more difficult for Tom to increase it to say, 32, or even larger? I understand that the larger the data drives, the higher the likelihood of a dual drive failure, but I was curious as to what is the governing limitation/obstacle from raising the maximum number of data drives in the unraid array.

[BobPhoenix]

My 2¢ guess is that emhttp is limited to single letter drives sda through sdz and that means 26 drives max for cache, parity, array & flash drives.  So at most you could add 1 more array drive to the current 24 drive total which does not count the flash drive.

[ogi]

My 2¢ guess is that emhttp is limited to single letter drives sda through sdz and that means 26 drives max for cache, parity, array & flash drives.  So at most you could add 1 more array drive to the current 24 drive total which does not count the flash drive.

 

given that Linux is case sensitive, can't the naming convention go from sda -> sdz -> sdA -> sdZ (resulting in 52 drives max)?  Then again I know nothing about how these letters are normally assigned so there may be another convention that could conflict I suppose...

[BRiT]

I was just wondering today why the limitation to data drives in the array is 24 ... is there a technical limitation that makes it more difficult for Tom to increase it to say, 32, or even larger?

 

To be pedantic, the limitation is how it's currently coded. It will take a bit of refactoring in the md-kernel-driver and inside emhttp to allow for more drives.

 

Also, Linux does drive letter by using "[a -> z] -> [aa -> az] -> [ba -> bz] ...  [za -> zz] -> [aaa -> aaz] -> [aba -> abz] ... [zza -> zzz] -> [aaaa -> aaaz] ...". It does not do something as going with case sensitive device names.

[ogi]

I was just wondering today why the limitation to data drives in the array is 24 ... is there a technical limitation that makes it more difficult for Tom to increase it to say, 32, or even larger?

 

To be pedantic, the limitation is how it's currently coded. It will take a bit of refactoring in the md-kernel-driver and inside emhttp to allow for more drives.

 

Also, Linux does drive letter by using "[a -> z] -> [aa -> az] -> [ba -> bz] ...  [za -> zz] -> [aaa -> aaz] -> [aba -> abz] ... [zza -> zzz] -> [aaaa -> aaaz] ...". It does not do something as going with case sensitive device names.

 

That naming convention makes sense...

 

Do we know for a fact that the emhttp module is limited based strictly on the [a -> z] naming convention or is that speculation?

 

Ogi

[graywolf]

I was just wondering today why the limitation to data drives in the array is 24 ... is there a technical limitation that makes it more difficult for Tom to increase it to say, 32, or even larger?

 

To be pedantic, the limitation is how it's currently coded. It will take a bit of refactoring in the md-kernel-driver and inside emhttp to allow for more drives.

 

Also, Linux does drive letter by using "[a -> z] -> [aa -> az] -> [ba -> bz] ...  [za -> zz] -> [aaa -> aaz] -> [aba -> abz] ... [zza -> zzz] -> [aaaa -> aaaz] ...". It does not do something as going with case sensitive device names.

 

That naming convention makes sense...

 

Do we know for a fact that the emhttp module is limited based strictly on the [a -> z] naming convention or is that speculation?

 

Ogi

 

Been quite awhile but somewhere in another thread Tom has said in the past that it is based on the [a -> z] naming limitation and that it would involve an extensive rewrite with subsequent extensive testing to change it to allow double character drive letters

 

[ogi]

I was just wondering today why the limitation to data drives in the array is 24 ... is there a technical limitation that makes it more difficult for Tom to increase it to say, 32, or even larger?

 

To be pedantic, the limitation is how it's currently coded. It will take a bit of refactoring in the md-kernel-driver and inside emhttp to allow for more drives.

 

Also, Linux does drive letter by using "[a -> z] -> [aa -> az] -> [ba -> bz] ...  [za -> zz] -> [aaa -> aaz] -> [aba -> abz] ... [zza -> zzz] -> [aaaa -> aaaz] ...". It does not do something as going with case sensitive device names.

 

That naming convention makes sense...

 

Do we know for a fact that the emhttp module is limited based strictly on the [a -> z] naming convention or is that speculation?

 

Ogi

 

Been quite awhile but somewhere in another thread Tom has said in the past that it is based on the [a -> z] naming limitation and that it would involve an extensive rewrite with subsequent extensive testing to change it to allow double character drive letters

 

Got it, figured it was probably like that (as 24 drives + cache + flash drive making up all letters of the alphabet was not a coincidence).

 

 

[jumperalex]

And frankly at some point you are looking at a lot if drives, big drives now with 4tb out there, all protected by a single parity. Rebuilding the array will take a long time and you now have the chance that one out of 23 drives  could fail.

 

I'd want double parity before I got that far. Or just run another array.  Once virtualization kicks in you  could have two Unraid arrays in single box.  If you could fit it the drives, SAS cards, and the power supply(s) for it all

 

Sent from my Nexus 7 using Tapatalk 4

[JonathanM]

Once virtualization kicks in you  could have two Unraid arrays in single box.  If you could fit it the drives, SAS cards, and the power supply(s) for it all

Just add this to your rack. 24 more drives and PSU done.