BTW: I am reducing it to 2% since.. long long time. I haven't seen an issue arising from this at all. regards Peter On Mon, Aug 24, 2015 at 10:17 AM, Trent W. Buck <trentbuck@gmail.com> wrote:
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.
_______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main