[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: What uses these 50 GB?



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]