David Zuccaro <david.zuccaro@optusnet.com.au> writes:
On 21/08/15 12:24, Trent W. Buck wrote:
By default mke2fs reserved 5% of the filesystem for uid 0. This is also used as a staging area to reduce fragmentation.
df does not include this area in the "free" size, so if you fill a disk *as root*, you must remove >5% for df to show any change.
30G is about 2% of 1.4T, so that's not enough.
You can remove this reserved area using tune2fs, but that is a bad idea.
Thanks Trent, that would explain the anomaly. I did not know that that the 5% reserved area was accessible to root (I was running the back up as root). Would it be ok to reduce the reserved area to say 1%?
It won't hurt. Without reserved space, you will get more fragmentation (if you repeatedly fill the filesystem). BUT you're running the backup as root, so it effectively ignores that reserved space ANYWAY. e2fsck -f reports fragmentation as a percentage, but I'm not sure how believable that number is. * * * You could just put up with it. IME fragmentation isn't a big deal on ext. You could change the reserved user ID from 0 (using tune2fs), so the root-owned rsync can't use the reserved space. You could run a defrag program occasionally. This mostly consists of writing a new copy of each file, along these lines (untested, pre-coffee): nice ionice -c3 find -O3 /srv/backup -xdev -type f -links 1 -size +1M \ -exec cp -v {} {}~ \; \ -exec mv -v {}~ {} \; ...but it is easy to break unusual files (e.g. hard-linked, sparse) without realizing until it's too late. Last time I looked, all of the ext defrag programs were written by recent Windows refugees and I didn't trust them to get edge cases right any better than the above.