![]() | This article is rated B-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||||
|
![]() | On 20 December 2008, Ext3 was linked from Slashdot, a high-traffic website. ( Traffic) All prior and subsequent edits to the article are noted in its revision history. |
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 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)
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:
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)
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)
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)
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)
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)
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
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)
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)
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)
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)
“ | File System Supported: Recovers data from Ext2 and Ext3 File system volumes on all flavours of Linux including Red Hat, Suse, Caldera, SCO, Debian, Mandrake, Sorcerer, TurboLinux, Slackware, Gentoo and others. |
” |
“ | Salvage or undelete files of damaged ext2/ext3 file systems
debugfs salvage command can be used to salvage files from a damaged ext3 or ext2 file system. The code is alpha, so use at your own risk. salvage first-block count-blocks Salvage is an addition to the debugfs program in the e2progs package by Ted Ts'o. |
” |
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)
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)
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)
--- 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)
--- 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)
What is ext3 dir-index about and shouldn't it be mentioned in the Ext3 article?-- Hhielscher 20:11, 6 October 2006 (UTC)
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)
There is a tool which can be used for ext3, "shake" :
Scullder 19:51, 8 December 2006 (UTC)
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)
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)
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)
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)
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)
Linux kernel source file linux/fs/ext3/super.c contains a function ext3_max_size which clearly confirms the above comment. Ekscrypto ( talk)
The table currently in the article contradicts [1] which says:
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)
---
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)
---
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)
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)
---
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)
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)
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:
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)
Please give a reference. Otherwise this information is of no use. - 16:01 (UTC+1), 2009-04-08
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)
I also found that the windows defragmenter calculates the fragmentation different too.-- Thunderpenguin ( talk) 03:59, 8 July 2008 (UTC)
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)
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)
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)
What does ext3 use? Htrees or Hashed Btrees? Someone changed it to Hashed Btrees.-- Thunderpenguin ( talk) 02:37, 31 August 2008 (UTC)
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. — Quicksilver T @ 02:26, 11 December 2010 (UTC)
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)
References Link 11 is broken. — Preceding unsigned comment added by 66.203.207.68 ( talk) 12:59, 20 May 2015 (UTC)
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: 5 June 2024).
Cheers. — cyberbot II Talk to my owner:Online 02:22, 28 August 2015 (UTC)
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: 5 June 2024).
Cheers.— InternetArchiveBot ( Report bug) 11:20, 26 September 2017 (UTC)
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: 5 June 2024).
Cheers.— InternetArchiveBot ( Report bug) 00:18, 3 December 2017 (UTC)
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)
![]() | This article is rated B-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||||
|
![]() | On 20 December 2008, Ext3 was linked from Slashdot, a high-traffic website. ( Traffic) All prior and subsequent edits to the article are noted in its revision history. |
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 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)
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:
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)
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)
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)
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)
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)
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
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)
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)
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)
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)
“ | File System Supported: Recovers data from Ext2 and Ext3 File system volumes on all flavours of Linux including Red Hat, Suse, Caldera, SCO, Debian, Mandrake, Sorcerer, TurboLinux, Slackware, Gentoo and others. |
” |
“ | Salvage or undelete files of damaged ext2/ext3 file systems
debugfs salvage command can be used to salvage files from a damaged ext3 or ext2 file system. The code is alpha, so use at your own risk. salvage first-block count-blocks Salvage is an addition to the debugfs program in the e2progs package by Ted Ts'o. |
” |
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)
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)
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)
--- 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)
--- 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)
What is ext3 dir-index about and shouldn't it be mentioned in the Ext3 article?-- Hhielscher 20:11, 6 October 2006 (UTC)
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)
There is a tool which can be used for ext3, "shake" :
Scullder 19:51, 8 December 2006 (UTC)
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)
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)
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)
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)
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)
Linux kernel source file linux/fs/ext3/super.c contains a function ext3_max_size which clearly confirms the above comment. Ekscrypto ( talk)
The table currently in the article contradicts [1] which says:
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)
---
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)
---
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)
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)
---
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)
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)
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:
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)
Please give a reference. Otherwise this information is of no use. - 16:01 (UTC+1), 2009-04-08
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)
I also found that the windows defragmenter calculates the fragmentation different too.-- Thunderpenguin ( talk) 03:59, 8 July 2008 (UTC)
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)
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)
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)
What does ext3 use? Htrees or Hashed Btrees? Someone changed it to Hashed Btrees.-- Thunderpenguin ( talk) 02:37, 31 August 2008 (UTC)
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. — Quicksilver T @ 02:26, 11 December 2010 (UTC)
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)
References Link 11 is broken. — Preceding unsigned comment added by 66.203.207.68 ( talk) 12:59, 20 May 2015 (UTC)
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: 5 June 2024).
Cheers. — cyberbot II Talk to my owner:Online 02:22, 28 August 2015 (UTC)
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: 5 June 2024).
Cheers.— InternetArchiveBot ( Report bug) 11:20, 26 September 2017 (UTC)
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: 5 June 2024).
Cheers.— InternetArchiveBot ( Report bug) 00:18, 3 December 2017 (UTC)
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)