Slashdot Mirror


EXT4 Is Coming

ah admin writes "A series of patches has been proposed in Linux kernel mailing list earlier by a team of engineers from Red Hat, ClusterFS, IBM and Bull to extend the Ext3 filesystem to add support for very large filesystems. After a long-winded discussion, the developers came forward with a plan to roll these changes into a new version — Ext4."

7 of 182 comments (clear)

  1. Sounds like a good idea. by Ant+P. · · Score: 5, Funny

    This'll fill the gap between now and when Reiser4 is declared stable - some time after Duke Nukem Forever gets released.

  2. Yes but by Anonymous Coward · · Score: 5, Interesting
    Yes, but will it be enough if you had energy to boil all the oceans?

    Interesting bit from wiki/ZFS:
    ZFS is a 128-bit file system, which means it can provide 16 billion billion times the capacity of current 64-bit systems. The limitations of ZFS are designed to be so large that they will never be encountered in any practical operation. When contemplating the capacity of this system, Bonwick stated "Populating 128-bit file systems would exceed the quantum limits of earth-based storage. You couldn't fill a 128-bit storage pool without boiling the oceans."

    In reply to a question about filling up the ZFS without boiling the ocean, Jeff Bonwick, an engineer at Sun Microsystems who led the team in developing ZFS for Solaris, offered this answer:

    "Although we'd all like Moore's Law to continue forever, quantum mechanics imposes some fundamental limits on the computation rate and information capacity of any physical device. In particular, it has been shown that 1 kilogram of matter confined to 1 liter of space can perform at most 1051 operations per second on at most 1031 bits of information [see Seth Lloyd, "Ultimate physical limits to computation." Nature 406, 1047-1054 (2000)]. A fully-populated 128-bit storage pool would contain 2128 blocks (nibbles) = 2137 bytes = 2140 bits; therefore the minimum mass required to hold the bits would be (2140 bits) / (1031 bits/kg) = 136 billion kg.

    To operate at the 1031 bits/kg limit, however, the entire mass of the computer must be in the form of pure energy. By E=mc2, the rest energy of 136 billion kg is 1.2x1028 J. The mass of the oceans is about 1.4x1021 kg. It takes about 4,000 J to raise the temperature of 1 kg of water by 1 degree Celsius, and thus about 400,000 J to heat 1 kg of water from freezing to boiling. The latent heat of vaporization adds another 2 million J/kg. Thus the energy required to boil the oceans is about 2.4x106 J/kg * 1.4x1021 kg = 3.4x1027 J. Thus, fully populating a 128-bit storage pool would, literally, require more energy than boiling the oceans."
  3. LWN article on ext4 by ElMiguel · · Score: 5, Informative

    LWN had an interesting article on ext4 not long ago.

  4. ClusterFS by schon · · Score: 5, Funny

    engineers from Red Hat, ClusterFS, IBM

    OK, hands up - who wants to run ClusterFS so that they can say they needed to do a "clusterfsck"?

  5. Re:Modularizable filesystem by Bogtha · · Score: 5, Informative
    --
    Bogtha Bogtha Bogtha
  6. Re:define very large by Kjella · · Score: 5, Insightful

    Let me put it this way, it's a little past the average slashdot porn collection:

    ext3: 8TB total, 4TB files
    ext4: 32 zettabyte (1024*1024*1024 TB), 1 exabyte files (1024*1024 TB)

    Beyond that, it doesn't seem to actually change much.

    --
    Live today, because you never know what tomorrow brings
  7. fsck quality by r00t · · Score: 5, Informative

    Nobody has a fsck that can compare to e2fsck (ext2/ext3/etc.) for quality.

    The e2fsck program has a huge test suite that it must pass before a release. A set of corrupted filesystems must be correctly repaired to be bit-for-bit identical to the desired result.

    A typical fsck has a good chance of crashing (SIGSEGV, the "segmentation violation") when the going gets tough.

    While FreeBSD's UFS developers were messing around with sync writes to avoid testing a fsck that would often crash, the ext2 developers ran full async and wrote a damn fine fsck to put things back in order. Now you can choose from three different levels of journalling, and you still get the ass-kicking fsck program.

    There basically is no fsck for XFS, Reiserfs, or Reiser4. JFS doesn't have much AFAIK, and ZFS is a newborn.

    What are you going to do when your fancy filesystem gets trashed? I hope you keep excellent backups, very recent and tested to be readable.