0

I think there is a limitation that how many disk could a SLES 9 machine handle. (32bit). I cannot find the number via Google..

My question: Can somebody tell with reference, what is this number?

evachristine
  • 2,613
  • My answer assumes you are asking about total storage primarily, but the way you ask your question, I think you might just want to know how many physical hard drives the OS will support. Please let me know which you mean. Either my answer needs to be brought into line with your intent, or the question needs to be edited to more clearly ask the question the way I answered it. – Warren Young May 07 '14 at 05:19

2 Answers2

0

There's no limit to my knowledge and if the limit exists you're not likely to meet it. After rotating through all sd[a-z] the drives will be labeled sdaa through sdazz and on and on. So if there's a limit it's the number of drives that scheme can label inside the maximum file path length (UUIDs might change that I'm not sure).

That only covers IDE, SCSI, SATA and similar. I believe USB and others will have different limits.

Livinglifeback
  • 1,596
0

Educated Guess

4 PiB.

Justification

SLES 9 is about a decade old now, so it's not going to support filesystems as big as modern Linux distros can, or as many volumes as modern kernels can. The newest supported kernel in SLES 9 is 2.6.5.

You're also artificially limiting yourself by using a 32-bit OS: bigger filesystems require more RAM to manage. A conservative rule of thumb is 1 GiB per TiB. Since 32-bit Linux is limited to 4 GiB normally[1], you're pushing it to use a 32-bit Linux to manage more than 4 TiB. I've gone as far as 16 TiB and gotten away with it[2], but I am not actually recommending that. A common horror story is for an fsck after a power outage to fail to complete due to lack of RAM, thus preventing the filesystem from being remounted.

The most capable filesystem that comes built into SLES 9 is JFS. Its volume size limit is up in the petabytes, thus effectively unlimited.

SLES 9 also supports ReiserFS, which has a 16 TiB volume size limit. This is a good match for your 32-bit system, for the RAM limit reasons above.

There's also a limit on the number of /dev/sd device paths in the Linux kernel. It's changed a few times over Linux's lifetime, in common power-of-2 values. The limit for SLES 9 is probably 256 volumes, based of the documented limit for RHEL 3 and 4, which are roughly contemporaneous with SLES 9.[3]

The storage limit is the volume size limit times the maximum number of volumes. My 4 PiB number above is based on a 16 TiB max volume size × 256 volumes.

You're Not Going to Hit the Limit

That's an awful lot of storage, no matter how you arrange it. The actual number ends up not being terribly important for practical reasons. Simply connecting enough disks to a single computer to reach this guessed-at limit is going to be quite a challenge, especially given that the common disk controllers compatible with kernel 2.6.5 won't support modern Advanced Format disks, so you probably can't use disks bigger than 2 TB.

That means you need thousands of physical disks to hit this 4 PiB limit.

If you don't run into a connectivity or rack size limit first, you'll run into some other practical limit before you hit the absolute hard technical limit.

Footnotes:

  1. PAE allows up to 64 GiB on a 32-bit system, but I don't know that the kernel can use any of the space beyond 4 GiB for the buffer cache.

    No fsck implementation I'm aware of can make use of PAE, either, since it takes a lot of special trickery in user-space applications to do so. An exceedingly small number of programs ever made real use of PAE, in the years past when it was a viable solution to the RAM limit problem. (Today, you'd just use a 64-bit OS.)

  2. The need for RAM is a function of the number of files and directories on the disk, and the number of simultaneous accesses it is serving. The "1 GiB per TiB rule" is thus a kind of proxy rule.

    I believe the only reason I got away with 16 TiB on a 32-bit kernel is that these were digital video servers with few simultaneous users. Since the files were relatively few and large, an fsck didn't have to juggle a huge number of directory or file inodes, and it didn't need to keep a lot of filesystem information in RAM to keep track of concurrent users.

    A good counterexample would be an email server, which may serve thousands of simultaneous users, each one wanting access to a great many small files, scattered over thousands of directories.

  3. Newer kernels raise the limit to 1,024, 4,096 or 8,192 volumes.

    Theoretically, you can get up to /dev/sdzzz.... with 29 zs, which is roughly 1041 volumes, but other practical limits will come into play first.

Warren Young
  • 72,032