# e2fsck -v -f /dev/vgbarley/cache
e2fsck 1.44.5 (15-Dec-2018)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
8410 inodes used (6.42%, out of 131072)
47 non-contiguous files (0.6%)
1 non-contiguous directory (0.0%)
# of inodes with ind/dind/tind blocks: 0/0/0
Extent depth histogram: 5628/2
469120 blocks used (44.74%, out of 1048576)
0 bad blocks
1 large file
2684 regular files
1583 directories
0 character device files
0 block device files
0 fifos
0 links
4134 symbolic links (2772 fast symbolic links)
0 sockets
------------
8401 files
I don't see any errors, and it still reports 1M blocks @4k/block -> 4G
Although the blocks in use are very high, 469k -> 1.6G (48%)
In contrast, df reports 770M/3G in use (28%). So if there's 1G that
is somehow hidden from that total, adding it to both sides gives
roughly
1.8G/4G which is close to the 1.6G reported in use above.
du -sh says 745M is in use.
Reserved blocks reported by dumpe2fs is only 5% of the block count, so
they can't account for the difference.
e2fs also reports 621488 free blocks, roughly 2.4GB. That is roughly
consistent with free space reported by df, even though their total
space counts disagree.
Maybe the data management structures, which were originally
appropriate for a filesystem 1000x larger than the one I have now, are
somehow chewing up blocks in some way not directly reported? But it
seems quite a coincidence that the reported drive size by df matches
the earlier shrunken size of 3G so well.
Ross
