Talk:Ext4

message: The article originally claimed the following:
:[...]In addition, 2 bits of the expanded timestamp field are added to the most significant bits of the seconds field of the timestamps to defer the year 2038 problem for an additional 500 years.
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:
:The time range has also be extended with two additional bits to increase the lifetime by another 500 years.
But the math doesn't support this claim. An additional two bits would increase the time range by
(3 \times 2^{31}) / 3600 / 24 / 365 \mbox{ years} \approx 204 \mbox{ years}
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)
replies: text: And I'm reverting it. WP:OR is pretty clear on this point. You say yourself you can't find any published sources to back up your claim. NipokNek (talk) 11:51, 10 August 2009 (UTC)
replies: text:  Why would you revert it? I've clearly showed that the original information is wrong. If there's no source for the correct information, and that prevents it from being added, the conservative position would be to remove the claim entirely—not to reinstate wrong information. I don't like that this page has a completely wrong claim, so to avoid "original research", I've simply made the claim in the article more vague ("500 years" -> "several hundred years"). If this is still unacceptable, the section should be removed entirely. Propagating erroneous information simply because it's also found on an IBM page is foolish. Colin (talk) 02:11, 17 September 2009 (UTC)
replies: text:  The guidelines on specialists adding their own knowledge point out that you should still cite your source, so if you have investigated you should write an article explaining in detail what you did, on your blog maybe, and then you or someone else can cite your article and put in the correct information. --Petercoulton (talk) 14:37, 17 September 2009 (UTC)
replies: text:  With all due respect, that's totally nuts.  According to the above rule, I couldn't correct a Wikipedia page that claimes 2+2=5 without citing a source.  Simple arithmetic is not "specialist knowledge" that needs to be sourced.  If you really need a source, here's one: I just checked (3 \times 2^{31}) / 3600 / 24 / 365.25 \mbox{ years} \approx 204.15 \mbox{ years} on my Casio fx-115ES calculator. (The \approx is there because a 204 year period may have a different number of leap years, but it's always 204, never 203 0r 205. Drop the ".15" and you can drop the \approx.)  I am going to change the number in the article to the correct figure now. 72.251.90.125 (talk) 16:09, 10 October 2009 (UTC)
replies: text:  The ext2 time field holds 2^{32} values. two extra bits gives a range of 2^{34}\mbox{ seconds} \approx 544\mbox{ years}.  It's unclear if the earliest date representable is intended to be in 1970 or 1901.  In the current implementation bugs means dates outside the 1970-2038 range don't work right.  The existing (unsourced) infobox says 14 December 1901 - 25 April 2514, this is off by 68 years at one of the ends. https://bugzilla.kernel.org/show_bug.cgi?id=23732 BCoates (talk) 05:56, 8 January 2012 (UTC)
thread_title: ext4 "extra" timestamp storage

message: 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)
replies: text: If ext3 works, then parts of ext4 may work. But when using stuff like extents, you first need to add support for that to the BSD/OSX kernels. Read the paragraph about backward/forward compatibility. -Jen 15:46, 19 October 2006 (UTC)

text: I use BSD, both OpenBSD and FreeBSD. BSD does not support ext4. Not even FreeBSD, which tends to be ahead of the curve. BSD supports ext3, but only because ext3 is essentially ext2 with journaling thrown on top -- BSD actually only supports ext2, but because of the nature of ext3, it is able to mount it and edit it - it just doesn't respect the journaling feature. As far as Mac OS X, I haven't used it in some time, but I would be very surprised if Mac OS X could mount extfs, given it doesn't support UFS2, even though it has a "BSD subsystem." A lot of things that work on BSD systems do not work on Mac OS X. For example, no pf firewall, no /dev/audio or /dev/dsp, etc. Bearshark (talk) 04:30, 14 February 2010 (UTC)
thread_title: OS's?

message: 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)
replies: text: It should probably be a page in itself since ext3 also uses htrees 
Narayannewton (talk) 18:26, 14 January 2008 (UTC)

text: I agree that a page in itself would be better as htree been available since ext2 as a patch.
Ekscrypto (talk) 21:17, 3 February 2009 (UTC)
thread_title: HTrees

message: 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)
thread_title: Table

message: 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)
replies: text: Please see here.  An online defragmenter already exists, it just isn't merged yet.  And that's not counting the ability to treat ext4 filesystems as ext2 (depending on options) and use ext2 defragmenters on it.  --Yamla (talk) 14:34, 27 March 2008 (UTC)

