http://lwn.net/Articles/320284/Anatomy of ext4 (developerWorks)
developerWorks has posted a
detailed look at the ext4 filesystem. "One
of the first visible differences in ext4 is the increased support for
file system volumes, file sizes, and subdirectory limits. Ext4 supports
file systems of up to 1 exabyte in size (1000 petabytes). Although that
seems huge by today's standards, storage consumption continues to grow,
so ext4 was definitely developed with the future in mind. Files within
ext4 may be up to 16TB in size (assuming 4KB blocks), which is eight
times the limit in ext3."
(Log in to post comments)
Anatomy of ext4 (developerWorks) Posted Feb 23, 2009 16:22 UTC (Mon) by nix (subscriber, #2304) [Link] Factually this looks accurate enough, but article's phrasing just rubs me the wrong way. Why does someone writing something that's supposed to be relatively technical find it necessary to stick in heaps of marketing hyperbole? 'Why it will be your new favorite file system' and much else tries to make ext4 seem like a huge and radical revamp, when the whole point of it was that it was not radical; that it was boring enough that all current ext3 users could migrate over easily. Describing ext4 as a 'surprise' is equally silly (who to? anyone who cared about the release of new filesystems in brand-new upstream kernels would have been reading LWN or the l-k list anyway, so it would not be surprising to them; and ext4 development has proceeded in public for years, so is hardly concealed enough to be surprising)...This was satisfactory in many settings, but as processors evolve with higher speeds and greater integration (multi-core processors) and Linux finds itself in other application domains such as high-performance computing, the seconds-based timestamp fails in its own simplicityThis is purest bunkum, unless make(1) is an example of a high-performance-computing application, and I really can't see any connection between subsecond timestamps and multicore CPUs! Finegrained timestamps are useful all over the shop. The article says that extents have been used in other filesystems before, but then describes the use of extents as 'breaking new ground in areas of file system metadata management' --- assuming that this was what it was talking about. (That phrase appears in a heading but nothing groundbreaking is described in the section it heads, so it could have been referring to anything at all.) It describes preallocation as providing 'bounded Read performance'. It's no more bounded than non-preallocated reads are: it's just likely to be faster due to fragmentation reduction. It says that 'ext4 includes numerous self-protection and self-healing mechanisms', but then describes journal checksumming (OK) and, er, online defragmentation (neither a self-protection nor a self-healing mechanism). ext4 isn't especially radical in this area: data is not checksummed, nor is all metadata (IIRC). And as for the closing line: Although it's too early to know what's coming for ext5, it's clear that it will lead the way for enterprise-ready Linux systems.It's nice to know that Tim Jones has a time machine, but the rest of us generally refrain from speculating in authoritative tones about things that haven't even been proposed let alone designed or implemented. I suspect that btrfs or one of the other next-gen filesystems are more likely to take the crown by the time ext5 rolls around (if it ever does). This is all small-beer moaning about a generally good article, really: I just wish people would stop overhyping interesting and useful non-radical changes as if they were the biggest thing since the invention of Unix.
Anatomy of ext4 (developerWorks) Posted Feb 23, 2009 17:54 UTC (Mon) by xorbe (guest, #3165) [Link] Are "internet average" articles like this
indicating that Linux is reaching a slightly wider audience these days
perhaps?
Anatomy of ext4 (developerWorks) Posted Feb 23, 2009 21:57 UTC (Mon) by proski (subscriber, #104) [Link] Factually this looks accurate enoughNo, it's not accurate at all. There was no "ext1" filesystem. Just check Linux 1.2.13. The sources are in fs/ext and there is no "ext1" in the sources. The only reference to "ext1" is in drivers/net/README.arcnet-jumpers, but it has nothing to do with filesystems.
Anatomy of ext4 (developerWorks) Posted Feb 23, 2009 22:42 UTC (Mon) by nix (subscriber, #2304) [Link] Ah. Missing that one dates me, I'm afraid
:)
I was worried about being castigated for overdoing the criticism, but
it
Anatomy of ext4 (developerWorks) Posted Feb 24, 2009 4:23 UTC (Tue) by k8to (subscriber, #15413) [Link] I'd say extfs can be called ext1
reasonably. I think we all know what it means.
Anatomy of ext4 (developerWorks) Posted Feb 23, 2009 17:58 UTC (Mon) by jengelh (subscriber, #33263) [Link] >file sizes [16TB], and subdirectory
limits. Ext4 supports file systems of up to 1 exabyte in size (1000
petabytes). As usual, the author has forgotten to look at other filesystems,
e.g. xfs: - single file size (per WP): 8 EB
And XFS exclusive Posted Feb 23, 2009 19:55 UTC (Mon) by khim (subscriber, #9252) [Link] - Nasty bugs: for almost 5 years. People claim last serious bug in Linux port was fixed in 2007, but by this time I was biten by XFS enough to strike out it from "filesystems for consideration" list. Sure hope ext4 will not beat this record...
And XFS exclusive Posted Feb 23, 2009 20:55 UTC (Mon) by jengelh (subscriber, #33263) [Link] Oh yeah crash here crash there, we all
had it. reiserfs, ext2, unionfs, and all the others filesystems too.
And XFS exclusive Posted Feb 24, 2009 4:25 UTC (Tue) by k8to (subscriber, #15413) [Link] I don't relish the rehash, but not all
filesystems have had the same track record.
I'm the guy running reiserfs for my mp3 directory, anyway, just to
see
if it would screw up (from back when it was "hot"). Answer, yes, it
does screw up, just like they said.
Anatomy of ext4 (developerWorks) Posted Feb 23, 2009 18:38 UTC (Mon) by nowster (subscriber, #67) [Link] The other thing to note is that ext4 doesn't have online defragmentation yet. There are several proposals and some implementations, but none has matured enough to reach the mainline kernel. |
