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 <block not found> > 98305 <block not found> 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 _______________________________________________ Ext3-users mailing list Ext3-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ext3-users