text: Also, I'd like to see a reliable source that indicates lack of online defragmentation in ext3 is a performance killer.  I've been using ext3 in production environments for years and have not seen this performance issue on any system.  Still, I'm not a reliable source.  A simple link will suffice, no need to engage in inappropriate discussion about it here.  --Yamla (talk) 14:36, 27 March 2008 (UTC)
replies: text: Just to follow up, if anyone is trying to use this discussion as a reliable source (not a good idea), this page (5.10.11) indicates that it is probably not a good idea to use the ext2 defrag program even on an ext2 filesystem.  However, it also indicates that fragmentation is really not a problem on Linux file systems.  Other references I've found indicate that this may be a problem if your file system is over 90% of 95% full.  --Yamla (talk) 21:32, 30 March 2008 (UTC)
replies: text: I can only give you german sources, but theses state very clearly, that fragmentation of ext3 is a huge problem - and its design makes fragmentation worse than on some other filesystems (read this article about the "why?"). And even worse: Using the very old ext2 defrag, which has not been updated by programmers for nearly ten years now, on modern ext3 or ext2 flavours, which use techniques such as htrees, which were not present, when the in fact deprecated ext2 defrag was written, may damage your data. I am sorry, that I can only provide german sources, because I'm german and I don't know any english computer magazin that ever wrote about such stuff, but if you can read german, you'll see that your believe in the "unnecessity" of defragmentation on Linux file systems is just an Urban Legend. (I found the english version of that article) --88.73.150.217 (talk) 12:10, 14 March 2010 (UTC)

text: This is not a discussion forum.  Please see WP:NOT.  --Yamla (talk) 15:41, 1 April 2008 (UTC)

text: What part of "This is the talk page FOR DISCUSSING IMPROVEMENTS TO THE EXT4 ARTICLE" are you having trouble understanding?  Please reference your claims and use them to improve the Wikipedia defragmentation page.  Do that (Learn the rules about sourcing and NPOV first!) and you could be a valuable contributor instead of being disruptive. On THIS talk page the only part of what you wrote that has any bearing is the question of whether e4defrag exists. 72.251.90.125 (talk) 16:42, 10 October 2009 (UTC)

text: This is not a general discussion forum for ext4.  I have now semi-protected this page so that anonymous user, 61.88.61.66, can read this, which explains this in more detail.  --Yamla (talk) 00:21, 2 April 2008 (UTC)
thread_title: defragmentation

message: 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)
thread_title: Bad jokes and other deleted nonsense?

message: 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)
replies: text: Two fields (i_crtime and i_crtime_extra) which make up the creation time are present in the Linux kernel source (fs/ext4/ext4.h as of version 2.6.27-rc3.) I thus removed the "Citation needed" tag without actually adding one. C code is probably of little help to the typical user in this context, but anybody feel free to add a link if you think otherwise.  —Preceding unsigned comment added by 62.206.189.40 (talk) 11:17, 25 August 2008 (UTC)
thread_title: Creation date timestamps?

message: 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)
replies: text: I think this is entirely appropriate. A file system implementation is software. The Linux kernel implementation of ext4 is under development. Typically the FS's name refers to the file system itself as well as its original implementation. For example, you don't see people differentiating between the NTFS file system and Windows's NTFS code. -- intgr [talk] 13:38, 19 August 2008 (UTC)
replies: text: "A file system implementation is software." Interesting, I did not know that. Thanks for the info :)PGScooter (talk) 04:12, 20 August 2008 (UTC)
thread_title:  "This article contains information about computer software currently in development." 

message: 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)
replies: text: I totally disagree with your assessment.  The text in this article as you have changed it now looks wrong.  Please look at the articles linked:  forward compatibility/backward compatibility, they agree with me.  If you read those articles and still believe that I am incorrect, then I'll go through the trouble to find a source.  If nobody replies here, I'm going to reverse the article text.  ~a (user • talk • contribs) 23:23, 8 January 2009 (UTC)
thread_title:  backward/forward compatible 

message: 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)
replies: text: AFAIK, an ext3 disk of only a few terabytes can take something like an hour to check.  And without some optimizations this would grow so that a check of a 100 TB disk would be unrealistic to do at all.  Also, the amount of RAM needed during the check can be a critical factor.  Actually, there has been work going on to speed up fsck on ext3 as well, like , but I don't know whether it has been accepted into the kernel. Rune Kock (talk) 15:41, 20 March 2009 (UTC)
replies: text: There's no actual need to fsck an ext3 file system anyway, as it's a journaling file system. -- intgr [talk] 16:00, 21 March 2009 (UTC)
replies: text:  Sorry intgr - that's not accurate.  By default, most linux distros will actually force an fsck on boot for ext3 filesystems every X number of mounts (typically reboots) or Y number of days, whichever comes first - and in the event of power failure, while you don't *need* to FSCK, there are times when it's helpful.  Disk corruption and various other things can cause it.  Speaking as someone who's had to perform more than a few FSCKs of EXT3 filesystems on the various systems I manage or own, I have to disagree. Overand (talk) 19:24, 24 February 2010 (UTC)
thread_title:  the size ext4 is built to support 

message: 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)
replies: text: By the way, this section, when I found it today, portrayed the problem as an "exposing API bugs" in the headline, and further down claimed that it was "really an application bug", as applications weren't calling fsync after they'd written to files. While the author clearly seems to think that this is the case, this is not the place to promote such an opinion. The content is therefore removed. Rōnin (talk) 01:36, 10 April 2009 (UTC)

