From roland.olbricht at gmx.de Sun Aug 17 17:28:33 2014 From: roland.olbricht at gmx.de (Roland Olbricht) Date: Sun, 17 Aug 2014 19:28:33 +0200 Subject: What uses these 50 GB? Message-ID: <53F0E641.7030907@gmx.de> Hello everybody, first of all thank you the development of Ext2/3/4. It works like a charm and makes it possible to base applications on it. However, now I have the first time where I need more information to understand the behaviour of a ext4 installation on a 480 GB harddisk. It holds a database with a size of 355 GB, as said by "du -m": ... 355263 /opt/ssd However, "df" says: Filesystem 1K-blocks Used Available Use% Mounted on ... /dev/sdc 468346644 409888536 35015532 93% /opt/ssd I do understand why there is a gap between "Used" plus "Available" and "1K-blocks", but I don't understand why "Used" is so much bigger (54 GB difference) than what "du -m" indicates. I can rule out any issues with inodes; "df -i" indicates that less than one percent is used. I tried to understand more details by using "debugfs". I thought I get a full list of used blocks with: for i in *; do { echo "blocks $i" | sudo debugfs /dev/sdc | grep -vE "^debugfs" | awk '{ for (i=1; i < NF; ++i) print $i; }'; }; done which delivered 90938943 lines (containing block numbers allocated by visible files). But echo "testb 1 117330000" | sudo debugfs /dev/sdc | grep "marked in use" has delivered 102595007 lines (containing block numbers marked as "used"). I tried to learn more about blocks marked as "marked in use" but not by a known file, and echo "icheck 98304 98305" | sudo debugfs /dev/sdc returned debugfs: icheck 98304 98305 Block Inode number 98304 98305 Could somebody explain to be what the purpose of these 11,656,064 blocks is that don't belong to an inode but are still marked as used? Do I have a chance other than reformatting the drive to get back this space? Best regards, Roland From sandeen at redhat.com Sun Aug 17 18:00:47 2014 From: sandeen at redhat.com (Eric Sandeen) Date: Sun, 17 Aug 2014 13:00:47 -0500 Subject: What uses these 50 GB? In-Reply-To: <53F0E641.7030907@gmx.de> References: <53F0E641.7030907@gmx.de> Message-ID: <53F0EDCF.5080506@redhat.com> On 8/17/14, 12:28 PM, Roland Olbricht wrote: > Hello everybody, > > first of all thank you the development of Ext2/3/4. It works like a > charm and makes it possible to base applications on it. > However, "df" says: > > Filesystem 1K-blocks Used Available Use% Mounted on > ... > /dev/sdc 468346644 409888536 35015532 93% /opt/ssd > Could somebody explain to be what the purpose of these 11,656,064 > blocks is that don't belong to an inode but are still marked as > used? At least some is filesystem metadata. mkfs.ext4 preallocates inode tables, bitmaps, etc, and that takes space from the filesystem. But that's not supposed to be shown by default, with the "bsddf" behavior that's hidden from the total available. >From above, 468346644*1024=479586963456; let's make a filesystem of the same size: # truncate --size=479586963456 fsfile # mkfs.ext4 fsfile # mount -o loop fsfile # df mnt/ Filesystem 1K-blocks Used Available Use% Mounted on /tmp/fsfile 460865340 71736 437359888 1% /tmp/mnt Hm, that doesn't have the same "1k blocks" value as you saw. What if we mount it with minixdf, which doesn't "hide" fs-internal metadata from the totals? # umount mnt/ # mount -o minixdf,loop fsfile mnt # df mnt/ Filesystem 1K-blocks Used Available Use% Mounted on /tmp/fsfile 468346644 7553040 437359888 2% /tmp/mnt now the 1k-blocks total matches your output; you must be mounting with minidxf for some reason. 468346644-460865340 is 7481304 1k blocks, or 7G, so that's some of it. If you have one nonstandard mount option, perhaps there are other tweaks you've made at mkfs time which could change the geometry from what I see above. dumpe2fs -h output might show us that. It could also be open but unlinked files, or unprocessed orphan inodes after a crash. Have you run e2fsck? > debugfs: icheck 98304 98305 > Block Inode number > 98304 > 98305 icheck won't find an inode number for internal metadata; it's not associated with any inode. > Do I have a chance other than reformatting the drive to get back this > space? It shouldn't be "lost" - repeating the same administration steps should lead to the same space usage. You could choose to rereate it with fewer inodes, to save some inode table space... -Eric From roland.olbricht at gmx.de Sun Aug 17 19:05:50 2014 From: roland.olbricht at gmx.de (Roland Olbricht) Date: Sun, 17 Aug 2014 21:05:50 +0200 Subject: What uses these 50 GB? In-Reply-To: <53F0EDCF.5080506@redhat.com> References: <53F0E641.7030907@gmx.de> <53F0EDCF.5080506@redhat.com> Message-ID: <53F0FD0E.3010105@gmx.de> Hello Eric, thank you for the quick reply and the explanations. > dumpe2fs -h output might show us that. Filesystem volume name: Last mounted on: /opt/ssd Filesystem UUID: 75d6aae6-1746-4260-994b-148dfdb5af95 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize Filesystem flags: signed_directory_hash Default mount options: user_xattr acl Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 29310976 Block count: 117212886 Reserved block count: 5860644 Free blocks: 115322570 Free inodes: 29310965 First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 996 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8192 Inode blocks per group: 512 Flex block group size: 16 Filesystem created: Wed Apr 16 06:31:53 2014 Last mount time: Wed Apr 16 06:48:26 2014 Last write time: Wed Apr 16 06:48:26 2014 Mount count: 1 Maximum mount count: -1 Last checked: Wed Apr 16 06:31:53 2014 Check interval: 0 () Lifetime writes: 133 MB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 28 Desired extra isize: 28 Journal inode: 8 First orphan inode: 8388637 Default directory hash: half_md4 Directory Hash Seed: a094608e-671f-4a9c-81e8-81bb72eb4516 Journal backup: inode blocks Journal features: journal_incompat_revoke Journal size: 128M Journal length: 32768 Journal sequence: 0x001d92ff Journal start: 27755 > It could also be open but unlinked files, or unprocessed orphan inodes > after a crash. Have you run e2fsck? No, not yet. Shoud I do this routinely? Running sudo e2fsck -fn /dev/sdc gives as result: Warning! /dev/sdc is mounted. Warning: skipping journal recovery because doing a read-only filesystem check. Pass 1: Checking inodes, blocks, and sizes Deleted inode 8388637 has zero dtime. Fix? no Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information Block bitmap differences: -(9255--9422) -(33793--33801) -(33808--33870) ... (really long list) Fix? no Free blocks count wrong (115322570, counted=14605339). Fix? no Inode bitmap differences: -8388637 Fix? no Free inodes count wrong (29310965, counted=29310750). Fix? no /dev/sdc: ********** WARNING: Filesystem still has errors ********** /dev/sdc: 11/29310976 files (272.7% non-contiguous), 1890316/117212886 blocks So I assume the best thing to do here would be to unmount the disk and do a e2fsck? Best regards, Roland From sandeen at redhat.com Sun Aug 17 19:36:23 2014 From: sandeen at redhat.com (Eric Sandeen) Date: Sun, 17 Aug 2014 14:36:23 -0500 Subject: What uses these 50 GB? In-Reply-To: <53F0FD0E.3010105@gmx.de> References: <53F0E641.7030907@gmx.de> <53F0EDCF.5080506@redhat.com> <53F0FD0E.3010105@gmx.de> Message-ID: <53F10437.4060501@redhat.com> On 8/17/14, 2:05 PM, Roland Olbricht wrote: > Hello Eric, > > thank you for the quick reply and the explanations. > >> dumpe2fs -h output might show us that. > > Filesystem volume name: ... > Filesystem created: Wed Apr 16 06:31:53 2014 > Last mount time: Wed Apr 16 06:48:26 2014 > Last write time: Wed Apr 16 06:48:26 2014 > Mount count: 1 > Maximum mount count: -1 > Last checked: Wed Apr 16 06:31:53 2014 > Check interval: 0 () > Lifetime writes: 133 MB > Reserved blocks uid: 0 (user root) > Reserved blocks gid: 0 (group root) > First inode: 11 > Inode size: 256 > Required extra isize: 28 > Desired extra isize: 28 > Journal inode: 8 > First orphan inode: 8388637 ... Ok, pretty standard, and it appears that you mkfs'd it in april, mounted it, and have never unmounted it. (Nor has it ever crashed, apparently). Also, the last line above shows that there is at least one orphan inode, meaning it's open but unlinked. Blocks aren't freed until it's closed; that may be where all the space is. > >> It could also be open but unlinked files, or unprocessed orphan inodes >> after a crash. Have you run e2fsck? > > No, not yet. Shoud I do this routinely? Running > > sudo e2fsck -fn /dev/sdc > > gives as result: > > Warning! /dev/sdc is mounted. > Warning: skipping journal recovery because doing a read-only filesystem check. and so the rest isn't useful. You'd have to unmount it to check it. ... > So I assume the best thing to do here would be to unmount the disk and do a e2fsck? Probably so, or figure out who has that orphan inode open... if that process lets go, the space may free up; if it doesn't let go, you won't be able to unmount... -Eric From billcun at suddenlink.net Sun Aug 17 19:52:46 2014 From: billcun at suddenlink.net (Bill Cunningham) Date: Sun, 17 Aug 2014 15:52:46 -0400 Subject: extended filesystems Message-ID: <749495512430486BB5034A66823496EF@apz7pobnnwb075> I would like to start experiemnting with the ext filesystems. I might like one day to develop something. :) What files contain the ext4 filesystem. That's what I'm running right now. I like ext 2/3/4 all of them. My fedora partition is only 20 GB in size. I don't need huge filesystem support which is a feature of ext4 I believe. Which feature can I remove to remove this feature? I know it would be done with tune2fs -O ^ and then the feature name. Why would I want to do this. to learn and I don't think I need it. Too much overhead. Bill From sandeen at redhat.com Sun Aug 17 20:47:01 2014 From: sandeen at redhat.com (Eric Sandeen) Date: Sun, 17 Aug 2014 15:47:01 -0500 Subject: extended filesystems In-Reply-To: <749495512430486BB5034A66823496EF@apz7pobnnwb075> References: <749495512430486BB5034A66823496EF@apz7pobnnwb075> Message-ID: <53F114C5.1090408@redhat.com> On 8/17/14, 2:52 PM, Bill Cunningham wrote: > I would like to start experiemnting with the ext filesystems. I might > like one day to develop something. :) What files contain the ext4 > filesystem. That's what I'm running right now. I like ext 2/3/4 all of them. fs/ext4/*.[ch] fs/jbd2/*.[ch] in the linux kernel source tree. > My fedora partition is only 20 GB in size. I don't need huge filesystem > support which is a feature of ext4 I believe. Which feature can I remove to > remove this feature? I know it would be done with tune2fs -O ^ and then the > feature name. Reading the tune2fs man page would be a start... > Why would I want to do this. to learn and I don't think I need it. Too > much overhead. The only feature unique to "huge filesystems" is the 64bit feature, and it's not used by default on a small filesystem; it also cannot be added or removed with tune2fs after the fact. So the first thing you've learned is that it is not in fact too much overhead, because it's not there. ;) -Eric From bothie at gmx.de Sun Aug 17 21:32:29 2014 From: bothie at gmx.de (Bodo Thiesen) Date: Sun, 17 Aug 2014 23:32:29 +0200 Subject: What uses these 50 GB? In-Reply-To: <53F0FD0E.3010105@gmx.de> References: <53F0E641.7030907@gmx.de> <53F0EDCF.5080506@redhat.com> <53F0FD0E.3010105@gmx.de> Message-ID: <20140817233229.267f350e@phenom> * Roland Olbricht hat geschrieben: Hi Roland > Reserved block count: 5860644 > Block size: 4096 Makes >20 GB. df doesn't show reserved clusters as free. That's why I always mke2fs -m 0 [...]. Tip: It's a tunable parameter, but as for e2fsck, you *really* should umount first. Also, not mentioned yet: Files big enough, that not all cluster pointers / extents fit in the inode itself, will take up additional meta data clusters. However, for ext2 with extents feature (which you have), this shouldn't really be much, I guess much much less than 1 GB. Regards, Bodo From roland.olbricht at gmx.de Sun Aug 17 21:53:32 2014 From: roland.olbricht at gmx.de (Roland Olbricht) Date: Sun, 17 Aug 2014 23:53:32 +0200 Subject: What uses these 50 GB? In-Reply-To: <53F10437.4060501@redhat.com> References: <53F0E641.7030907@gmx.de> <53F0EDCF.5080506@redhat.com> <53F0FD0E.3010105@gmx.de> <53F10437.4060501@redhat.com> Message-ID: <53F1245C.30007@gmx.de> Hello Eric, > Ok, pretty standard, and it appears that you mkfs'd it in april, > mounted it, and have never unmounted it. (Nor has it ever crashed, > apparently). > > Also, the last line above shows that there is at least one orphan > inode, meaning it's open but unlinked. Blocks aren't freed > until it's closed; that may be where all the space is. Thank you. That was indeed the cause of the problem. There was a single file that has been deleted some month ago, but the process which kept it open was still alive. I'll add a check for open deleted files to my checklist. Best regards, Roland From billcun at suddenlink.net Mon Aug 18 17:33:02 2014 From: billcun at suddenlink.net (Bill Cunningham) Date: Mon, 18 Aug 2014 13:33:02 -0400 Subject: extended filesystems References: <749495512430486BB5034A66823496EF@apz7pobnnwb075> <53F114C5.1090408@redhat.com> Message-ID: <8D57C458C8A3455F89DC16455699F8DC@apz7pobnnwb075> ----- Original Message ----- From: "Eric Sandeen" To: "Bill Cunningham" ; Sent: Sunday, August 17, 2014 4:47 PM Subject: Re: extended filesystems [snip] > So the first thing you've learned is that it is not in fact too much > overhead, because it's not there. ;) > > -Eric Ok I see. Well I have used fsarchiver to save my ext4 system and the mkfs option to uninstall everything as an ext2 filesystem. Everything uncompress and is written to the block device much more quickly. I know with ext3 there is the journal inode which isn't present on ext2. Well anyway is this list for the entire ext family or just ext3? Bill From sandeen at redhat.com Mon Aug 18 17:34:57 2014 From: sandeen at redhat.com (Eric Sandeen) Date: Mon, 18 Aug 2014 12:34:57 -0500 Subject: extended filesystems In-Reply-To: <8D57C458C8A3455F89DC16455699F8DC@apz7pobnnwb075> References: <749495512430486BB5034A66823496EF@apz7pobnnwb075> <53F114C5.1090408@redhat.com> <8D57C458C8A3455F89DC16455699F8DC@apz7pobnnwb075> Message-ID: <53F23941.8050002@redhat.com> On 8/18/14, 12:33 PM, Bill Cunningham wrote: > > ----- Original Message ----- From: "Eric Sandeen" > To: "Bill Cunningham" ; > Sent: Sunday, August 17, 2014 4:47 PM > Subject: Re: extended filesystems > > [snip] > >> So the first thing you've learned is that it is not in fact too much >> overhead, because it's not there. ;) >> >> -Eric > > Ok I see. Well I have used fsarchiver to save my ext4 system and the mkfs option to uninstall everything as an ext2 filesystem. Everything uncompress and is written to the block device much more quickly. I know with ext3 there is the journal inode which isn't present on ext2. > > Well anyway is this list for the entire ext family or just ext3? > > Bill > linux-ext4 at vger.kernel.org is the list for all of them. ext3-users isn't used much. -Eric From billcun at suddenlink.net Mon Aug 25 19:19:09 2014 From: billcun at suddenlink.net (Bill Cunningham) Date: Mon, 25 Aug 2014 15:19:09 -0400 Subject: filesystem Message-ID: <164EA3526D4E4A98A7590E7E05B73037@a8qn1legfukpv6> I hope this is the right list. I have created an ext2 filesystem and removed the dir_index feature. I don't know if this kind of experimentation is going to help me learn something about filesystems or not. Well what is dir_index? Then I ran e2fsck -f -v -pD and the /dev file. Now what did I remove? Htree. I guess it can always be put back and it's on an experimental filesystem. What features separate ext4 from ext3 ? I have noticed too that ext2 fragments quite a bit. Bill From bothie at gmx.de Tue Aug 26 00:15:05 2014 From: bothie at gmx.de (Bodo Thiesen) Date: Tue, 26 Aug 2014 02:15:05 +0200 Subject: filesystem In-Reply-To: <164EA3526D4E4A98A7590E7E05B73037@a8qn1legfukpv6> References: <164EA3526D4E4A98A7590E7E05B73037@a8qn1legfukpv6> Message-ID: <20140826021505.235b3d51@phenom> * "Bill Cunningham" hat geschrieben: > I hope this is the right list. I have created an ext2 filesystem and > removed the dir_index feature. I don't know if this kind of experimentation > is going to help me learn something about filesystems or not. Well what is > dir_index? Then I ran e2fsck -f -v -pD and the /dev file. Now what did I > remove? Htree. I guess it can always be put back and it's on an experimental > filesystem. > > What features separate ext4 from ext3 ? I have noticed too that ext2 > fragments quite a bit. Hello Bill. You're trying to understand what exactly? From the user point of view, dir_index just makes directory accesses on very big directories faster. When creating a new file, or searching a file to be opened, without dir_index the file system driver has to read each any every directory cluster and investigate it's content to figure out, whether an object with the given name already exists. With dir_index, there is an additional form of sorted tree in the directory, which speeds up this lookup process. Now, when you remove that feature and then e2fsck, all those indexes will be removed. If you later readd the feature and e2fsck, those indexes get recreated. >From the developer point of view, one approach is to read and understand the kernel sources for ext2/3/4 or just start writing your own file system checker. If you get that right, you've understood the file system ;) Not much more advice, anyone can give you in a general way. Features that separate ext2 / ext3 / ext4? Clear answer: There is no ext3 and ext4. It's all ext2, but there are three independent code bases in the Linux kernel, called ext2, ext3 and ext4 - but they all implement ext2. The fs driver called ext3 needs the feature has_journal, ext2 can't mount feature needs_recovery. Despite from this, they are pretty much identical. The fs driver called ext4 supports some new features, the prominent (i.e. documented) ones are: extent (don't store cluster pointers but instead cluster ranges - saving space for large files), flex_bg (drop the constraint, that group meta data shall be stored in it's own group, thus allowing to virtually create bigger groups. Probably you can mke2fs one file system with flex_bg, then remove the feature flag and perfecly mount and use it with ext2 / ext3, however, e2fsck may get cracy on that setup - but I don't see, why the file system drivers should get a problem with that - anyways, I didn't test it), uninit_bg (speeds up mke2fs by skipping the "overwrite all bitmaps and inode tables with zeros" step). Regards, Bodo From billcun at suddenlink.net Tue Aug 26 01:14:58 2014 From: billcun at suddenlink.net (Bill Cunningham) Date: Mon, 25 Aug 2014 21:14:58 -0400 Subject: filesystem References: <164EA3526D4E4A98A7590E7E05B73037@a8qn1legfukpv6> <20140826021505.235b3d51@phenom> Message-ID: <2FDF9B43A6424C04A4B1F07D91294305@a0xu9opy2hqxrr> ----- Original Message ----- From: "Bodo Thiesen" To: Sent: Monday, August 25, 2014 8:15 PM Subject: Re: filesystem > Hello Bill. [snip] > You're trying to understand what exactly? From the user point of view, > dir_index just makes directory accesses on very big directories faster. > When creating a new file, or searching a file to be opened, without > dir_index the file system driver has to read each any every directory > cluster and investigate it's content to figure out, whether an object with > the given name already exists. With dir_index, there is an additional form > of sorted tree in the directory, which speeds up this lookup process. Now, > when you remove that feature and then e2fsck, all those indexes will be > removed. If you later readd the feature and e2fsck, those indexes get > recreated. I see. Htree kept bieng mentioned. I am guessing that means "hash tree". I guess I would like to see all these filesystems, if possible, completely backwards reversibile. If you have ext2, simply add a journaling inode. It can be removed too. Now with ext4, removing "extents" might present much more of a difficulty. >>From the developer point of view, one approach is to read and understand > the kernel sources for ext2/3/4 or just start writing your own file system > checker. If you get that right, you've understood the file system ;) > > Not much more advice, anyone can give you in a general way. > > Features that separate ext2 / ext3 / ext4? Clear answer: There is no ext3 > and ext4. It's all ext2, but there are three independent code bases in the > Linux kernel, called ext2, ext3 and ext4 - but they all implement ext2. > > The fs driver called ext3 needs the feature has_journal, ext2 can't mount > feature needs_recovery. Despite from this, they are pretty much identical. > > The fs driver called ext4 supports some new features, the prominent > (i.e. documented) ones are: extent (don't store cluster pointers but > instead cluster ranges - saving space for large files), flex_bg > (drop the constraint, that group meta data shall be stored in it's own > group, thus allowing to virtually create bigger groups. Probably you can > mke2fs one file system with flex_bg, then remove the feature flag and > perfecly mount and use it with ext2 / ext3, however, e2fsck may get cracy > on that setup - but I don't see, why the file system drivers should get a > problem with that - anyways, I didn't test it), uninit_bg (speeds up > mke2fs by skipping the "overwrite all bitmaps and inode tables with > zeros" step). > > Regards, Bodo Yes all those features. I would like to know what they mean. There are mount options, ext4 features, ext3 features and some are directly related to the journaling inode. I seem to remember something called revoke_incompatible or something like that. I've also seen ext3 with no features. Is there any docs or help for learning ext development? One can not remove extents can thy. If I am correct they may cross multiple files. I have alot to learn. I'm glad this list is open to users. I guess anyway. Cheers, Bill From bothie at gmx.de Wed Aug 27 01:20:01 2014 From: bothie at gmx.de (Bodo Thiesen) Date: Wed, 27 Aug 2014 03:20:01 +0200 Subject: filesystem In-Reply-To: <2FDF9B43A6424C04A4B1F07D91294305@a0xu9opy2hqxrr> References: <164EA3526D4E4A98A7590E7E05B73037@a8qn1legfukpv6> <20140826021505.235b3d51@phenom> <2FDF9B43A6424C04A4B1F07D91294305@a0xu9opy2hqxrr> Message-ID: <20140827032001.4608f291@phenom> Hello Bill again. Two things. First. I read this mailing list, so no need to send answers to me personally in copy. Second. I guessed it already, but now it got really obvious, that you didn't do your homework. Please search for your questions in your favorite search engine first. Yes, I know, that there is not much easy to understand information on ext2 (in all flavours) out there, but there is enough to get you startet. Once you get to the details, which you can't get from those online source, feel free to ask again, but I will from now on ignore any question not specific enough for my taste. Ah, and to give you a start, here are some links for you to study before asking ANY more questions here. If you don't understand anything, ask, if you can't figure out anything, ask, but don't ask the easy things, that's really something you should work out for yourself. http://www.nongnu.org/ext2-doc/ext2.html https://en.wikipedia.org/wiki/Ext2 https://en.wikipedia.org/wiki/Ext3 https://en.wikipedia.org/wiki/Ext4 https://oss.oracle.com/projects/ocfs2/dist/documentation/disklayout.pdf (The pdf also contains details about ocfs2 - you can just ignore that.) Regards, Bodo From billcun at suddenlink.net Wed Aug 27 01:49:16 2014 From: billcun at suddenlink.net (Bill Cunningham) Date: Tue, 26 Aug 2014 21:49:16 -0400 Subject: filesystem References: <164EA3526D4E4A98A7590E7E05B73037@a8qn1legfukpv6><20140826021505.235b3d51@phenom><2FDF9B43A6424C04A4B1F07D91294305@a0xu9opy2hqxrr> <20140827032001.4608f291@phenom> Message-ID: <105F6AE742884663BC5E0405DF64B40F@a0xu9opy2hqxrr> ----- Original Message ----- From: "Bodo Thiesen" To: Sent: Tuesday, August 26, 2014 9:20 PM Subject: Re: filesystem > Hello Bill again. > > Two things. > > First. > > I read this mailing list, so no need to send answers to me personally in > copy. > > Second. > > I guessed it already, but now it got really obvious, that you didn't do > your homework. > > Please search for your questions in your favorite search engine first. > Yes, > I know, that there is not much easy to understand information on ext2 (in > all flavours) out there, but there is enough to get you startet. Once you > get to the details, which you can't get from those online source, feel > free > to ask again, but I will from now on ignore any question not specific > enough for my taste. > > Ah, and to give you a start, here are some links for you to study before > asking ANY more questions here. If you don't understand anything, ask, if > you can't figure out anything, ask, but don't ask the easy things, that's > really something you should work out for yourself. > > http://www.nongnu.org/ext2-doc/ext2.html > https://en.wikipedia.org/wiki/Ext2 > https://en.wikipedia.org/wiki/Ext3 > https://en.wikipedia.org/wiki/Ext4 > https://oss.oracle.com/projects/ocfs2/dist/documentation/disklayout.pdf > > (The pdf also contains details about ocfs2 - you can just ignore that.) > > Regards, Bodo Thanks. I hit reply group and your name and the group's email came up. I didn't know which to send a response to. I know now. Thanks again. Bill