text: Linux: ext4 Filesystem | KernelTrap
  Home Linux: ext4 Filesystem
  From: Theodore Ts'o [email blocked]
  Subject: Proposal and plan for ext2/3 future development work
  Date:	Wed, 28 Jun 2006 19:55:39 -0400
  filesystems, particular amongst the kernel development community.  For
  filesystems.  The concerns that were expressed can be summarized in the
  * Stability.  There is a concern that while we are adding new
  * Compatibility confusion.  While the ext2/3 superblock does
  compatibility.  This seems to be going too far,
  * Code complexity.  There is a concern that unless the code is
  perhaps a minor consideration of the 3rd.  Others dwelled very heavily
  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
  fork" of ext3.  A similar split of the fs/jbd will be made in order to
  support 64-bit jbd, which will be used by fs/ext4 and future versions
  of ocfs2.
  2) Bug fixes to fix 32-bit cleanliness issues, security/oops problems
  will go into fs/ext3, but all new development work will go into fs/ext4.
  There is some question about whether relatively low risk features such
  as slimming the extX in-core memory structure, and delayed allocation
  for ext3, which have no format impacts, should go into fs/ext3, or
  whether such enhancement should only benefit fs/ext4 users.  This is a
  cost/benefit tradeoff for which the guidance of the LKML community about
  whether the loss in code stability is worth the improvements to current
  ext3 users, given the existence of the development branch.
  In addition, we are assuming that various "low risk" changes that do
  involve format changes, such as support for higher resolution
  timestamps, will _not_ get integrated into the fs/ext3 codebase, and
  that people who want these features will have to use the
  stable/development fs/ext4 codebase.
  3) The ext4 code base will continue to mount older ext3 filesystems,
  as this is necessary to ensure a future smooth upgrade path from ext3
  to ext4 users.  In addition, once a feature is added to the ext3dev
  filesystem, a huge amount of effort will be made to provide continuing
  support for the filesystem format enhancements going forward, just as
  we do with the syscall ABI.  (Emergencies might happen if we make a
  major mistake and paint ourselves into a corner; but just as with
  changes to the kernel/userspace ABI, if there is some question about
  whether or not a particular filesystem format can be supported going
  forward indefinitely, we will not push changes into the mainline
  kernel until we are can be confident on this point.)
  4) At some point, probably in 6-9 months when we are satisified with the
  set of features that have been added to fs/ext4, and confident that the
  filesystem format has stablized, we will submit a patch which causes the
  fs/ext4 code to register itself as the ext4 filesystem.  The
  implementation may still require some shakedown before we are all
  confident that it is as stable as ext3 is today.  At that point, perhaps
  12-18 months out, we may request that the code in fs/ext3/*.c be deleted
  and that fs/ext4 register itself as supporting the ext3 filesystem as
  We believe this should satisfy most of the concerns that were
  articulated, in particular those that Linus and Jeff were most concerned
  about.  Comments are of course appreciated.
  Just a link... Gnux (not verified)
  June 30, 2006 - 4:13am
  It's just some link to understand why there is discussion about a new implementantation of the extended file system.
  Here: http://www.uwsg.iu.edu/hypermail/linux/kernel/0606.1/0268.html
  All the discussion that precedes Tso post :)
  Use the KISS principle, please! Anonymous (not verified)
  June 30, 2006 - 3:59pm
  ext4 = ext3 + 2 GiB maxfilesize removing + "4th or 5th level of blocks' trie".
  http://www.bullopensource.org Anonymous (not verified)
  July 1, 2006 - 12:23am
  "The limit of ext2/ext3 filesystem is 2 TB with 1kB blocks, and 8 TB with 4 kB blocks."
  I think the max file size is 2 TB. Don't confuse ext2/3 with FAT32 ;)
  Ext3 will be good enough for most users for years to go. IMO they should drop backwards compatibility and make ext4 simpler than ext3.
  yes,I think so Anonymous (not verified)
  July 1, 2006 - 5:00am
  no need the backwards compatibility
  Older programs and kernels Anonymous (not verified)
  July 1, 2006 - 1:12pm
  While that's true now, IIRC older kernels couldn't handle files > 2GB, and neither can older apps. I don't think that was ever really a filesystem issue (though it could've been VFS related) though.
  you just don't understand. i' Anonymous (not verified)
  July 1, 2006 - 11:12pm
  you just don't understand. i've got laptop. i've got few servers. all with ext3. i'd like to move to ext4. why should i care about migration? wouldn't it be simple to just do s/ext3/ext4 in /etc/fstab? if so, I vote for backward comptabilitity definitely.
  ext3 is quite a mess and it c Anonymous (not verified)
  July 2, 2006 - 2:22pm
  ext3 is quite a mess and it can't be cleaned up without removing backwards compatibility. Guess why ext3 directory handling code still uses buffer heads but ext2 doesn't. Simplicity is very important especially in FS code. Less backwards compatibility, less code, less bugs.
  BTW, the features planned for ext4 are not useful for majority of users, at least for now. It wouldn't make much sense to upgrade from ext3 to ext4.
  ext3 uses buffer heads becaus Anonymous (not verified)
  July 3, 2006 - 2:18am
  ext3 uses buffer heads because of jbd which is build around bh. and if you need journaling you need to track blocks belonging to transactions. thus you need some structures. it doesn't matter much whether it's buffer_head or some different structure.
  extents is what can reduce metadata overhead for user's video/audio by order of magnitude.
  And why does jbd use buffer h Anonymous (not verified)
  July 11, 2006 - 11:56am
  And why does jbd use buffer heads and not pages? Because it needs to handle sub-page block size, with per-block locking and caching. It is possible to do this with pages of course, you just need to create a block-oriented abstraction on top of the page cache. By the time you have done that you have reinvented the buffer cache.
  Also, it is not just the jbd, it is any metadata handling. Ext2's metadata handling is trivial enough that directory data can be forced into the page cache model, but it is indeed a force fit, there is nothing natural about it. Ext3 uses a btree index which is a nightmare to implement directly on top of the page cache, believe me, I tried it.
  2/8 TB filesystems are here already Nicolas Melay
  July 3, 2006 - 5:04am
  On this page, they also very appropriately state that while the current ext3 should be OK for most users in the next few years, it's already showing its limits on servers with large RAID volumes.
  (Furthermore, we all know that this kind of "should be OK" considerations sometimes prove wrong.)
  In this context, it's clear that ext3 needs to be extended to support larger fileystems while retaining stability and compatibility.
  The limit of ext2/ext3 is really 2TB with 1kB Laurent Vivier (not verified)
  October 15, 2006 - 11:18am
  I'm the author of this page (http://www.bullopensource.org/ext4/), I find this comment only now.
  ext2/ext3 uses 31bit addressing mode (because block number is signed...), so the maximum address space with 1 kB block is 2^31 * 1024 = 2^31 * 2^10 = 2^41 = 2 * 2^40 = 2 TiB
  With 4 kB blocks (the general case) limits is 2^31 * 4096 = 8 TiB.
  For the filesystem, of course, not for a file. Size limit of file is more complex to compute because of the use of direct, indirect, double indirect, triple indirect index blocks ... but by introducing extents we remove this limit (try ext4 in 2.6.19)
  Just An Ounce: 2 GiB = plagosus (not verified)
  January 25, 2008 - 8:29pm
  Just An Ounce: 2 GiB = 2TB
  2GiB != 2TB mobius (not verified)
  Good maths, plagosus! (not)
  I'm fairly certain that 2 x 1024^3 is a LOT smaller than 2 x 1000^4!!
  reiser4 vs. ext4 testerus
  July 2, 2006 - 9:38am
  What I do not understand is: why may ext4 be developed in the main kernel but reiser4 is stuck with mm?
  because they don't follow ker Anonymous (not verified)
  because they don't follow kernel rules. they don't even maintain v3.
  +100. mod parent up. Anonymous (not verified)
  July 3, 2006 - 1:31am
  +100. mod parent up.
  Hans is way too creative for anybody to catch with him up in any effective way. And he is getting too-o excited when his pet ideas got criticized. He's very volatile guy.
  During 2.4 series development, Linux grown to some crucial point when some discipline had to be applied to the development process. Let's say, focus shifted from developing features to maintaining kernel organization: code flows in faster than it can be accomodated.
  That's good when there are people who like to code for Linux on one side. But maintaining organization is magnitude more important, since it's organization what allows others to donate their work to Linux.
  Try again... Anonymous (not verified)
  July 3, 2006 - 9:26am
  That isn't the reason at all. They DO maintain v3, what they DON'T do is add new FEATURES to v3, because they don't want to risk destablizing it in the process. Why would you when you're spending time adding the features to v4 anyways? SuSE developers are actually trying to add new features to v3 against the will of Hans, but he can't do anything about it. Because of this it also has the potential to cause Hans to spend more time fixing bugs that these features cause. The main reason why v4 is still in the MM kernel is because Hans is a forward thinker and instead of making a mediocre file system that "fit" in to the current kernel infrastructure he tried to work around certain parts so he could gain more performance and freedom with features. I can see the reason Hans did this, and personally it makes sense to me. He didn't want to go through all the hassle and jump through the political hoops to try and convince kernel devs of a new way to interface with file systems JUST for ReiserV4. Afterall, why would they want to complicate things for other file systems and add all this extra code that only ReiserV4 will use?
  Unfortunately the kernel devs did the exact opposite. I personally think they should have allowed ReiserV4 to merge with the EXPERIMENTAL flag, work with them to sort out the best way for future file systems to interface with the kernel at that point, and slowly move over to it BEFORE they removed the EXPERIMENTAL flag from ReiserV4. Instead they rejected ReiserV4 outright and told Hans to submit code to change the way all file systems can interface with the kernel, so ReiserV4 isn't the only one with the "advantage". I think they were worried if ReiserV4 caught on that other file systems would start to use these "work arounds" to gain performance and other features and that would cause a huge mess in the kernel. So I can see where the kernel devs are coming from as well, I just don't agree with the way they approached it.
  please, read first about lock Anonymous (not verified)
  July 3, 2006 - 10:13am
  please, read first about locking mess Hans tried to add along with v4. they just don't know what they do.
  what locking mess? Hans Reiser (not verified)
  July 12, 2006 - 7:13pm
  what locking mess?
  http://lwn.net/Articles/10018 Anonymous (not verified)
  July 14, 2006 - 6:42am
  http://lwn.net/Articles/100183
  You just don't get it, right? Anonymous (not verified)
  July 7, 2006 - 8:33am
  You just don't get it, right?
  1. The statement that Namesys has been fixing reiser3 bugs may be true or not, but there's a number of critical bugs that had to be fixed by the kernel developers because Namesys didn't care. (search lkml if you want to read more)
  2. SuSE adding features to reiser3 (assuming they really do that) is perfectly acceptable. They obviously can't expect others to fix bugs in those parts for them then, but to say that they shouldn't do so and whining about how poor Hans can't do anything about it shows that you have not understood even a bit of what free software is actually about.
  3. The kernel does not need reiser4, but reiser4 needs the kernel. There's no *right* to get anything into the kernel, and while Hans doesn't have to grovel, I'm sure his arrogance and unwillingness to work with the kernel developers has contributed to reiser4 staying out of mainline.
  4. I, for one, am glad that the kernel developers are concerned about code quality, bloat, code duplication, creeping featuritis and the like and do not just blindly merge everything that gets thrown their way, especially when the submitter has already shown that he's not willing to maintain previous submissions.
  5. reiser4 *is* in -mm, which is the experimental kernel, so people who want to try it still can.
  6. Hans has had several years to get reiser4 into a merge-able state, yet constantly has refused to even admit that the code might not be perfect, so he has only himself to blame for it not getting into mainline yet. He's not above the rules, just like everyone else - tough luck for him really.
  All in all, it's really Hans's own fault that reiser4 hasn't been merged, and I'm often amazed by the amount of patience the kernel developers have exhibited when dealing with him.
  Dearest Anonymous One Hans Reiser (not verified)
  July 12, 2006 - 7:12pm
  1) is simply untrue. Name the bugs. Perhaps you and I disagree about whether something is a feature or a bug?
  Regarding 2): If you don't keep features out of some branch, you don't have a stable branch. I believe in stable branches as being useful to users.
  I don't see how you can say Reiser4 is not in a "mergeable state". We write code that works, and is self-contained. We do this because we don't want to play the political games with the people who don't decide things based on benchmarks.
  If these people who complain about our code knew what they were complaining about, how come none of them have written a filesystem as fast as Reiser4? Why should I write Reiser4 to use their code instead of ours, when their code is measurably slower than our code? Because they are politically well connected.....
  This is all about Ted Tso getting unhappy when ext3 first came out and I benchmarked it against reiserfs V3, published the benchmarks, and ext3 was half as fast (it did not do metadata journaling back then). Since then, every friend of his has hated me, and he has a lot of friends. He can't code, but he can sure schmooze.
  People who can't produce favorable benchmarks should get out of the way.
  Is that arrogant? Yes. Does that make it difficult to work with me? Yes. Oh well.
  We have been working on doing what akpm asked us to do without reducing our performance. For that reason, we just spent many months fixing the generic code to not do stupid stuff (4k at a time calls to the FS for every silly page) that was killing performance. akpm is a very good programmer, and his requests are generally reasonable, as are most of the comments we get. I would say that the whole time since we asked to be merged, we have mostly been working on the stuff we were asked to do, along with various bug fixes. Some of the comments we get are not so skillful. The biggest change we had to make, the VFS stuff from Hellwig, was a move all the furniture to the other side of the room kind of change, and it broke a lot of code and added bugs. What a waste of time. We did it.
  What can I say, if people don't think that producing a filesystem twice as fast as any other Linux FS matters to Linux.... There is no perfectly written FS. You can keep people busy indefinitely complaining about this or that about an FS. What there are are filesystems that are better than the alternatives. Reiser4 is very very fast, see www.namesys.com/benchmarks.html
  http://osnews.com/read_thread Anonymous (not verified)
  July 14, 2006 - 6:18am
  http://osnews.com/read_thread.php?news_id=15129&comment_id=141566
  It is worth noting... Anonymous (not verified)
  July 16, 2006 - 5:35am
  The Linux Gazette benchmarks are always going to butcher reiser4: Reiser4 is designed for systems with lots of CPU, and the Linux Gazette tests were done on a crusty old P3-500.
  If you have an old system then reiser4 isn't for you.
  Apparently JFS is particularly good for low CPU systems.
  I got several file corruption Anonymous (not verified)
  I got several file corruptions with JFS in a very subtle way (some hard links files corrupted in hsf modem driver directory only and thus render the modem driver to be reinstalled to fix it) with my laptop whike it is stable in my server for several years. Kernel 2.6.x.
  Ext4 may very well be a grand Anonymous (not verified)
  Ext4 may very well be a grand step forward, but honestly factoring in support for Ext3 is just stupid - the code will get big, bloated and performance will go down the toilet. People should use a tool to convert up their filesystem(s) to Ext4 when it is finished then that should be that.
  Then if they want to stick and use Ext3 instead of 4 they can by using an older branch of kernel, and not bog down users who are looking forward. Just think, not everyone wants an everything-including-the-kitchen-sink kernel!
  Ext3->Ext2->Ext4 ? hkmaly (not verified)
  October 14, 2006 - 5:10am
  I, personally, wouldn't mind if ext4 will support ext2, but will require (partial) downgrade to ext2 (doable without reformat, something as removing journal, which is safe operation on clearly unmounted fs as far as I now) before it can read ext3 volumes. Will that help ?
  The real question is why ext4 Anonymous (not verified)
  October 22, 2006 - 9:33am
  The real question is why ext4 needs to support ext2 and ext3 at all. Why not leave ext2 and ext3 separate and just do maintenance to those codebases to keep them working with later kernel releases? Am I being way too naive here?
  how to format in ex4? Anonymous (not verified)
  January 12, 2007 - 7:18pm
  did not find mkfs.ext4 ...(
  mke2fs -j Anonymous (not verified)
  January 26, 2007 - 1:43pm
  форматировать как обычно mke2fs -j
  а монтировать так "mount -t ext4dev -o sync,extents"
  self-contained? Tasci (not verified)
  February 10, 2007 - 3:46pm
  > We write code that works, and is self-contained. If you write code that is self contained, then why can it not be built as a third party kernel module? I would be just ecstatic if I could build reiserfs by telling it where my kernel source is, rather than having to run a monolithic patch that modifies my kernel source willy nilly. Reiser4 needs to work as a 3rd party module, something that should be pretty easy to do if it's so self-contained as you claim.
  [4K size on writes really kills ] [Re: Dearest Anonymous One ] Anonymous (not verified)
  November 22, 2007 - 5:29pm
  I went through this thread and another one (on LKML last year) in which all world seemed to stand against Hans. Generic code of Linux sure restricts file system developers (Oh yes, I didn't write ext3). UFS development is one such case in point. In case one would like to enjoy the features of UFS, and would like to develop/modify read-write version of UFS - he/she has to go for lot of workarounds. Also 4k limit as pointed out by Hans is pain in all wrong places.
  By denying a place for reiser4 in main stream kernel has been a pity. And whosoever says Hans doesn't know what he is doing has for sure not looked into ReiserFS code (or he/she looked into it and could not fathom it as it is written for programmers and for performance and not for entertainment of "I want to be great kernel programmer").
  Linux maintainers are doing a great job,no contentions about that, but then maintaining code and writing code are two different ballgames. And then systems are developed for performance (in addition to Reliability, Scability ...) I had run some benchmarks on ReiserFS (3 as well 4), ext3, ext2, JFS, XFS long time back (2 years and yes on 2.6) and ReiserFS (3) was a winner. Ext3 was nowhere near. JFS was total crap (lost lot of files in case of crashes, some of which it caused itself). XFS was good but with some files lost in case of crashes. Only drawback of ReiserFS is/was sync performance (generally the case with Databases).
  On Hans being arrogant, whoever says so, has not really written/developed some code from scratch and seen it being discarded as "un-fit" for no/minor reasons (even though it is performing wonderful - no idea where all those teachings gone - there is always a tradeoff of performance - in reiser's case tradeoff is - it is not going the way shown by maintainers). Comemon folks, if Hans is fighting for his baby's due place in kernel - why so much hue and cry about it.
  Neglecting and discarding ReiserFS as a filesystem is sure missing on good piece of software.
  SOME FILESYSTEM BENCHMARKS Anonymous (not verified)
  February 6, 2007 - 11:31pm
  | | Across | (MB) | Within | Sources | Sources | (seconds) |
  | | Partitions | | Partition | (seconds) | (seconds) | |
  From http://linuxhelp.150m.com/resources/fs-benchmarks.htm
  NTFS ekati42
  February 15, 2007 - 4:17pm
  Wow according to this NTFS is by far the worst file system there is.
  Well, the Linux drivers for Anonymous (not verified)
  February 18, 2007 - 8:03pm
  Well, the Linux drivers for NTFS are crap, but even with the Windows drivers it can't outperform too many Linux filesystems. The biggies, ext2/3, ReiserFS/4, etc., outstrip it by a long shot.
  I am very surprised with drunkstop
  March 21, 2007 - 6:31am
  I am very surprised with this. Never had thought result like that would come up.
  The NTFS-3G driver isn't bunti (not verified)
  April 5, 2007 - 9:49am
  The NTFS-3G driver isn't optimized at all, they just achieved stable write recently. It's explained for example here: http://www.ntfs-3g.org/performance.html
  Really hope we would see Anonymous (not verified)
  February 21, 2007 - 3:31am
  Really hope we would see versioning as a option for ext4, would be somewhat esier if the filesystem supported it out of the box instead of we have to use a fuse one for getting this very handy function.
  REISER4 Anonymous (not verified)
  March 14, 2007 - 7:57pm
  The filesystems benchmarks at http://linuxhelp.150m.com/resources/fs-benchmarks.htm have been updated. A larger number of more carefully considered tests have been run.
  RESULT: REISER4 was easily the best of the tested filesystems.
  Using REISER4 (tails), rather than EXT2/3/4, saves you a MASSIVE 816 - 673 = 143 Megabytes (a 17.5% saving) when storing 655 MB of raw data..
  |File    |Disk |Copy |Copy |Tar  |Unzip| Del |
  |System  |Usage|655MB|655MB|Gzip |UnTar| 2.5 |
  |Type    |(MB) | (1) | (2) |655MB|655MB| Gig |
  |REISER4 | 692 | 148 |  55 |  67 |  25 |  56 |
  | tails  | 673 | 148 |  63 |  78 |  33 |  65 |
  |NTFS3g  | 772 |1333 |1426 | 585 | 767 | 194 |
  |NTFS    | 779 | 781 | 173 |   X |   X |   X |
  |REISER3 | 793 | 184 |  98 |  85 |  63 |  22 |
  |XFS     | 799 | 220 | 173 | 119 |  90 | 106 |
  |JFS     | 806 | 228 | 202 |  95 |  97 | 127 |
  |EXT4    | 816 | 174 |  70 |  74 |  42 |  50 |
  | extents| 806 | 162 |  55 |  69 |  36 |  32 |
  |EXT3    | 816 | 182 |  74 |  73 |  43 |  51 |
  |EXT2    | 816 | 201 |  82 |  73 |  39 |  67 |
  |FAT32   | 988 | 253 | 158 | 118 |  81 |  95 |
  http://linuxhelp.150m.com/resources/fs-benchmarks.htm (Update)
  Thanks for these results Anonymous (not verified)
  April 4, 2007 - 11:07pm
  Thanks for these results
  Filesystems benchmarks & compression Anonymous (not verified)
  Filesystems benchmarks at http://linuxhelp.150m.com/resources/fs-benchmarks.htm have been updated (yet again) to include transparent compression (gzip and lzo).
  RESULT: With compression REISER4 SMASHED the other filesystems.
  Using REISER4 (tails), rather than EXT2/3/4, saves you a truly amazing 816 - 213 = 603 MB (a 74% saving), and this, with little, or no, loss of performance when storing 655 MB of raw data. In fact, substantial performance increases were achieved in the bonnie++ benchmarks.
  The results for REISER4 are really very impressive. Anonymous (not verified)
  April 2, 2007 - 12:38am
  The results for REISER4 are really very impressive.
  At 4408 secs, EXT4 is higher in the table than it should be. Anonymous (not verified)
  April 2, 2007 - 9:30pm
  At 4408 secs, EXT4 is higher in the table than it should be.
  undelete/recover deleted files Anonymous (not verified)
  September 19, 2007 - 2:37am
  it would be great if ext4 would allow easier recovery/undeletion again - as i learned the hard way, there is no easy way to recover files that you accidentily deleted on an ext3-fs
  Please let me undelete recently deleted files Anonymous (not verified)
  January 4, 2008 - 7:11pm
  I think is a great feature to keep track of recently deleted files and be available to:
  a) recover by hand
  b) let the os permanently delete it if space is required
  linux fls are great and in MHO this would add value to it.
  Record your softphone conversations with this VoipBuster (and others softphones) recorder.
  can you guys please add a Anonymous (not verified)
  December 30, 2007 - 8:48pm
  can you guys please add a feature that keeps track of directory sizes, so I dont have du -ks every directory to see how much space it takes?
  Directory Sizes Already Reported Anonymous (not verified)
  June 1, 2008 - 1:29am
  Anonymous- directory sizes are already being reported. What you fail to understand is how directories work in relation to inodes and blocks. On my ext3 filesystem, 1 block is 4096 bytes. So:
  aaron@kratos:~ 6642 % ls -ld .
  drwxr-xr-x 74 aaron aaron 4096 2008-06-01 02:16 .
  My home directory is showing that it is only occupying 1 block on disk. What do the contents of my home directory show?
  aaron@kratos:~ 6643 % ls | wc -l
  Only 34 files. Remember, that everything on disk, as far as Linux is concerned, is a file. This includes directories. Running 'ls' is just opening the directory file, and showing me the contents. So, this home directory file has 34 lines, telling me other files that exist on the filesystem. The directory holds the inodes to those files as well. All of this data is sitting within 1 block on my filesystem. So, the file size for my home directory is 1 block, or 4096 bytes.
  What you're asking for, the appropriate tool has already been created, and you demonstrated it fine in your comment. The 'du' command will show you 'disk usage' for a directory, it files, and so forth recursively.
  aaron@kratos:~ 6644 % du -hs .
  36G     .
  So, even though I only have 34 files in my home directory, and the /home/aaron/ directory itself is 4096 bytes in size, they are occupying 36GB of disk space, as reported by 'du'.
  So, it a nutshell, 'ls -ld [dir]' is reporting exactly what is should be reporting- the file size of that file on disk, even for directories.