On Mon, Jun 3, 2019 at 10:36 AM I wrote:
> I just noticed the reported journal size is exactly 1G, which would
> account for the difference:
> Journal size: 1024M
> That's assuming the units are bytes; if they are blocks, it's just a
> crazy value.
> I'll see what the extN experts have to say.
Ted Ts'o over on https://www.spinics.net/lists/linux-ext4/index.html (sorry, reply isn't in index yet) confirms that the big log is the
cause of the 3G vs 4G discrepancy, and the big log is a holdover from
the original 4TB size I specified. There are some additional
suboptimalities from shrinking by a factor of 1000, but the log size
is the only substantial one. To reset the journal size he recommended
removing and then recreating the journal, which worked for me. df now
reports 4G as the volume size, with a corresponding increase in the
free data space.
root@barley:~#tune2fs -O ^has_journal /dev/vgbarley/cache # remove journal
tune2fs 1.44.5 (15-Dec-2018)
root@barley:~#date; tune2fs -O has_journal /dev/vgbarley/cache # turn
it back on
Mon 03 Jun 2019 08:27:37 PM PDT tune2fs 1.44.5 (15-Dec-2018) Creating
journal inode: done
root@barley:~#date; dumpe2fs -h /dev/vgbarley/cache
Inode count: 131072
Block count: 1048576
Reserved block count: 52428
Free blocks: 538855 # was 621488 before, but there's a
lot more on it
Free inodes: 118435
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 24162063-f4a6-4420-b79b-3ad4f9b71ab7
Journal backup: inode blocks
Checksum type: crc32c
Journal features: (none)
Journal size: 64M ### <<<<<<<< was 1G
Journal length: 16384
Journal sequence: 0x00000001
Journal start: 0
root@barley:~## journal size now 64M instead of 1G!
root@barley:~#date; mount /var/local/cache/
Mon 03 Jun 2019 08:28:59 PM PDT
root@barley:~#df -h !$
df -h /var/local/cache/
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vgbarley-cache 4.0G 1.9G 1.9G 51% /var/local/cache
# only 0.7G in use in my original post; now 1.9G.
# the +1.2G is from real files, not overhead
Thanks to everyone for your help.
* Don't say 4TB when you mean 4GB! (Duh)
* e2fs tools report (roughly?) the entire device size for block count,
while df only shows the size of the data area, excluding metadata
* Mis-sized journals can be fixed by removal and recreation, at least for ext4.
On Mon, Jun 03, 2019 at 09:06:11PM -0700, Ross Boylan wrote:
> * Don't say 4TB when you mean 4GB! (Duh)
> * e2fs tools report (roughly?) the entire device size for block count,
> while df only shows the size of the data area, excluding metadata
> * Mis-sized journals can be fixed by removal and recreation, at least for ext4.
Very nice. I am pleased that this was resolved and I have definitely
learned a few new things by following this thread.