Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×

EXT4 Is Coming 182

Posted by CowboyNeal from the we're-going-five-blades dept.
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."
This discussion has been archived. No new comments can be posted.

EXT4 Is Coming More

EXT4 Is Coming

Comments Filter:

  • Sounds like a good idea. (Score:5, Funny)

    by Ant P. ( 974313 ) on Saturday July 01, 2006 @08:39AM (#15642352)
    This'll fill the gap between now and when Reiser4 is declared stable - some time after Duke Nukem Forever gets released.

    • Comment removed (Score:5, Interesting)

      by account_deleted ( 4530225 ) on Saturday July 01, 2006 @10:14AM (#15642547)
      Comment removed based on user account deletion
      • Who cares? Linux has more than its fair share of filesystems, including XFS. I'm still wondering why XFS isnt used universally on desktop and server Linux installations everywhere. Is the ext2/3 just 'traditional'?
        • There are or were a few quirks.

          First off the bat: you can't install the bootloader in a XFS partition since XFS uses the first 512 byte block on the partition. Of course, most people install the bootloader in the MBR but for some it's an issue.

          GRUB had a bug with XFS. When you tried to use a XFS partition as /boot, you could corrupt XFS.

          For a considerable period of time, ext3's code was more stable than XFS.

          ext3 has an ordered data mode (which is the default). Other journaled file systems only support write
      • I've read the arguements on LKML, and it seems to me Hans isn't the only one being stubborn about filesystems and whatnot in the kernel. The kernel developers are unyielding to modernizing the VM subsystem, which is causing a lot of grief for ReiserFS.

        It's ugly, and annoying, especially for people like me who rely on ReiserFS in production. I'd love to see ReiserFS 4 in the standard kernel, it'd make my life a lot easier.

        I can't use EXT2/3, it's too slow and just kills the machine for the amount of files

      • Re:Sounds like a good idea. (Score:5, Informative)

        by hansreiser ( 6963 ) on Sunday July 02, 2006 @12:19PM (#15646237) Homepage
        What are you talking about? I said I didn't like the coding standards. I then had us change the code to conform to them.
    • Comment removed based on user account deletion
      • Didn't you mean to say the obligatory "but will it run Linux?"

        However in this case we need to flip it:

        "Will it run Vista, and will it come out before Duke Nukem Forever?"

        Oh and to for a momentary instance of reason: is it GPL-compatible? If so then I'm sure that it will support Hurd, or the reverse, Hurd will support it.
    • Well, for what it's worth, based on ReiserFS 3.6, I'd trust Reiser4 before I'd trust Ext2 (and derivatives - Ext3 is Ext2 with journaling on top) again. I've lost data more than once on Ext2, but never on Reiser. In fact, Reiser's journaling was able to rescue data for me when an ABIT motherboard caught fire (bad caps burst, the motherboard started smouldering, and one of the processors exploded and punched a hole through the board). One of the NTFS drives got scrambled, yet the Reiser drives on the same co
      • I'd trust Ext2 (and derivatives - Ext3 is Ext2 with journaling on top) again. I've lost data more than once on Ext2

        While ext3 definitely started as a fork of ext2, I'm pretty sure that it's been totally rewritten by now.
    • Reiser4 was fairly stable 1-2 years ago. We need more users to find bugs.

  • Yes but (Score:5, Interesting)

    by Anonymous Coward on Saturday July 01, 2006 @08:40AM (#15642354)
    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."

    • Re:Yes but (Score:4, Informative)

      by Anonymous Coward on Saturday July 01, 2006 @08:48AM (#15642372)
      That post makes more sense if you realize that there should be ^ marks to show exponentiation, such as 10^51 and 2^140. Otherwise it just looks like gibberish numbers that someone made up and stuck in the wiki for shits and giggles.

      • Re:Yes but (Score:2, Funny)

        by Anonymous Coward
        Nature 406, 10^47-10^54 (2000)
        Volume 406 is really thick.
    • 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.

      That is, until next week, when some guy in Peoria manages to do just that by trying to create a single mirror of all the pr0n on the Internet.
    • Wow. Imaging the size of the fan you would need to keep that hard drive cool.

    • 128 bits? (Score:3, Funny)

      by turgid ( 580780 )

      "128 bits should be enough for anyone." - Scott G. McNealy (retired).

      /me ducks.

      • Well, let's see what you can address with 128 bits. If we assume byte-addressing, it's enough for 2^128=3.4*10^38 bytes, or 2.7*10^39 bits.

        Now lets assume we want to store every bit in a single carbon atom. Carbon has a specific mass of 12 g/mol, 1 mol about 6.022*10^23 atoms. So 2.7*10^39 bits would translate to 4.5*10^15 mol, or 5.4*10^16 g, which is 54 gigatonnes of carbon.

        I doubt hard drives will get larger than that any time soon :-)
    • ...will be enough for anyone...right?

      Everytime I hear someone say "there is no way we would ever use that much data", I laugh out loud! HD cameras are coming, bandwidth is getting faster and cheaper (DSL is like $12 here in Indiana) and lets face it, people want to save EVERYTHING...weather this is good or bad is a differant topic, but the fact is, if you give people the storage, they will use it...Remember when you asked yourself "How will I ever fill this 500MB HDD?" I do...
      • I'm reporting greer2005 to Homland Security for his terrorist plot to boil the oceans.
      • For what it's worth, I'd suspect that if such amounts of storage were to become available, the current administration here in America could fill it up.

        In addition to knowing who my friends are, whom I call, and that I'm interested in aviation and fast cars, they'll be able to track which brand of mouthwash I buy (and where I buy it), who my dentist is, how much I've spent on my teeth, which brand of toilet tissue I buy (because only terrorists buy Scotts, right?), how many times I've read 1984 over the year
        • the current administration here in America could fill it up.

          Blah blah blah I hate Bush blah blah Bush is Evil blah blah blah I have no independent thoughts blah blah blah.

          Build the storage, and SOMEBODY will fill it up, probably the government (not necessarily just the current administration by the way) with tracking every inane detail of our lives

          Man, where have you been the past 10 years? Credit card companies, banks, insurance companies, big retailers (Wal-Mart, Blockbuster, NetFlix, Amazon, etc, etc, e
      • The number of particles in the Universe is estimated at around 10^89 (high estimates). This is about 2^270 (I can't be bothered to calculate the correct number).

        That should put 2^128 in perspective when it comes to adressing. Also see the posts about how much energy it would take to store this amount of data.

        Really there comes a time when "... enough for anyone" really is enough for anyone. Unless you're building Deep Though or similar computers.

  • LWN article on ext4 (Score:5, Informative)

    by ElMiguel ( 117685 ) on Saturday July 01, 2006 @08:42AM (#15642360)
    LWN [lwn.net] had an interesting article on ext4 [lwn.net] not long ago.
  • What about a modularizable filesystem, which can be upgraded with modules for compression, encryption, larger file support etc. ? Is this impossible or is it a unkown area for the linux developers?

    • Re:Modularizable filesystem (Score:5, Informative)

      by Bogtha ( 906264 ) on Saturday July 01, 2006 @09:00AM (#15642393)

      Reiser4 does this [namesys.com].

      • Interesting article - the premise that Reiser is more stable than ext3 "because it has been out longer", the quote from Adam Smith, the ridicule of the unix approach of everything as a file and all the naked people covered in newsprint?

        Anyone have a "more technical" link without dancing trees and with a bit about how to recover your filesystem when something goes weird with the hardware even if the filesystem is perfect?

        • Re:Modularizable filesystem (Score:5, Insightful)

          by Bogtha ( 906264 ) on Saturday July 01, 2006 @10:01AM (#15642509)

          the premise that Reiser is more stable than ext3 "because it has been out longer"

          It's dishonest to put something in quotes when it's not a direct quote. The exact quote is:

          "We don't touch the V3 code except to fix a bug, and as a result we don't get bug reports for the current mainstream kernel version. It shipped before the other journaling filesystems for Linux, and is the most stable of them as a result of having been out the longest. We must caution that just as Linux 2.6 is not yet as stable as Linux 2.4, it will also be some substantial time before V4 is as stable as V3."

          There's a substantial difference between saying that something is more stable "as a result" of something and more stable "because" of something. He's not claiming that being out longer intrinsically makes it more stable as your misquote suggests, he's claiming that it led to reiserfs becoming more stable - because of the practices he mentioned.

          In short - something being out longer == more stable? No. Something being exposed to lots of real-world use and receiving only bugfixes == more stable? Yes.

          the quote from Adam Smith

          He didn't quote Adam Smith, he drew an analogy between what he was saying and the network effect. It's an entirely reasonable analogy.

          the ridicule of the unix approach of everything as a file

          What ridicule? He's actually supporting that approach. For example:

          Can we do everything that can be done with {files, directories, attributes, streams} using just {files, directories}? I say yes--if we make files and directories more powerful and flexible. I hope that by the end of reading this you will agree.

          Would you care to point out where you thought he was ridiculing the UNIX approach?

          all the naked people covered in newsprint

          Yeah, they look dumb, don't they?

          Anyone have a "more technical" link

          I can only assume you mean something other than "technical".

          without dancing trees

          Dancing trees are a fundamental part of the design. How are you meant to understand the filesystem without understanding dancing trees?

          and with a bit about how to recover your filesystem when something goes weird with the hardware even if the filesystem is perfect?

          Ah, you don't mean technical at all, you mean practical for somebody who is entirely uninterested in the way the filesystem works. Perhaps Reiser4 Transaction Design Document [namesys.com] is what you are after, but I doubt it.

          • Sorry it's beyond midnight in this part of the world - so here is the correct quote:

            "and is the most stable of them as a result of having been out the longest"

            The context is supplied in the article and the portion above - do you see what I am getting at here and why I do not agree that it is a definition of stability? It certainly gives me no confidence to the questions of stability and recovery, which I'm sure are answered elsewhere, but no - I didn't think much of the article - perhaps the annoying graph

        • You can't really get more technical about filesystems than talking about things like dancing trees and other algorithms for storing and retrieving data quickly, safely, and efficiently. Don't forget, Hans Reiser is a filesystem expert, so don't expect his site to not have that sort of information on it.
          • OK - I should have phrased that as without pictures of people pretending to be trees that are dancing, or even pictures of leafy trees dancing. Something boring with only the sort of diagrams and descriptions you would see in a published paper would be nice.
      • Like the Abrams tank going 60 miles an hour, ReiserFS is fine for doing all sorts of amazing things, once. Actually being trying to recover any data from ReiserFS if any hardware errors creep in, such as a failing drive in a RAID array, is like the drive train seizing up on the Abrams: it's a big development effort to get spectacular features which don't actually work well in the field.

        Ext2 and its descendants have been less ambitious and thus considerably more robust.
    • Take a look at the device mapper and associated stuff like EVMS, LVM2, dm-crypt, etc.

      Arbitrary block device layering is the way forward.

  • ClusterFS (Score:5, Funny)

    by schon ( 31600 ) on Saturday July 01, 2006 @08:51AM (#15642377)
    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"?

  • define very large (Score:3, Insightful)

    by frovingslosh ( 582462 ) on Saturday July 01, 2006 @09:07AM (#15642404)
    OK, I've read both links. What does this mean? Can anyone give a breakdown of ext3 vs. ext4, particularly in terms of what size files and what size partitions they both support, as well as any other differences that can be quantified?

    • Re:define very large (Score:5, Insightful)

      by Kjella ( 173770 ) on Saturday July 01, 2006 @09:31AM (#15642440) Homepage
      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.
      • Let me put it this way, it's a little past the average slashdot porn collection:
        I think you underestimate the combination of lonely geeks, OCD, unemployment, broadband and wget.
        • I think you underestimate the combination of lonely geeks, OCD, unemployment, broadband and wget.

          We're talking about a dozen full 750GB hdds (with no redundancy) to hit 8TiB. That's over four grand just for the disks without controllers, never mind the broadband you need. Do tell where you can get that on unemployment benefits...
          • That's over four grand just for the disks without controllers, never mind the broadband you need. Do tell where you can get that on unemployment benefits...

            Well, "he" lives in his parents' basement, and earns some cash doing errands for them...

      • Re:define very large (Score:2, Interesting)

        by zlogic ( 892404 )
        Though this may be needed in some rare applications, I don't see ext4 as something needed in the near future. As I understand, the larger the max partition&file size, the more space indexes will need (not to mention that speed will probably drop).
        For example, if we have 20-bit indexes (2^20 clusters max) and use 4-kilobyte clusters, to increase the maximum space we'll either have to add one bit to the indexes to double the maximum space or we'll have to increase the cluster size and have problems storin

        • Re:define very large (Score:4, Informative)

          by Kjella ( 173770 ) on Saturday July 01, 2006 @11:29AM (#15642739) Homepage
          From what I understood the sector index will be configurable as either 32 or 64 bit, so pick it if you need it... Since there's no reason to use it unless the disk is that big, I imagine this can be set automaticly. Also, the whole reason this will be ext4 is that they'll change the way it stores the sectors (ranges instead of singles) which will be better for big files, and since one sector is 4kB almost any file is "big".

      • Re:define very large (Score:4, Insightful)

        by glwtta ( 532858 ) on Saturday July 01, 2006 @11:16AM (#15642703) Homepage
        ext3: 8TB total, 4TB files
        ext4: 32 zettabyte (1024*1024*1024 TB), 1 exabyte files (1024*1024 TB)

        Are they just going to work on improving the 8TB paper limitation, or are they actually trying to improve on ext3 scalability? Which, currently tends to suck the big one, especially on a significant number of disks (eg: http://scalability.gelato.org/DiskScalability/Resu lts [gelato.org]).

        I also seem to keep coming up against a pretty hard 2TB block device limit in Linux (eg LVM2 lv size, LUN size for fibre attached SAN, etc). I don't really know what the reasons for it are, anyone know what technologies allow for larger single partitions?

        Anyway, I've long ago settled on reiserfs (3) for speedy random access to small files, and XFS for file server type applications; though I still wonder why RedHat doesn't include any "enterprise" filesystems by default in their "enterprise" products (I know, I know, you can enable it - I did say "by default").
    • Everyone sweats out the file and FS size limits, but it's amazing to me that Linux's most popular filesystem still limits you to under 32K directories at one level in a directory. Does ext4 address this? Why not?

      I realize this is irrelevant for most people, but for some of us it's crucial.
      • Linux's most popular filesystem still limits you to under 32K directories at one level in a directory.

        Something's wrong with your data layout if you need to put 32,767 directories at a single level.

  • LKML Message (Score:3, Informative)

    by Anonymous Coward on Saturday July 01, 2006 @09:20AM (#15642427)
    The kernel mailing list message:

    Subject Proposal and plan for ext2/3 future development work
    From "Theodore Ts'o"
    Date Wed, 28 Jun 2006 19:55:39 -0400

    Given the recent discussion on LKML two weeks ago, it is clear that many
    people feel they have a stake in the future development plans of the
    ext2/ext3 filesystem, as it one of the most popular and commonly used
    filesystems, particular amongst the kernel development community. For
    this reason, the stakes are higher than it would be for other
    filesystems. The concerns that were expressed can be summarized in the
    following points:

    * Stability. There is a concern that while we are adding new
    features, bugs might cause developers to lose work.
    This is particularly a concern given that 2.6 is a
    "stable" kernel series, but traditionally ext2/3
    developers have been very careful even during
    development series since kernel developers tend to get
    cranky when all of their filesystems get trashed.

    * Compatibility confusion. While the ext2/3 superblock does
    have a very flexible and powerful system for
    indicating forwards and backwards compatibility, the
    possibility of user confusion has caused concern by
    some, to the point where there has been one proposal
    to deliberately break forwards compatibility in order
    to remove possible confusion about backwards
    compatibility. This seems to be going too far,
    although we do need to warn against kernel and
    distribution-level code from blindly upgrading users'
    filesystems and removing the ability for those
    filesystems to be mounted on older systems without an
    explicit user approval step, preferably with tools
    that allow for easy upgrading and downgrading.

    * Code complexity. There is a concern that unless the code is
    properly factored, that it may become difficult to
    read due to a lot of conditionals to support older
    filesystem formats.

    Unfortunately, these various concerns were sometimes mixed together in
    the discussion two months ago, and so it was hard to make progress.
    Linus's concern seems to have been primarily the first point, with
    perhaps a minor consideration of the 3rd. Others dwelled very heavily
    on the second point.

    To address these issues, after discussing the matter amongst ourselves,
    the ext2/3 developers would like to propose the following path forward.

    1) The creation of a new filesystem codebase in the 2.6 kernel tree in /usr/src/linux/fs/ext4 that will initially register itself as the
    "ext3dev" filesystem. This will be explicitly marked as an
    CONFIG_EXPERIMENTAL filesystem, and will in affect be a "development
    f

  • Why EXT4 ? (Score:4, Interesting)

    by Anonymous Coward on Saturday July 01, 2006 @09:36AM (#15642449)
    Ext4 is an extention of ext3, much like ext3 is an extention of ext2. The plan is to ensure backwards compatability and sanity for when things break, and with filesystems.. things break.

    There are many factors that influence filesystems, not just "how fast it can write", but rather.. how it breaks when it does.

    While the fanboys of XFS, JFS, ZFS may promise that their filesystems are faster, had no problems, secure and will not eat your data, it simply is not as proven as ext2 and ext3.

    Scream fanboys scream, someone will listen, but the problem is that these filesystems are not proven in the field, or in some circumstances even in the kernel itself.

    • Re:Why EXT4 ? (Score:5, Informative)

      by Frumious Wombat ( 845680 ) on Saturday July 01, 2006 @09:51AM (#15642486)
      Actually, XFS (SGI), JFS (IBM), and ZFS (Sun) are very well proven in the field, on their respective native operating systems. Given the situations they're used in (financial sector, pharmaceutical research data, supercomputing), they're far more proven that EXT(anything). Now, whether the average Linux user knows how to install, tune, and use them is a different issue, but if I were worried about scalable, mission-critical, filesystems, those three would be on the top of my list. (and my personal history says that while XFS never gave me any trouble, JFS would be my first choice. Nobody ever let me have a budget large enough to buy a machine that would justify ZFS).

      With IBM's know-how in the mix, EXT4 may be able to join the above three, but it would seem to be time better spent fixing XFS/JFS support in Linux first, rather than worrying about backwards compatibility with EXT2.

      • Re:Why EXT4 ? (Score:4, Informative)

        by Znork ( 31774 ) on Saturday July 01, 2006 @10:20AM (#15642564)
        "ZFS (Sun) are very well proven in the field"

        Um, I have yet to see a production installation of ZFS in an enterprise environment, and it hasn't been out as an actual release for even a year yet. You probably mean UFS. HTH.

        • Um, I have yet to see a production installation of ZFS in an enterprise environment...

          Then you haven't been looking very hard. SUN has been using ZFS internally in their enterprise environment for a while. In addition, there are several special customers that were using ZFS in production working closely with SUN engineers. Not only that, I know of a hosting company that posted about using ZFS already for their production environment. In addition, ZFS is now officially supported and part of Solaris 10 as of

          • Re:Why EXT4 ? (Score:3, Insightful)

            by kimvette ( 919543 )

            SUN has been using ZFS internally in their enterprise environment for a while.

            Most people would not consider that to be "proven in the field"

            By your logic, Windows Vista should have been released a year ago because it's long been "proven" stable via widespread deployment at Microsoft.

            Internally, Sun has Sun software running mostly on Sun hardware, not the mis-mash of SANs, external and internal third-party hard drives, and custom RAIDs that many enterprises will have. When it's used and stable across a vari

        • Re:Why EXT4 ? (Score:3, Informative)

          by Builder ( 103701 )
          Actually, I think you'll find that ZFS has been out as a production release (GA or Generally available) for just under 2 weeks now. That's weeks!

          There is no way in hell that ZFS is even _remotely_ proven in the field. And since we're still fighting with a bug with Sun Disksuite where you can't boot off the second disk when a disk in a mirror breaks, I'd be VERY loathe to mention Sun, Filesystems and Disk management as being stable right now.

      • fsck quality (Score:5, Informative)

        by r00t ( 33219 ) on Saturday July 01, 2006 @10:27AM (#15642582) Journal
        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.
        • I've had e2fsck crash with a segfault, fairly recently, on an Mac. This was with Debian unstable, so I downloaded a static build of e2fsck from the web to try a more conservative solution, and that would also crash. It didn't cause that many problems, because I could still read the FS, backed it up somewhere else, and recreated the FS. Reiserfsck had no problem fixing the other FSes (I have had loads of FS related problems with this machine, probably because it writes gibberish to the disk when the power is
          • Wow, it's been a damn long time since I've heard of such a thing. It would be nice if you'd have contacted tytso@mit.edu to ensure that your filesystem gets into the test suite.

            The fact that HFS+ is so unreliable is a bit worrying. While lower reliability is to be expected, failures should still be rare. Perhaps your hardware has some minor (or not so minor) memory problems.
            • I think the problems are caused by the disk cache being corrupted before it's properly flushed. This is an old laptop, and it probably doesn't expect 16 MB of cache. It usually gets uptimes of several weeks, so I don't think it's the system memory.

              Unfortunately, I no longer have Linux installed on it, and I rebuilt the filesystem anyway.
        • There basically is no fsck for XFS

          Really. What are xfs_check and xfs_repair for then?

          • You'll find out what they are when you find yourself wanting a fsck program.

            Hint: they barely do anything, if you are lucky.
            • Nonsense. xfs_repair runs over half a dozen checks on metadata. I've done it and watched it and it is thorough. The only problem is running it on 32 bit architectures with a 13TB filesystem, when it runs out of memory address space at around phase 7. That's curable with an Operton.

        • Re:fsck quality (Score:3, Interesting)

          by hansreiser ( 6963 )
          ext2fsck has a history of plenty of problems, just like everyone. I get reports from users swearing they will never again use ext*. Ted Tso goes walking around FUD'ing everyone else's fsck. He does this because ext* performance is poor, so there is not much else to do but FUD. Some users suspect that high performance is a little sinful, so this works on some.

          All of the major filesystems have a decent fsck, and all of them are by now stable to the point that you should worry about your hardware and backu
      • Mod parent up -- oh he had 5 points -- still give it a try.

        Please complete the following;

        We need another enterprise file system;

        - like we need another web browser.
        - like we need another Window manager.
        - like we need another Bourne shell derivative.
        - more than we need improved network filesystem support.
        - more than we need Hans Reiser to rip out the limitations of the VFS from the kernel.
        - because the other Enterprise level filesystems just don't support big enough filesystems/files.
        - because the other Enter
      • I'm not using their native operating systems, so how stable the filesystems are there doesn't really affect me. What matters to me is whether the code in Linux that uses them is stable.
    • "While the fanboys of XFS, JFS, ZFS may promise that their filesystems are faster, had no problems, secure and will not eat your data, it simply is not as proven as ext2 and ext3."

      I am sorry, but you got this quite the wrong way around :)

      XFS and JFS have been used in enterprise enviroments far longer than EXT2 (not to mention EXT3) has been in existance.

      • Re:Why EXT4 ? (Score:3, Interesting)

        by Carewolf ( 581105 )
        In enterprise.. Exactly!

        Note that servers with extensive mirroring and other hardware error-handling rarely need error-recovery from the filesystem. Filesystem errors happen on ordinary peoples harddrives when they grow old, and ext* have a million times more experience in the handling those than any enterprise FS..

      • I got this:

        xfs_force_shutdown(sdb1,0x8) called from line 1088 of file
        fs/xfs/xfs_trans.c. Return address = 0xf8c3043b
        Filesystem "sdb1": Corruption of in-memory data detected. Shutting down
        filesystem: sdb1
        Please umount the filesystem, and rectify the problem(s)

        Last week on a debian sarge box runing 2.6.8 while setting up a file system on a box that built, ran and read from ext3 just fine. A format and reinstall of the 400GB array got XFS working on the second try.

        This was minutes after creating the partitio

      • Also, if choosing between data integrity and performance, one should choose integrity (unless doing something like heavy NLE where the data is not stored locally, just pulled down to get work done). Just as with RAID-5 vs. "RAID-0" there are advantages for performance and there are advantages of integrity with a (hopefully minor) performance penality with various filesystems.

  • Why only 48 bits? (Score:3, Insightful)

    by The Wicked Priest ( 632846 ) on Saturday July 01, 2006 @09:41AM (#15642461)
    Why not go all the way to 64 bits now, and thereby avoid further changes for the forseeable future? In one of the messages linked from the article, it's suggested that 1024 PB, obscene as it sounds, may only be good enough for another decade.

    I guess we'll be on to ext5 or 6 by then, though.

    • Re:Why only 48 bits? (Score:5, Interesting)

      by r00t ( 33219 ) on Saturday July 01, 2006 @09:59AM (#15642499) Journal
      With a block size of 32 kB (64 kB is expected to be supported soonish) the 48-bit numbers will take you 1 byte over the maximum file size that apps can support. There is no UNIX-like OS that lets an app handle files bigger than 2**63.

      We'll need to adjust other things if filesystems ever get so huge. The whole design probably needs a rethink, but we can't do it now. We don't know what the future holds in terms of seek times, transfer rates, sector sizes, etc.
    • Why stop at 64 bits? It may seem excessive now, but so did the 2GB limitation of the original IDE implementation (even though IDE included large-disk addressability in the original design the common implementation did not include the full feature set) when "huge" hard drives were just 80MB, and each time it has been extended we've hit the limit, with 32GB limits and 137GB limits. I realize there has to be some decision about where to draw the line but why not make it TWICE as wide as we can imagine technol

  • Pattern (Score:5, Funny)

    by Eudial ( 590661 ) on Saturday July 01, 2006 @10:09AM (#15642532)
    Ext2...Ext3...Ext4

    Wait... I think I can detect a pattern. The next number has to be Ext7½!

  • Linux and other Unix FSes (Score:4, Insightful)

    by digitalhermit ( 113459 ) on Saturday July 01, 2006 @11:27AM (#15642734) Homepage
    I'm as big a Linux fan as anyone, but one glaring thing that it needs is some better filesystem tools. Don't get me wrong -- they've come a long way in the last couple years -- but compared to something like AIX it still has a little ways to go. Here's one feature that causes a challenge: Linux filesystems and the underlying logical volume layer is largely decoupled. You have an immense amount of flexibility but as a consequence, the filesystem and volume layers don't always communicate as well. For example, the AIX JFS2 tools allow you to dynamically grow/shrink filesystems. This functionality exists in Linux for some filesystems (EXT3, ReiserFS) but the procedure varies depending on how the filesystem is constructed. And at this point, I'm not fully convinced of its stability as I've recently (three months ago) lost an entire disk after a dynamic resize on an LVM backed EXT3 partition. I have yet to reproduce the failure but it occurred with a 95% full /home and a kernel compile going full tilt.

    But I'm amazed at how quickly these features are being integrated. There's functionality in Linux that allows me to easily create file-backed volumes, remote volumes, SAN LUNs, etc.. The "resize in a single command" is not fully there yet, but within 6 months I'd expect it to be.

    • Re:Linux and other Unix FSes (Score:4, Insightful)

      by Homology ( 639438 ) on Saturday July 01, 2006 @12:55PM (#15642958)
      >I'm as big a Linux fan as anyone, but one glaring thing that it needs is some better filesystem tools.

      I'm pretty certain that Linux would have better filesystem tools if the developers could resist add a new filesystem every few months.
    • Your comment on filesystem tools led me to think about one particular tool I'd love to have: I would like to know whether metadata --more specifically, my user comments on the file-- would be a component of the proposed ext4.

      As an example of when I would like to annotate files: sometimes I download a file --let's say it's a program for my Palm, called "VP2.pdb". Now, that filename could mean just about anything; let's say it was some image viewer named "ViewPicture II", so I would like to rename it "ViewPi
      • A far simpler solution to the specific problem you mention:

        [root@flathat example]# ls -l
        total 4
        -rw-r--r-- 1 root root 2692 Jul 2 10:03 VP2.pdb
        [root@flathat example]# ln -s VP2.pdb ViewPicture2.pdb
        [root@flathat example]# ls -l
        total 4
        lrwxrwxrwx 1 root root 7 Jul 2 10:03 ViewPicture2.pdb -> VP2.pdb
        -rw-r--r-- 1 root root 2692 Jul 2 10:03 VP2.pdb
  • The main described change / advantage in this proposed ext4 is that the notion that a file's allocation is tracked via "extents" (a specified number of contiguous 2k blocks) rather than a chain of inode pointers (with up to 3 levels of indirection).

    This is based not only on the need for a larger maximum file system, but a recognition that there is significant performance advantage to reducing read/write head movement and initiating large reads from consecutive blocks that can take advantage of the high tran
  • will i be able to upgrade from ext3 to ext4?
  • If they're going to make an ext4, why not add access control lists and extended attributes, which have been sorely needed for some time?

    melissa

Slashdot Top Deals

2 pints = 1 Cavort

Close