This is the
talk page for discussing improvements to the
Ext4 article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
This
level-5 vital article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||||||
|
On 24 December 2008, Ext4 was linked from Slashdot, a high-traffic website. ( Traffic) All prior and subsequent edits to the article are noted in its revision history. |
The article originally claimed the following:
Although the article cited no source, some research found plenty of articles making this claim. For example, in this IBM article ( http://www.ibm.com/developerworks/linux/library/l-anatomy-ext4/index.html) we find:
But the math doesn't support this claim. An additional two bits would increase the time range by
So either the nature of the change is wrong in these articles (it could be more than two bits) or the math is wrong. I took a look at the Linux kernel sources and this is the relevant code ( http://git.kernel.org/?p=linux/kernel/git/tytso/ext4.git;a=blob;f=fs/ext4/ext4.h;h=b77babe667f3cc323e24f71547581d44f7b6b6f0;hb=HEAD#l483):
static inline void ext4_decode_extra_time(struct timespec *time, __le32 extra) { if (sizeof(time->tv_sec) > 4) time->tv_sec |= (__u64)(le32_to_cpu(extra) & EXT4_EPOCH_MASK) << 32; time->tv_nsec = (le32_to_cpu(extra) & EXT4_NSEC_MASK) >> 2; }
EXT4_EPOCH_MASK is 11 in binary. The 'extra' field is four bytes, most of which are used for finer grained precision. As the sources say, the code does in fact simply add two additional bits of precision to the seconds field. This means the increase is by 204 years, not 500 years. However, every source you can find (other than the code itself) says 500 years, so there is no correct source to cite. I went ahead and made the change anyway, but I'm posting here to explain that. Colin ( talk) 23:38, 30 July 2009 (UTC)
I'm not sure this article is appropriate as yet, since I don't think that it's gone past the proposal stage. Not sure if it should be deleted though. FrozenPurpleCube 16:42, 1 July 2006 (UTC)
Travis| 2:22, 1 August 2006 (PST)
Is it sure ext4 works on BSD and Mac OS X? I seriously doubt that. Can anyone bring more clarity to this matter, so we can remove those OS's if needed? Ludootje 10:23, 11 October 2006 (UTC)
The HTrees discussed are not explained sufficiently - the explanation needs to be extended or a new Wiki article needs to be created for "HTrees". Doronyg ( talk) 14:30, 14 January 2008 (UTC)
Narayannewton ( talk) 18:26, 14 January 2008 (UTC)
Ekscrypto ( talk) 21:17, 3 February 2009 (UTC)
Is the table data structure a Hash Table? If it is it should have link to it. 213.205.69.57 ( talk) 18:52, 28 February 2008 (UTC)
Issue with the online defragmentation section: The section below is just pure rubbish.
Online defragmentation Ext4 will also have an online defragmenter. Even with the various techniques used to avoid it, a long lived file system does tend to become fragmented over time. Ext4 has a tool which can defragment individual files or entire file systems."
Here is my note to explain why this section must be corrected. NOTE: Come on! That is a total lie! Ext4 does NOT have a tool to defragment individual tools or entire filesystems! it just doesnt! If it does, I challenge the author of this unsupported statement to back up this claim with some information. What is this tool called? Where can I get it? Is is a production ready tool, or is it a kludged hack written to do some quick benchmarks/testing for an academic paper that was written early in 2007 and which has had little or no follow-up or adoption by users since then? There are 3rd party tools such as Shake which can be used to defrag any filesystem, including ext4, but they do so very inefficiently. Moving data off a partition, then back also defragments, but we don't say a filesystem has a defragmenter just because the standard unix commands mv or tar can be used to move data off then back onto the partition. Keep this discussion of Ext4 honest, or this wikipedia entry is worthless. The statement "Ext4 will also have an online defragmenter" is also a statement of hope and faith, and at this time is pure fantasy. Ext3 never got an online or offline defragmenter. How can anyone be 100% sure that ext4 will get one? Be honest. Admit that ext4 has no online or offline defragmenter. Feel free to state that an online defragmenter MAY be available in the future. That is all we can say at the moment.
I suggest the misleading statement on defragmentation be changed to something like the following:
Vague Promises of future Online defragmentation Ext4 may in future provide an online defragmenter. Even with the various techniques used to avoid it, a long lived file system does tend to become fragmented over time. Ext4 currently has no tool which can defragment individual files or entire file systems.
PS - if anyone thinks this defragmentation issue can continue to be glossed over by statements like those currently in this wiki page, they are mistaken. Defragmentation has been an appalling performance killer on ext3 and other filesystems for many years, and allowing untrue statements and vague promises from developers to gloss over these problems cannot be allowed anymore! Don't let them get away with it. Until these guys produce a proper online defragmenter - we should let it be known that the lack of one is a problem! If the true situation is actually publicised, and made clearly visible in wiki pages such as these, perhaps these developers will realise they have to actually produce a defragmenter BEFORE they can brag about having done so.
THANK YOU, on behalf of all linux users everywhere who have been putting up with fragged filesystems for years, because those in the know have refused to admit what a performance killer it is - and they've been reluctant to do that because the developers have never provided a solution, and so, to admit the standard linux filesystems are crippled by fragmentation is too embarrassing for linux lovers and can't be allowed...
—Preceding unsigned comment added by 61.88.61.66 ( talk) 02:03, 27 March 2008 (UTC)
Once again, we're told an online defragmenter exists, but... oh wait... its not available! Once again someone mentions the the ext2 defrag tool that has been obsolete and DANGEROUS for years. Noone in their right mind would use ext2defrag on an ext2 filesystem, let-alone on ext3 or ext4. Once again someone says that fragmentation is not an issue, just because they havent noticed it. How do you know its not an issue? Just because your production linux servers perform adequately, does not mean they couldn't perform better. Take one of your production filesystems and run a proper benchmark on it. Then copy all data off it, delete everything on it, copy data back, redo benchmark, be amazed. Saying it is not an issue is head-in-the-sand nonsense. Also, probably, what is occurring is that you have smart SCSI controllers which are letting your drives do out of order reads on all the fragments, reading them in the fastest way that they'll come off disk, and reassembling them in controller. That will mitigate the problem somewhat. Try using non-scsi controllers, ie an IDE or simple SATA drive - and you will be horrified - you will easily lose 50% or more of your disk speed due to fragmentation, and it doesnt take long, and you DONT have to run your drives to 95% full for it to happen - though, of course it will accelerate the fragging process if you do. —Preceding unsigned comment added by 61.88.61.66 ( talk) 05:51, 1 April 2008 (UTC)
errrr... there are three little tabs at the top of this Ext4 wiki page. In case you havent noticed... this IS the "discussion" tab... —Preceding unsigned comment added by 61.88.61.66 ( talk) 23:48, 1 April 2008 (UTC)
I am just flabbergasted at the complete denial that everyone lives in w.r.t defragmentation. Yamla, you seem like a nice guy, i'm not trying to give you a hard time - but you said above that your link to tldp "indicates that it is probably not a good idea to use the ext2 defrag program even on an ext2 filesystem." But no, that is NOT what the tldp page indicated. What it actually said was: "However, it is HIGHLY recommended that you NOT use it. It was designed for and older version of ext2, and has not been updated since 1998! I only mention it here for references purposes." That means it would be sheer, utter, suicide to use that defragger. Don't gloss over that by saying oh its probably not a good idea to use it. No. Its worse than that. The simple fact is it just CANT be used ever by any sane person. A refernce to linux symposium nearly a year ago in June 2007 does not give ext4 an online defragger.
Why can't people just write a half-decent defragger for a modern linux filesystem! It doesnt have to be ultra-super-dooper-efficient. Just 100% safe, effective, and, reasonably efficient. Thats all. It's not asking too much. I don't like to seem ungrateful to open source software developers, i reckon they're great etc, I just wish they would stop trying to get me to swallow this sweetly coated poison pill, year after year. You will have a defragger they say. rrrgh. Ok for God/Allah's sake just produce said defragger so i can say "thank you thank you" and be happy, instead of being a sourpuss. —Preceding unsigned comment added by 61.88.61.66 ( talk) 00:17, 2 April 2008 (UTC)
If anyone cares to check, the source is available for a work in progress version of the defragger available at [ hhttp://www.kernel.org/pub/linux/kernel/people/tytso/ext4-patches/LATEST/broken-out/ext4-online-defrag-command.patch] , it is compilable if you commend out the comments and rename it to a .c file —Preceding unsigned comment added by 216.248.103.177 ( talk) 16:56, 16 July 2008 (UTC)
EXT4 will have a mutiblock allocator which will reduce fragmentation since ext4 will know ahead of time the file size only if delayed allocation is on-- 24.128.74.11 ( talk) 04:06, 16 July 2008 (UTC)
I love how the article says that "H trees are higher alphabetically than B* trees", then points a citation to the Wikipedia article on Alphabetical order!
Comedic gold!-- Dwedit ( talk) 12:01, 20 June 2008 (UTC)
Could someone add a citation on whether ext4 will support creation date timestamps for files? I haven't found any information on this feature anywhere on the Internet and only this article on Wikipedia suggests that ext4 will support creation date timestamps leading me to believe that this is just wishful thinking. I believe we should delete this section in order to not create wrong expectations on ext4. —Preceding unsigned comment added by 84.38.9.123 ( talk) 07:35, 10 August 2008 (UTC)
This tag is placed at the top of this article. However, a file system is not software, correct? But it is in development so is that why we must accept the misnomer? PGScooter ( talk) 06:58, 19 August 2008 (UTC)
The uses of backward and forward compatible seem backwards to me and everyone I've talked to. The uses would be correct in relation to the "filesystem driver", but a backward compatable filesystem is clearly one that can be mounted with the previous version's driver, not the other way around! - 24.98.65.137 ( talk) 04:08, 12 November 2008 (UTC)
I disagree with the use of "forward compatible". forward compatible means it is designed can accept input from future versiones (as specified in provided link): that would be ext5 (or whoever comes to replace ext4 en future). Backwards compatible, acording to provided link, means "allows input generated by older devices"; i'd understand that ext4 is backwards compatible in that "it can accept input generated by an ext3-aware OS", in other words, it's backward compatible since it can be mounted and treated as an ext3 file system. HuGo_87 ( talk) 17:07, 30 January 2009 (UTC)
Linux 2.6.29 removes "noextents" mount option-- 211.127.229.23 ( talk) 12:49, 6 June 2009 (UTC)
I find the current version weird, too. To me, an ext4 file system is backward compatible with ext3 when it can be handled as ext3. —Preceding unsigned comment added by Huggie ( talk • contribs) 13:11, 10 June 2009 (UTC)
Perhaps, extent seems not to be used until tune2fs -O extent is done. However, tune2fs -O ^extent cann't. -- 211.127.229.23 ( talk) 07:03, 11 June 2009 (UTC)
Why is the phrase "the size ext4 is built to support" used in this article without clarification? Does this mean larger file systems, near the limit of what ext4 can support and beyond the size ext3 can support? Or does it mean any file system from only a few files up to that limit? —Preceding unsigned comment added by 12.168.81.98 ( talk) 13:03, 20 March 2009 (UTC)
In case anyone is interested, the patches that Ted Ts'o has written to mitigate this problem are: commit 8750c6d5fcbd3342b3d908d157f81d345c5325a7 ext4: Automatically allocate delay allocated blocks on rename and commit 7d8f9f7d150dded7b68e61ca6403a1f166fb4edf ext4: Automatically allocate delay allocated blocks on close [if the file was previously truncated] Rune Kock ( talk) 22:12, 8 April 2009 (UTC)
According to this page...
http://ext4.wiki.kernel.org/index.php/Ext4_Howto#Barriers_on_by_default
...the disadvantage listed under "Delayed allocation and potential data loss" can only happen if you purposely turn off the default barrier setting.
Quote:
"Barriers on by default:
This is an option that improves the integrity of the filesystem at the cost of some performance (you can disable it with 'mount -o barrier=0', recommended trying it if you're benchmarking).
From this ( http://ext4.wiki.kernel.org/index.php/New_ext4_features ) LWN article:
'The filesystem code must, before writing the [journaling] commit record, be absolutely sure that all of the transaction's information has made it to the journal. Just doing the writes in the proper order is insufficient; contemporary drives maintain large internal caches and will reorder operations for better performance. So the filesystem must explicitly instruct the disk to get all of the journal data onto the media before writing the commit record; if the commit record gets written first, the journal may be corrupted. The kernel's block I/O subsystem makes this capability available through the use of barriers; in essence, a barrier forbids the writing of any blocks after the barrier until all blocks written before the barrier are committed to the media. By using barriers, filesystems can make sure that their on-disk structures remain consistent at all times.' "
Unless I am misunderstanding the above, the the disadvantage listed under "Delayed allocation and potential data loss" appears to not exist in the most recent EXT4 version. I would welcome correction from someone with more technical knowledge in this area. 72.251.90.125 ( talk) 15:24, 10 October 2009 (UTC)
I noticed a bit of incoherency. The article starts off thus: "The ext4 or fourth extended filesystem is a journaling file system developed as the successor to ext3... However, other Linux kernel developers opposed accepting extensions to ext3 for stability reasons..." Why the 'however'? Who were the 'original' (as opposed to 'other') developers, who favored ext4 as an extension? 97.118.195.32 ( talk) 19:00, 7 May 2009 (UTC) / doctorcolossus
http://www.phoronix.com/scan.php?page=article&item=ubuntu_lucid_alpha2&num=3
Various Linux OS using ext4 and recent kernel are suffering from performance hit on PostSQL. The issue is closely related to I/O performance. Is that a matter (or feature) of ext4? If that is true, it is good idea to include that.-- Kittyhawk2 ( talk) 09:23, 15 January 2010 (UTC)
"detect the occurrence of these common cases"
These cases? Which cases would those be? Can you be specific? -- 213.130.252.119 ( talk) 03:42, 2 May 2010 (UTC)
"Work is in progress at pu branch of e2fsprogs."
Does this make sense? I can't work out what that means, but it is late... Chaos.squirrel ( talk) 14:46, 14 June 2010 (UTC)
Doesn't mention whether it's been adopted in Linux distributions... AnonMoos ( talk) 17:19, 13 September 2011 (UTC)
Currently, the article says that the number of subdirectories under ext3 is 32,000 and 64,000 under ext4. Those two numbers look suspiciously like somebody rounded 32K and 64K down. If so, wouldn't it be more accurate to use the exact numbers, possibly both as K and written out? JDZeff ( talk) 20:33, 11 November 2011 (UTC)
The table on the right hand side of the article states that allowed characters in filenames are all bytes except NULL and '/'.
It would be helpful to clarify whether ext4 is aware of characters or just of Bytes in its filenames; and if it is aware of characters, what codepage is used to store the characters. According to the description it is apparently aware of the character '/' ... Gandalf44 ( talk) 01:10, 14 August 2012 (UTC)
The article tells the maximum filelength in ext4 to be 255 characters which seems to me to be missleading or at least unprecise as (at least in linux) the system does not care about character encoding. Since a UTF8 formated filename with 5 charaters can have more then 5 bytes (i.e. 10) it is entirely possible to have a filename being at maximum 127 characters in size. I would suggest updating the maximum filename length to state 255 bytes. — Preceding unsigned comment added by 77.12.15.151 ( talk) 06:29, 13 August 2013 (UTC)
I think there is an error in the limits mentioned by Red Hat. According to Red Hat ( https://access.redhat.com/solutions/53431): The solution for large filesystems is to use XFS. The XFS file system is specifically targeted at very large file systems (16 TB and above).
According to Red Hat ( https://access.redhat.com/solutions/1532): The maximum size they support for ext4 is 16TB. The maximum they support for XFS is 100TB for RHEL5 or RHEL6 and 500TB for RHEL7.
Under Features|Large file system, the text claims that Red Hat supports ext4 for file systems up to 100TB. That is untrue. They support ext4 file systems up to 16TB and XFS file systems up to 100TB (or 500TB in RHEL7).
Technical reasons for the 16TB limit is confirmed with this citations (already cited). https://ext4.wiki.kernel.org/index.php/Ext4_Howto#Bigger_File_System_and_File_Sizes — Preceding unsigned comment added by 134.223.116.156 ( talk) 21:30, 3 December 2014 (UTC)
Hello fellow Wikipedians,
I have just added archive links to one external link on
Ext4. Please take a moment to review
my edit. If necessary, add {{
cbignore}}
after the link to keep me from modifying it. Alternatively, you can add {{
nobots|deny=InternetArchiveBot}}
to keep me off the page altogether. I made the following changes:
When you have finished reviewing my changes, please set the checked parameter below to true to let others know.
This message was posted before February 2018.
After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than
regular verification using the archive tool instructions below. Editors
have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the
RfC before doing mass systematic removals. This message is updated dynamically through the template {{
source check}}
(last update: 18 January 2022).
Cheers.— cyberbot II Talk to my owner:Online 14:35, 16 January 2016 (UTC)
Hello fellow Wikipedians,
I have just added archive links to one external link on
Ext4. Please take a moment to review
my edit. If necessary, add {{
cbignore}}
after the link to keep me from modifying it. Alternatively, you can add {{
nobots|deny=InternetArchiveBot}}
to keep me off the page altogether. I made the following changes:
When you have finished reviewing my changes, please set the checked parameter below to true to let others know.
This message was posted before February 2018.
After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than
regular verification using the archive tool instructions below. Editors
have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the
RfC before doing mass systematic removals. This message is updated dynamically through the template {{
source check}}
(last update: 18 January 2022).
Cheers.— cyberbot II Talk to my owner:Online 16:01, 18 February 2016 (UTC)
Hello fellow Wikipedians,
I have just modified 4 external links on Ext4. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
This message was posted before February 2018.
After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than
regular verification using the archive tool instructions below. Editors
have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the
RfC before doing mass systematic removals. This message is updated dynamically through the template {{
source check}}
(last update: 18 January 2022).
Cheers.— InternetArchiveBot ( Report bug) 11:25, 26 September 2017 (UTC)
The "recommended" maximum EXT4 volume size is up from 16TiB to 50TiB.
https://access.redhat.com/solutions/1532 — Preceding unsigned comment added by Sbergman27 ( talk • contribs) 10:42, 7 October 2018 (UTC)
Under Backward compatibility some option keywords are given, and each one has a caret on it. The linux ext4 man page doesn't mention these carets. The ref linked to that sentence has them but has no reason to explain them. They are unusual and may or may not need some explanation. Research is needed. 192.31.106.36 ( talk) 13:41, 9 December 2018 (UTC)
Hello,
The first link in this section,
Theodore Ts'o's discussion on ext4, 29 June 2006
is broken; I searched for a copy but could only find
Theodore Ts'o's Proposal and Plan for Future EXT4 Work, 28 June 2006.
I'm not comfortable replacing this, since the replacement occurred one day after the original, and so might not be the original discussion. Moreover, the replacement text isn't useful documentation. It discusses future plans for development of something that's already been developed. Not sure what to do.
Delete me when resolved
Josh — Preceding unsigned comment added by Josh5923 ( talk • contribs) 08:31, June 9, 2020 (UTC)
Infobox says the maximum number of files would be 4 billion. But what is this information based on? Number of files is limited by the number of inodes. Maybe in the past this was 32 bit, but nowadays this is no problem anymore. I have a file system with according to "tune2fs -l" Inode count: 4291584 So "Max. number of files" would better be written "depending on the inode count (specified at filesystem creation time)" Umfassender ( talk) 22:05, 9 July 2022 (UTC)
Hello,
Where does the file system size limit come from?
Here : https://www.kernel.org/doc/html/latest/filesystems/ext4/overview.html , I can read that the limit is 64 Zib on a 64 bits machine and there is no mention about a 1Eib limit.
BastienCoco ( talk) 13:50, 25 June 2023 (UTC)