Slashdot Mirror

← Back to Stories (view on slashdot.org)

Linux Breaks 100 Petabyte Ceiling

Posted by timothy on from the no-stick-is-large-enough-to-shake dept.

*no comment* writes: "Linux has broken the barrier with the 100 petabyte ceiling, and doing it at 144 petabytes." And this is even more impressive in pebibytes, too.

4 of 330 comments (clear)

  1. XFS by starrcake · · Score: 5, Informative

    http://oss.sgi.com/projects/xfs/features.html

    XFS is a full 64-bit filesystem, and thus, as a filesystem, is capable of handling files as
    large as a million terabytes.

    263 = 9 x 1018 = 9 exabytes

    In future, as the filesystem size limitations of Linux are eliminated XFS will scale to the
    largest filesystems

  2. Article got it wrong on BeOS - 18 EXAbytes! by Snard · · Score: 5, Informative

    Just a side note: BeOS has support for files up to 18 exabytes, not 18 petabytes, as stated in the article. This is roughly 18,000 petabytes, or 2^64 bytes.

    Just wanted to set the record straight.

    --
    - Mike
  3. 1st desktop OS? Well, not quite. by mr · · Score: 5, Informative

    Before you start thumping your chest about how superior or cutting edge *Linux is, go look at these two links
    A slashdot story pointing out how without the FreeBSD ATA code, the Linux kernel would be 'lacking'
    The FreeBSD press release announcing the code is stable

    If The Reg actually researched the story, Andy would have notice it is not a 'first' but more a 'dead heat' between the 2 leading software libre OSes. Instead, The Reg does more hyping of *Linux.

    --
    If it was said on slashdot, it MUST be true!
  4. Reality check... by Anonymous Coward · · Score: 5, Informative
    Does anybody realize, that, even with a data rate of the order of 1GB/s, much higher than what current platters can do, it takes about 5 years to fill such a disk.

    I'm already fed up of the time it takes to back up large disks to tape. Drive transfer rate has not improved at the rate of disk capacity in the last few years and is becoming a bottleneck. It was unimportant when the backup time of a single disk was well below one hour (our Ultrium tapes give about 40Gb/hour).

    Just figure that if you want to transfer 144PB in about one day, you need a transfer rate of the order of 1TB/s. Electronics is far from there since it means about 10 terabits/second. Even fiber is not yet there. Barring a major revolution, magnetic media and heads can't be pushed that far. At least it is way further than the foreseeable future.

    Don't get me wrong, it is much better to have more address bits than needed to avoid the painful limitations of 528 Mb, 1024 cylinders etc... But, as somebody who used disks over 1Gb on mainfranmes around 1984-1985, I easily saw all the limitations of the early IDE interfaces (with the hell of CHS addresses and its ridiculously low bit numbers once you mixed the BIOS and interface limitations) and insisted on SCSI on my first computer (now CHS is history thanks to LBA, but the transition has been sometimes painful).

    However, right now big data centers don't always use the biggest drives because they can get more bandwidth by spread the load on more drives (they are also slightly wary of the greatest and latest because reliability is very important). Backing up starts to take too much time,

    In short, the 48 bit block number is not a limit for the next 20 years or so. I may be wrong, but I'd bet it'll take at least 15 years, perhaps much more because it is too dependent on radically new technologies and the fact that the demand for bandwidth to match the increase in capacity will become more prevalent. Increasing the bandwidth is much harder since you'll likely run into noise problems, which are fundamental physical limitations.