On 2017-08-31 02:49, Ulli Horlacher wrote:
On Thu 2017-08-24 (18:45), Peter Grandi wrote:
As usual with Btrfs, there are corner cases to avoid: 'defrag'
should be done before 'balance'
Good hint. So far I did it the other way: balance before defrag.
I will switch.
For reference, the reason to do things this way is that defragmenting a
filesystem may result in undoing some of the work balance did.
and with compression switched off
I have filesystems with compress mount option:
framstag@fex:~: grep /local /etc/fstab
LABEL=local /local btrfs defaults,compress,user_subvol_rm_allowed 0 2
and a weekly cronjob, which does a defrag and balance.
I cannot disable compression.
Any hint here?
Having compression enabled causes no issues with defray and balance.
There appears to be a prevalent belief however that defrag is pointless
if you're using compression, probably because some versions of
`filefrag` don't report compressed extents properly (they list each 128k
compressed unit as one extent, which is wrong).
I prefer dump-and-reload.
What do you mean by this?
I believe he means to copy everything off the filesystem, recreate it,
and copy everything back in. That will actually get you much closer to
an optimal layout than a defrag=balance cycle, but it also takes a long
time, requires extra space, and the layout will usually become
sub-optimal almost immediately when you start writing to the filesystem.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