text: (The opinion that is) Rōnin (talk) 01:37, 10 April 2009 (UTC)
replies: text: I think that it can be substantiated by misc. standards that the only way for an application to assure itself that its data has been written to disk, is to call fsync or similar.  So strictly speaking, it is an application bug that it doesn't call fsync after every important write.  But it is clearly not a good idea for the file system to be so vulnerable.  I would call it a case of "broken as designed": it follows the standard to the letter, but still eats your data.  Rune Kock (talk) 17:05, 13 April 2009 (UTC)
replies: text: If it really can be backed up by widely accepted standards that fsync() (or similar) has to be called, then of course it's admissible, as you say. It should at least be backed up by citations from the relevant standards, though, since just the initial discussion on Slashdot and elsewhere showed this to be a highly controversial issue. Rōnin (talk) 21:56, 13 April 2009 (UTC)
thread_title:  Delayed allocation and potential data loss 

message: 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)
thread_title: Missing sentence in introductory paragraph?

message: 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)
thread_title:  Benchmark on PostgreSQL 

message: "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)
replies: text: It was sort-of explained in the preceding section. But I rewrote most of it now, hopefully it's clearer? -- intgr [talk] 17:06, 2 May 2010 (UTC)
thread_title:  Replacing file contents 

message: "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)
replies: text: "pu" is the name of a branch in the e2fsprogs git repository. But I think I'm going to remove it because it's not really encyclopedia material. -- intgr [talk] 22:06, 14 June 2010 (UTC)
thread_title:  Features- Large FS  

message: Doesn't mention whether it's been adopted in Linux distributions... AnonMoos (talk) 17:19, 13 September 2011 (UTC)
thread_title: distros

message: 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)
replies: text: the article unlimited number of subdirectories, but a limited total number of files, why so? Jackzhp (talk) 12:13, 7 February 2017 (UTC)
thread_title:  Number of subdirectories 

message: 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)
replies: text: In all "native" Linux file systems, file names are just a bunch of bytes. It's up to the user space to interpret what they mean. Some foreign Unicode-aware file systems have a "codepage=" mount option to specify how to convert characters back to a single-byte representation. -- intgr [talk] 08:45, 14 August 2012 (UTC)
thread_title:  Codepage of filenames ? 

message: 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)
thread_title:  Limits of Ext4 & Red Hat 

message: Hello fellow Wikipedians,
I have just added archive links to  on Ext4. Please take a moment to review my edit. If necessary, add  after the link to keep me from modifying it. Alternatively, you can add  to keep me off the page altogether. I made the following changes:
*Added archive https://web.archive.org/20111023015226/http://www.soluvas.com:80/read-browse-explore-open-ext2-ext3-ext4-partition-filesystem-from-windows-7/ to http://www.soluvas.com/read-browse-explore-open-ext2-ext3-ext4-partition-filesystem-from-windows-7/
When you have finished reviewing my changes, please set the checked parameter below to true to let others know.
Cheers.—cyberbot IITalk to my owner:Online 14:35, 16 January 2016 (UTC)
thread_title:  External links modified 

message: Hello fellow Wikipedians,
I have just added archive links to  on Ext4. Please take a moment to review my edit. If necessary, add  after the link to keep me from modifying it. Alternatively, you can add  to keep me off the page altogether. I made the following changes:
*Added archive https://web.archive.org/20140222015915/https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/7-Beta/html/Performance_Tuning_Guide/s-storage-ext4.html to https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/7-Beta/html/Performance_Tuning_Guide/s-storage-ext4.html
When you have finished reviewing my changes, please set the checked parameter below to true to let others know.
Cheers.—cyberbot IITalk to my owner:Online 16:01, 18 February 2016 (UTC)
thread_title:  External links modified 

message: 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:
*Added archive https://web.archive.org/web/20100706040230/http://www.linuxsymposium.org/archives/OLS/Reprints-2007/mathur-Reprint.pdf to http://www.linuxsymposium.org/archives/OLS/Reprints-2007/mathur-Reprint.pdf
*Added archive https://web.archive.org/web/20081201104450/http://www.ibm.com/developerworks/linux/library/l-ext4/ to http://www.ibm.com/developerworks/linux/library/l-ext4/
*Added archive https://archive.is/20120712143749/kerneltrap.org/node/6776 to http://kerneltrap.org/node/6776
*Added archive https://web.archive.org/web/20120111062641/http://www.crossmeta.org/redmine to http://www.crossmeta.org/redmine
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 11:25, 26 September 2017 (UTC)
thread_title:  External links modified 

message: 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)
replies: text: How big will they go in RHEL 8? 192.31.106.36 (talk) 13:42, 9 December 2018 (UTC)
thread_title:  Red Hat Contractually supports EXT4 filesystems of up to 50 TiB in RHEL 7 

message: 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)
thread_title:  Carets 

message: 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)
: Not sure what you mean when you say that link is broken. Just tried it there and it works okay for me. Do you get an error? AlistairMcMillan (talk) 17:53, 9 June 2020 (UTC)
thread_title:  External Links 

message: 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)
thread_title:  What is "Max. number of files" with 4 billion based on? 

message: 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)
thread_title:  ext4 filesystem size limit