Talk:ext3

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

The Second Extended File system[edit]

The Second Extended File system was devised (by Rémy Card) as an extensible and powerful file system for Linux. It is also the most successful file system so far in the Linux community and is the basis for all of the currently shipping Linux distributions.

The EXT2 file system, like a lot of the file systems, is built on the premise that the data held in files is kept in data blocks. These data blocks are all of the same length and, although that length can vary between different EXT2 file systems the block size of a particular EXT2 file system is set when it is created (using mke2fs ). Every file's size is rounded up to an integral number of blocks. If the block size is 1024 bytes, then a file of 1025 bytes will occupy two 1024 byte blocks. Unfortunately this means that on average you waste half a block per file. Usually in computing you trade off CPU usage for memory and disk space utilisation. In this case Linux, along with most operating systems, trades off a relatively inefficient disk usage in order to reduce the workload on the CPU. Not all of the blocks in the file system hold data, some must be used to contain the information that describes the structure of the file system. EXT2 defines the file system topology by describing each file in the system with an inode data structure. An inode describes which blocks the data within a file occupies as well as the access rights of the file, the file's modification times and the type of the file. Every file in the EXT2 file system is described by a single inode and each inode has a single unique number identifying it. The inodes for the file system are all kept together in inode tables. EXT2 directories are simply special files (themselves described by inodes) which contain pointers to the inodes of their directory entries.

Figure shows the layout of the EXT2 file system as occupying a series of blocks in a block structured device. So far as each file system is concerned, block devices are just a series of blocks which can be read and written. A file system does not need to concern itself with where on the physical media a block should be put, that is the job of the device's driver. Whenever a file system needs to read information or data from the block device containing it, it requests that its supporting device driver reads an integral number of blocks. The EXT2 file system divides the logical partition that it occupies into Block Groups. Each group duplicates information critical to the integrity of the file system as well as holding real files and directories as blocks of information and data. This duplication is neccessary should a disaster occur and the file system need recovering. The subsections describe in more detail the contents of each Block Group. —Preceding unsigned comment added by 202.83.49.25 (talk • contribs) 05:16, 4 November 2004

an xattr is a fork[edit]

An ext2 xattr very similar to an HPFS EA, which the fork page considers to be a type of fork. Linux does in fact support two OS/2 filesystems, HPFS and JFS, using the same API as is used for ext3. The only reason you couldn't store most MacOS-style resource data is a size limit; small ones would work just fine though.

24.110.60.225 02:39, 3 January 2006 (UTC)[reply]

No, they're not. Forks can be read and written like normal files (i.e. you can call read(2), write(2), ftruncate(2), etc. on them). As such, Solaris 10's xattrs (on UFS or ZFS) are forks, as are NTFS's named streams, HFS's resource and data forks, and HFS+'s forks. An xattr on Linux is basically a named extension to struct stat. They are of limited size, and can only be atomically fetched, replaced, or deleted. They are not forks. Fork's definition of what a fork is is wrong, but I don't care to deal with it. --NJM 05:44, 3 January 2006 (UTC)[reply]
A fork is any kind of user defined data attached to a file that doesn't belong to file data or metadata.
They are just name=value and don't have to be unlimited in size.
So, xattr are forks.
—Claunia 12:57, 3 January 2006 (UTC)[reply]
By that definition, Mac OS doesn't have forks. --NJM 02:01, 4 January 2006 (UTC)[reply]
It has. ICON, ICNS, MENU, CODE, BNDL, etc. You can consider them as independent forks.
Or you can consider it has a big fork named "resource".
Apart from that 10.4 added support for other forks, named as user want.
—Claunia 13:43, 4 January 2006 (UTC)[reply]
All those things you just mentioned are either file data or metadata. (Except the OS X additions, but I wasn't talking about OS X.) --NJM 03:47, 5 January 2006 (UTC)[reply]
ICON, ICNS, MENU, CODE, BNDL, so on, are resources of Macintosh resource fork, and not file data or metadata, and are considered a different fork (alternate data stream).
LONGNAME, CHARCODE, so on, are extended attributes of OS/2, and not file data or metadata, and are considered a different fork (alternate data stream).
$Macintosh_Finder_Info, $Extended_Attribute, so on, are ADSs of NTFS, and not file data or metadata, and are considered a different fork (alternate data stream).
What have xattr that make them so very different to any of these to not be considered a fork or alternate data stream?
—Claunia 08:50, 5 January 2006 (UTC)[reply]
ICON/ICNS/MENU/CODE/BNDL/etc are contained in the Macintosh resource fork and not properly forks on their own. However, Macs do support two forks per file -- the well-known data and resource forks.
The NTFS alternate data streams are forks.
OS/2 EAs aren't forks either, for the exact same reasons that Linux xattrs aren't.
The important details is that alternate forks (whether the Mac resource fork, alternate streams on NTFS, xattrs on Solaris, named attributes in NFSv4, etc.) behave exactly like the default unnamed fork that all files have (once you've jumped passed the initial hurdle of opening them) -- they have a file pointer and are seekable, you can read and write them in whole or in part, truncate them, map them into memory, lock regions for your own exclusive use, etc. (Admittedly, doing these things to a Mac resource fork takes more effort than other operating systems.)
Linux xattrs (as well as OS/2 Extended Attributes and BeOS attributes) don't behave like the default unnamed fork -- you can't open them (i.e. acquire a handle to an attribute like a normal file data stream), you can't seek them, you can't truncate existing attributes, you can't memory map them, you can't lock them, etc. The operations that can be performed on xattrs are much more limited -- you can get an existing attribute, you can set an attribute (which will either create a new attribute or atomically replace an existing attribute), and you can remove an attribute entirely. That's all. This moves xattrs into an entirely different problem space than forks.
Forks are basically a way of attaching more files to a file, while xattrs are a way of extending file metadata to new and interesting areas -- the primary use of xattrs on Linux systems are for the storage of ACLs and MAC labels. Along with the system xattr namespace (with it's kernel-enforced content restrictions), there's also the user namespace, which apps like Samba are free to use to store extra bits of information that the traditional Unix struct stat doesn't keep around (like file creation times).
xattrs don't look like forks, they don't act like forks, they aren't used to store the same kinds of things as forks, they aren't forks. --NJM 01:11, 8 January 2006 (UTC)[reply]
In computing, a fork is additional data associated with a file system object. from Fork_(filesystem).
ADS, Resource Fork, EAs, xattr, are that. —Claunia 13:21, 8 January 2006 (UTC)[reply]

As NJM and Claunia appear to disagree on the definition of a fork I would suggest either to continue this discussion on the corresponding talk page or—as a compromise—to add something like the following to this article:

While Linux xattrs represent additional data associated with a file system object and so may be called forks according to the most general definition, the operations that can be performed on xattrs on Linux are much more limited than the operations on xattrs on Solaris, Mac resource forks, alternate streams on NTFS, named attributes in NFSv4 etc. in that one cannot acquire a handle to an attribute like a normal file data stream nor can Linux xattrs be seeked etc.

That way both points of view of this discussion could be represented and the value of the article be increased. —Tobias Bergemann 22:00, 8 January 2006 (UTC)[reply]


Variable block size[edit]

The article says under "Disadvantages" that "many of the on-disk structures are similar to those of ext2. Because of that, ext3 lacks a number of features of more recent designs, such as dynamic allocation of i-nodes, variable block sizes". The Ext2 article on the other hand claims that "ext2 ... has variable length block size". Either there is a contraditcion or poor use of words.

xerces8 --86.61.44.206 21:14, 4 March 2006 (UTC)[reply]

HTree in ext2/3 the same as the linked to "hash tree"?[edit]

The htree used to represent directory entries in ext2/3 filesystems is an implementation of BTrees. It is not an implementation of the algorithm mentioned in the htree article. It is called an htree because the directory entry names (i.e. filenames and directory names) - the keys for a lookup operation - are hashed. Or this is what I understand. Do let me know what you'll think.

Veliath 07:20, 11 April 2006 (UTC)[reply]

You are correct in pointing out this error in the article. The "H-Tree" (Hash Tree, Merkle Tree) structure currently referenced is NOT the same as the HTree structure used in ext2/3. Daniel Phillips simply coined this term (see his 2001 paper at the Ottawa Linux Conference) to describe the custom structure he developed.
-- phil hutto (pwh@cc.gatech.edu 1:17 am , 25 April 2006 (EST) —Preceding unsigned comment added by 68.155.131.205 (talk • contribs) 05:18, 25 April 2006

ext2 and ext3 definitions[edit]

Further is the htree based directory indexing a new feature in ext3? It seems to be available in ext2 as well. Should it be introduced in the section on ext3's features over its predecessor? Once again do let me know what you'll think. --Veliath 06:37, 9 May 2006 (UTC)[reply]

ext2 doesn't support the htree opton. --NJM 01:56, 12 May 2006 (UTC)[reply]
So is ext3 the name for an updated ext2 with a new version number or simply an ext2 file-system with a journal? I ask because an ext2 file-system can be created without a journal and using directory indices. --Veliath 18:33, 20 May 2006 (UTC)[reply]
ext3 is the updated filesystem (and site of all new development). My understanding is that ext2 only gets new stuff when an ext3 filesystem would become unintelligible or when there's very little complexity involved. So, the htree option wasn't added to ext2 because it's transparently backward compatible (htree unaware drivers just ignore the tree block and do an ordinary linear search through the directory) and the implementation itself was somewhat complex. (On the otherhand, things like xattr (with the accompanying SELinux labels and ACL support) were added because they weren't very difficult to implement and not including them would render the fs unreadable by ext2 (or else readable but potentially insecure)). --NJM 02:57, 21 May 2006 (UTC)[reply]
The file src/linux/Documentation/filesystems/ext3.txt has a line in the intro that reads "ext3 is ext2 filesystem enhanced with journalling capabilities". It goes on to describe only journaling - hence my query. --Veliath 15:17, 22 May 2006 (UTC)[reply]

List of distros using ext3[edit]

I removed the list of distros using ext3 because I thought it was getting too long and was largely useless. There are literally hundreds of Linux disributions, many or most of which that use ext3 by default and listing all of them would be a waste of space and mostly irrelevant to the article (The fact that ext3 is primarily used by Linux / used by most Linux distros is more important than the actual list itself). Pruning the list down to a limited selection of distros would only lead to an argument over which distros should be listed, so removing the list entirely was the better choice. --NJM 17:43, 13 May 2006 (UTC)[reply]

Deletion Recovery[edit]

Look at this: Stellar Phoenix Linux - ext2/ext3 Data Recovery Software. As far as I know, there's no other application that can recover deleted files on a ext3 filesystem. On many FAQs about ext3 you can read that it's hard to do that. So, I think it's really important to give users a choice to know there's such application, and this thing is possible. I want to recreate the link. Is that ok? —Preceding unsigned comment added by Hossein.ir (talk • contribs) 14:18, 4 July 2006

Could you cite these FAQs please? Mis-read your comment. Thought you were saying the FAQs pointed to SP's recovery software. Never mind. AlistairMcMillan 16:49, 4 July 2006 (UTC)[reply]
Please read Wikipedia:External links. Particularly the section titled "What should not be linked". AlistairMcMillan 19:05, 4 July 2006 (UTC)[reply]

I looked at the stellarinfo site and found that the program only works with Windows! So, if you only have Linux, you'll have to install windows to recover you're data! -- Jdm64 18:56, 4 July 2006 (UTC)[reply]

I've read the Wikipedia guidlines, and I still can't see a problem in adding the link. Right now, it's the only way of recovering files on ext3. Do you think that this is promoting the product? I don't think so. Could I add the link? It may help some people in recovering their data. By the way, somebody considered me as a newbie, and filled my talk page with welcome message. I want to say that I'm not a newbie here, but most of my contributions goes into Persian Wikipedia, with the user name of حسین. —Preceding unsigned comment added by Hossein.ir (talk • contribs) 19:46, 7 July 2006
If you re-add the link it will likely be deleted, because of the policies linked above. You say it is the only way of recovering files on ext3, can you provided credible sources to back this up? And you say we should have the link because it "may help some people", but this is an encyclopedia not a HOWTO. AlistairMcMillan 13:14, 8 July 2006 (UTC)[reply]
Look at these links:
* Canberra Linux User Group Mailing List
* ext3 FAQ, Q:: How can I recover....
You're just linking to the policies page; Could you please discuss about it? I can't see a problem with adding that link. Thanks
Hossein.ir 15:10, 9 July 2006 (UTC)[reply]
Those links make it sound like any undeletion software is unlikely to work. Do you have any independent evidence that the product actually works? The company says its software does something that the ext3 developers say isn't possible. That's a bold claim that requires some support, I think.
At first glance it looks like the company wants users to pay $80-$200 for a Windows program in the desperate hope of recovering lost ext3 data. The website gives the impression that the program can recover any deleted information. That can't be true; what if the deleted inodes have been overwritten? Wmahan. 15:50, 9 July 2006 (UTC)[reply]
Perhaps Hossein you could take a minute to actually read the stellarinfo page. That would make a good start. Particularly this sentence: "Provides recovery of deleted file(s) for Ext2 File system only". Aside from this, our policy tends toward avoiding the addition of links that are intended solely to promote commercial products. That is the core of the problem. Also the fact that this product doesn't recover files on ext3 file systems... AlistairMcMillan 17:06, 9 July 2006 (UTC)[reply]
I haven't actually used the software, but it's available for evaluation download. I use Linux right now, and I can't experiment the application. And your question: I think all ther other undeletion programs have the same problem: overwriting data. And it seems that there's no application that can recover all deleted files, in all situations. Btw, look at this links. Does this seem fake to you? I can't say anything about those products. If someone has more information about file recovery, maybe we can add a section about recovering files. If you look at the article, the only tool that is provided for recovering files on ext3 filesystem is "grep"! Hossein.ir 17:11, 9 July 2006 (UTC)[reply]

That website is just a mirror of their advertising. It is not a review. And again, the people that created this product admit on their own website that it cannot recover files from ext3 volumes. Please stop going on about this. AlistairMcMillan 17:23, 9 July 2006 (UTC)[reply]

Plese Look at Wikipedia:Notability (software). With this guideline, I can not agree with you. This product has most of the criterias mentioned in the guideline.
Hossein.ir 14:22, 11 July 2006 (UTC)[reply]

OKAY, AGAIN, THIS SOFTWARE CANNOT RECOVER FILES FROM EXT3 VOLUMES. DELETED FILES ON EXT3 VOLUMES CANNOT BE RECOVERED WITH THIS SOFTWARE. EXT3 VOLUME FILES, WITH THIS SOFTWARE, CANNOT BE RECOVERED. THEY SAY THAT, QUITE CLEARLY, ON THEIR OWN WEBSITE. PLEASE READ THEIR WEBSITE: "Provides recovery of deleted file(s) for Ext2 File system only". AlistairMcMillan 16:39, 11 July 2006 (UTC)[reply]

Nope! You're absolutely wrong. Get the software, Install it, and tell me it doesn't work. I've used it and it works. What do you say then? And please don't lie ;-) Have you ever heard of google before? This is the first result of searching "stellar Linux": 

Linux Data Recovery Software for Ext2, Ext3 Volume Recovery ...
Stellar Pheonix Linux - is fully automatic Linux data recovery software 
for the Ext2 and Ext3 File System volumes. 
Recovers data from Ext2 and Ext3 File ...

You're really careless. You don't even need to open the website. At least someone can use grep(read the faq). So don't tell "It's impossible", "It's impossible". And don't write it all caps. It's the way Internet trolls write. If you were in IRC, someone would probably ban you. So, take care. Please read the guideline I've mentioned before. Please read their website. Please try to do a little googling before speaking in this way. Please watch some famous Linux related website before claiming what works and what don't works. Hossein.ir 21:00, 12 July 2006 (UTC)[reply]

  • Step 1: Open this page http://www.stellarinfo.com/linux-data-recovery.htm in a web browser.
  • Step 2: Find the section header titled: "Key Features"
  • Step 3: Find and read the third sentence that begins with the words "Provides recovery of deleted file(s)..." and ends with the words "...for Ext2 File system only."
  • Step 4: ???
  • Step 5: Profit!!!
AlistairMcMillan 21:38, 12 July 2006 (UTC)[reply]
I think the confusion stems from the fact that the link (www.stellarinfo.com/linux-data-recovery.htm) is unclear on exactly what can be recovered. I doubt that the ambiguity is entirely accidental; it probably benefits sales of the product, by increasing the number of users who hope to recover lost data.
The site says both of the following:
  1. Stellar Phoenix Linux - is ... software for Ext2 and Ext3 File system volumes.
  2. Provides recovery of deleted file(s) for Ext2 File system only.
Not having used the software, my impression is that it can recover blocks of data from Ext3 volumes, but not entire files. I don't think it is possible to recover files, given the FAQ that Hossein.ir linked above, which says that Ext3 "actually zeros out the block pointers in the inode" when deleting files.
My opinion is that the link should not be included until it is added by an editor who has used it and found it useful. After adding the link, Hossein.ir said "I haven't actually used the software". Wmahan. 22:14, 12 July 2006 (UTC)[reply]
Although you can read this in another part of the page:
I think they've talked of ext2, because they wanted to make a difference from their other tools that recover files from fat32/NTFS. But, I agree with Wmahan. AlistairMcMillan, are you proud enough to check this software, or you want to repeat "it's fake", "it's fake" all the time?
Hossein.ir 20:09, 13 July 2006 (UTC)[reply]
I have three words for you: no original research. AlistairMcMillan 21:13, 13 July 2006 (UTC)[reply]
As Wmahan mentioned, block pointers in the inodes are zeroed. But it does not actually zero the blocks, so it's possible to recover the files, at least in theory. And as I've read their website, they claim that their software has a "unique" scanning method, that finds deleted files, and recover them. As I remember, when the virus Chernobyl deleted many computers data by deleting partition tables, some guy had wrote a program that could recover the partition table, by scanning through the disk. You can find it here. Technically, I think this is feasible, because there's a chain of pointers, that you've lost one level of them. see inode for more information.
Hossein.ir 20:26, 13 July 2006 (UTC)[reply]
Btw, look at this open source software, Salvage. Please try it, and tell your opinion. It seems that including a link to this, is better from mentioning that propertiary product.
From its web page:
Hossein.ir

I'm sure I asked this before, but can you point to a single verifiable source on either of these programs? AlistairMcMillan 21:23, 13 July 2006 (UTC)[reply]

For sure Yes. The latter program is a patch to the latest version of e2fsprogs, by a usuall contributor to e2fsprogs, and I think it will be merged into upstream in next version(it's not now). Keld Simonsen, the author, is a usuall contributor to [e2fsprogs]. The program is a opensource software, that is available for downlaod, and testing; I've downloaded, compiled, and tested the program and it worked, but as as I know, for wikipedia this is not enough. But consider that Keld Simonsen, is a professional Linux programmer, and he has two RFCS. It seems that he's a notable person, and he deserves a page in wikipedia. I can not find a better way to make you understand This really works. If you were a expert in this area, we would have no problems. Do you have any experience in free software(ever heard of GNU??) and specially Linux?

For the previous program, there are a lot of well-known Linux-related website, that have listed this program.

These were some famous websites from so many other sources. It's not original research.

Hossein.ir 22:16, 13 July 2006 (UTC)[reply]

Have you read our policies on sources? Those are software directories. Anyone can get software listed in a directory. We're looking for something like a magazine review... AlistairMcMillan 23:18, 13 July 2006 (UTC)[reply]
Ok, in this way, I can not even talk about the e2fsprogs itself. If I want to say that "there's a patch that does that thing" what should I do? Hey, we're talking about software. In the way that you think, even articles like GNOME and XFCE are invalid, because all the external links lead to their website, and their friends'. What about the Stellar Phoenix Linux? The sources seems to be enough.
BTW, when I explain the problem to you to show you it's feasible, and I give you links, you call it original research. Have you read the guideline yourself? It's mainly used for physics, and these kind of things. It seems that you've read it like the web pages of the Stellar Phoenix Linux(Just first few lines). Hey, I'm not researching. I'm giving you some links, to some well know websites, that introduce this software. If I find a magazine that contains an article, do you call it research....! I want to talk with another person about this issue. It seems that this is your POV.
Hossein.ir 00:25, 14 July 2006 (UTC)[reply]
I forgot to say, how can I find a source for a source or an external link for an external link? Have you thought of this? No external link has an extra external link to prove itself.
Hossein.ir 00:30, 14 July 2006 (UTC)[reply]

Should the fact that it is much harder to recover deleted files from an ext3 filesystem than a ext2 filesystem be added to the main page with a brief explanation of the zeroing of file pointers and the use of grep as a possible solution? This is an important factor in choosing an appropriate file system, not suggesting that using ext2 replaces the need for backup. Personally I believe it should be added to the disadvantages section. The size of the discussion of this section indicates it importance to people. 81.103.161.189 (talk) 17:43, 4 August 2008 (UTC)[reply]

--- Some more infos about deletion.

On ext2, the inode number is deleted from the directory index (don't know why) and you have to recover it manually by inspecting all deleted inode (knowing that there is a good probability that it is still in the same block group than the parent directory). All inode informations are preserved, so, as soon as nothing has been overwritten, recovery is straightforward.

On ext3, the inode number is preserved in the directory index... but the pointers to all direct and indirect blocs are cleared in the inode (this is a well known fact, even if i'm not sure WHY this is usefull to prevent corruption after an unlink). However, the direct and indirect blocks themself, are untouched. I don't have any reference for this, but there are multiple evidence: the Salvage tool exploit this feature, as well as ext3-grep, and one more method depicted in this article.

In addition, as cited in the previous article, and used by ext3-grep, you can use data from the ext3 journal to recover an old version of the deleted file inode as well as all the pointers to the direct and indirect blocs. This works, wathever journaling mode you use (metadata are always saved to the journal). In addition, when a single inode from a block group is written to the journal, all the other inodes from the same group are written as well (once again, no particular reference to give you). This increase furthermore the chances to retrieve the inode from the journal. Knowing that the default size for the journal is 128Mo, if you act quickly (just as you need for ext2 partitions) you have a fair chance to recover the inode, and your file.

We can also say that both ext2 and ext3 are well suited for data carving, since they have minor fragmentations, and also because you can do some guess in which block groups the file is located (probably in the same group than the parent directory).

So definitively, recovering file on ext3 is possible and... i would say... not very difficult (if you act quickly). —Preceding unsigned comment added by Mhz42 (talk • contribs) 06:51, 10 July 2009 (UTC)[reply]

--- UFS Explorer Standard Recovery version 4??

Why would this external link to some commercial software be here? There are enough tools on a basic linux install to recover deleted files. I've done it myself. You can just "cat /dev/sda1 > dumpfile" and then grep through it for the contents, or even just do something like "strings /dev/sda1 |grep contents" to find text files. That being said, why would you directly link to some exploitive commercial product before linking to ext3grep which is free, open-source, and verifiably works? This is an add on a wikipedia article, period. —Preceding unsigned comment added by 75.147.236.238 (talk) 18:41, 18 December 2009 (UTC)[reply]

ext3 dirindex[edit]

What is ext3 dir-index about and shouldn't it be mentioned in the Ext3 article?--Hhielscher 20:11, 6 October 2006 (UTC)[reply]

dir_index is another name for H-Tree directory indexing. It's the name used by tune2fs, e.g. tune2fs -O dir_index /dev/hda1 . Yep I think it should be mentioned, I found the different names for the same thing confusing. Dj68 22:51, 16 November 2006 (UTC)[reply]

Defragmentation[edit]

There is a tool which can be used for ext3, "shake" :

Scullder 19:51, 8 December 2006 (UTC)[reply]

There is a tool from a Kerneldeveloper, just some script, he claims that it is "filesystem agnostic". For me it "just works (tm)" on ext3 while being mounted. It can be found here: http://ck.kolivas.org/apps/defrag/

"Is a lack of defrag tool a disadvantage? I mean: Does impact in a serious way the fragmentation on ext3? I don't think so, but..."

--Sebelk 01:50, 20 December 2006 (UTC)[reply]

In order to check the fragmentation on ext3 one can use the filefrag(1) utility. It is built above the FIBMAP and FIGETBSZ ioctls which which allow to enumerate the physical blocks used by a given file. As these ioctls can be implemented on various filesystems, filefrag(1) might work on something else than ext3 as well. Defragmenting is just copying the file data to a new file, checking whether it is less fragmented, and possibly replacing the original file.... Adam Mirowski (talk) 19:51, 13 April 2008 (UTC)[reply]

File timestamps resolution[edit]

Would it be relevant to mention that ext3 does not have sub-second timestamps resolution, in contrast with other file systems (NTFS?). I personally would have liked to find that information in Wikipedia, especially if it was comparative.

Rngadam 18:43, 15 January 2007 (UTC)[reply]

I think this is relevant. Please add...

Maximum File Size[edit]

Most people want to know the maximum file size of THEIR ext3 file system.

In order to do this, they must determine the block size of THEIR file system.

Currently, this entry provides a table that tells the max file size for various block sizes, but it offers little direction for people to determine THEIR ext3's maximum file size.

I wrote an article that tells people how to determine their block size in Linux: http://www.howtoadvice.com/Ext3Max/

Many people will find this link very helpful. Please consider it for linkage. —Preceding unsigned comment added by 209.0.204.89 (talk) 00:10, 3 October 2007 (UTC)[reply]

I've corrected the max file size for the 8KiB block size. The source document (http://www.charmed.com/txt/ext2.txt) says 2TiB and that is correct because it's limited by the i_blocks field which stores the size as 512byte blocks as a 32bit number. --Djm6809 (talk) 02:40, 20 November 2007 (UTC)[reply]

Linux kernel source file linux/fs/ext3/super.c contains a function ext3_max_size which clearly confirms the above comment. Ekscrypto (talk)

Maximum size stats[edit]

The table currently in the article contradicts [1] which says:

Ext3 can support files up to 1TB. With a 2.4 kernel the filesystem size is limited by the maximal block device size, which is 2TB. In 2.6 the maximum (32-bit CPU) limit is of block devices is 16TB, but ext3 supports only up to 4TB.

Can anyone determine what the truth is? The source which is referenced in the article now is much older than the FAQ, and is from the era before ext3 was available for Linux 2.4 kernels. -- Beland (talk) 18:18, 23 January 2008 (UTC)[reply]

Your article is outdated. Probably wikipedia should specify that 4K is by far the most common blocksize for PCs, and its limits are 16T for filesystems, and 2T for files. That's what most people care about, anyway.86.120.236.174 (talk) —Preceding comment was added at 06:20, 22 March 2008 (UTC)[reply]
Well, there are people who use 8k, 16k, and even larger filesystems. These only work on architectures such as the Itanium, Power PC, etc., where the page size is greater than 4k. (The block size must be less than or equal to the page size.) So this isn't common, but table in the filesystem does list the maximum filesystem size based on block size, which is a correct thing to do. I have received bug reports in e2fsprogs saying that things don't quite work right if you try to use a block size of 64k and you have an empty directory block, so there are people experimenting with block sizes up to 64k.Ted (talk) 15:30, 19 April 2008 (UTC)[reply]

---

According to http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.18

commit 1c2bf374a4b8c2e1a3e6ff3a64fb67272a8cd2e2

Author: Mingming Cao <cmm@us.ibm.com>

Date: Sun Jun 25 05:48:06 2006 -0700

[PATCH] ext3_fsblk_t: filesystem, group blocks and bug fixes

Some of the in-kernel ext3 block variable type are treated as signed 4 bytes int type, thus limited ext3 filesystem to 8TB (4kblock size based).

With this series of patches and the percpu counter data type changes in the mm tree, we are able to extend exts filesystem limit to 16TB. —Preceding unsigned comment added by 78.142.44.252 (talk) 18:34, 16 July 2008 (UTC)[reply]

---

I think there is a major inconsitency between the ext2 article, which states that the max. file size is 4Tib whith 4Kib blocks, while in the ext3 article, the limit is said to be 2Tib.

It is not difficult to compute what the max file size is: you have 12 direct blocks, one indirect block, one 2x indirect block, and one 3x indirect block. So if the block size is B (def: 4Kib), and the blocks are addressed on L bits (def: 32bits), you can address N=B/L blocks per indirect blocks (def: 1024). The max file size is therefore (12 + N + N^2 + N^3) * B, which will give with the default values: 4.4Tib. This is true both for ext2 and ext3 file. You can have more specific info here

The 2Tib limit was specific to an old branch of the linux kernel and is not part of the ext specifications. It has nothing to do in this article. The values in the array have to be fixed. —Preceding unsigned comment added by Mhz42 (talk • contribs) 07:33, 10 July 2009 (UTC)[reply]


Changed values of Max Filesystem size to agree with ext2 documentation. Also article previously stated that max blocks is 2^31-1. I find no support for that outside this article. I am also curious as to the non-linearity for the lowest block size, and wonder if that is a typo in the original source or is an implementation bug due to unsigned/signed confusion. Ozga (talk) 01:18, 24 November 2009 (UTC)[reply]


---

I think we should change the values back to 2**31-1 blocks and therefore a bit under 8TiB for 4K blocks. Here is what I got on Ubuntu Hardy 8.0.4.4 LTS with a partition of over 8.2TB when running mkfs.ext3: 

        mkfs.ext3: Filesystem too large.  No more than 2**31-1 blocks
        (8TB using a blocksize of 4k) are currently supported.

So practically even if ext3 MAY support 16TB with 4KB blocks, e2fsprogs and mkfs do not support it, making it a moot point

Pombredanne (talk) 16:24, 21 May 2010 (UTC)[reply]

I strongly agree with the above. In truth I purchased a 12 TB raid array based on the main article's listed 16TB maximum and just ran into exactly the same error from mkfs.ext3 - 8TB maximum. This is very misleading. —Preceding unsigned comment added by 146.186.104.173 (talk) 18:58, 25 January 2011 (UTC)[reply]

Subdirectory limit[edit]

I've just been discussion ext3 limitations on IRC. Of particular interest is the following line in note #1:

The max number of subdirectories in one directory is fixed to 32000.

This is not entirely correct. The maximum number of hardlinks per inode is fixed at 32000. Every directory in the filesystem has one hardlink consumed for:

  • the '.' special directory and
  • the parent directory's link (if not /) and
  • lost+found's '..' link (if the root of the mountable filesystem)

Thus, the maximum number of subdirectories you can have in any one directory varies between 31998 and 31997.

- Man in shack (talk) 13:32, 13 June 2008 (UTC)[reply]

Please give a reference. Otherwise this information is of no use. - 16:01 (UTC+1), 2009-04-08

Ext3 fragmentation VS Ntfs fragmentation[edit]

Hi I noticed someone keeps adding that ext3 is more resistent to fragmentation than NTFS. Is this a myth or fact? I dont think we will ever know unless Microsoft releases the source code for NTFS.--Thunderpenguin (talk) 14:49, 7 July 2008 (UTC)[reply]

It is wishful thinking. People do not realize that ext3 fragments because the tools for checking this are not popular, and the topic is kind of taboo and religious. My recent experience is that ext3 fragments quite a bit, and the tools to see this are actually very simple; I already mentioned them above. As far as NTFS is concerned, fragmentation can be evaluated very easily too, because reading NTFS is something people have been doing for 10 years now. Theoretically the same Linux tools should work for both filesystems, but strangely do not (IIRC). Also, please note that disk space allocation policy is largely a matter of software, so it is quite possible that the Linux NTFS filesystem implementation fragments differently than MS implementation. All this is irrelevant anyway, because Wikipedia should be based on reliable sources, and not on private research. And this competitive and performance-related topic is sensitive too, so many sources will be naturally biased. Adam Mirowski (talk) 00:44, 8 July 2008 (UTC)[reply]

I also found that the windows defragmenter calculates the fragmentation different too.--Thunderpenguin (talk) 03:59, 8 July 2008 (UTC)[reply]

Many sites tell to leave about 15% free of your ext3 drive to avoid fragmentation. So maybe ext3 fragmentation happens because of inproper usage. 213.243.169.251 (talk) 14:31, 29 July 2008 (UTC)[reply]

Extents?[edit]

There's that strange comment about ext3 not supporting extents. My understanding was that it was called the extended filesystem because it did support extents. So, marking as citation required. Mugwumpjism (talk) 21:54, 24 July 2008 (UTC)[reply]

No it does not support extents. It uses an old block mapping scheme which uses direct indirect blocks ETC. I citied the source to--Thunderpenguin (talk) 15:29, 31 July 2008 (UTC)[reply]

Trees[edit]

What does ext3 use? Htrees or Hashed Btrees? Someone changed it to Hashed Btrees.--Thunderpenguin (talk) 02:37, 31 August 2008 (UTC)[reply]

Htree Widefox (talk) 07:28, 5 May 2009 (UTC)[reply]

Cleanup needed - Size limits[edit]

The article confuses the terms KiB/kB, MiB/MB, GiB/GB and TiB/TB. Without delving into extensive research, I don't know what the past editors actually meant to say, if, indeed, they knew the difference between these pairs of terms. Accordingly, I've tagged the "Size limits" section for cleanup. —QuicksilverT @ 02:26, 11 December 2010 (UTC)[reply]

What makes you think that they're confused? All the limits are powers of two, therefore using SI prefixes is accurate. -- intgr [talk] 17:00, 11 December 2010 (UTC)[reply]

References Link 7 is broken (Roderick W. Smith (2003-10-09)....) — Preceding unsigned comment added by 93.34.158.45 (talk) 14:51, 3 January 2012 (UTC)[reply]

References Link 11 is broken. — Preceding unsigned comment added by 66.203.207.68 (talk) 12:59, 20 May 2015 (UTC)[reply]

External links modified[edit]

Hello fellow Wikipedians,

I have just added archive links to one external link on Ext3. 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).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers. —cyberbot IITalk to my owner:Online 02:22, 28 August 2015 (UTC)[reply]

External links modified[edit]

Hello fellow Wikipedians,

I have just modified one external link on Ext3. 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).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 11:20, 26 September 2017 (UTC)[reply]

External links modified[edit]

Hello fellow Wikipedians,

I have just modified one external link on Ext3. 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).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 00:18, 3 December 2017 (UTC)[reply]

Heading order[edit]

Hello, I found that it was necessary to move the "References" heading underneath the "External links" because the reference named ":1" was giving an error: "invoked but never defined" due to its replication in one of the external link items. Hope this is not too confusing or out-of-the-ordinary. 2600:8800:1880:188:5604:A6FF:FE38:4B26 (talk) 09:58, 25 November 2018 (UTC)[reply]

The error was caused by a stray ref tag, which I've removed. External links generally do not have references. BlackcurrantTea (talk) 10:53, 25 November 2018 (UTC)[reply]
Sounds good! Thanks. 2600:8800:1880:188:5604:A6FF:FE38:4B26 (talk) 10:59, 25 November 2018 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Ext3&oldid=1201814191"