On 12/13/2014 05:53 AM, Tomasz Chmielewski wrote:
My usage case is quite simple:
- skinny extents, extended inode refs
okay
- mount compress-force=zlib
I'd, personally, "never" force compression. This can increase the size
of files by five or more percent if it is an inherently incompressible
file. While it is easy to deliberately create a file that will trick the
compress check logic into not compressing something that would enjoy
compression it does _not_ happen by chance very often at all.
- rsync many remote data sources (-a -H --inplace --partial) + snapshot
Using --inplace on a Copy On Write filesystem has only one effect, it
increases fragmentation... a lot... Every new block is going to get
written to a new area anyway, so if you have enough slack space to keep
the one new copy of the new file, which you will probably use up anyway
in the COW event, laying in the fresh copy in a likely more contiguous
way will tend to make things cleaner over time.
--inplace is doubly useless with compression as compression is perturbed
by default if one byte changes in the original file.
The only time --inplace might be helpful is if the file is NOCOW...
except...
- around 500 snapshots in total, from 20 or so subvolumes
That's a lot of snapshots and subvolumes. Not an impossibly high number,
but a lot. That needs it's own use-case evaluation. But regardless...
Even if you set the NOCOW option on a file to make the --inplace rsync
work, if that file is snapshotted (snapshot?) between the rsync
modification events it will be in 1COW mode because of the snapshot
anyway and you are back to the default anti-optimal conditions.
Especially rsync's --inplace option combined with many snapshots and
large fragmentation was deadly for btrfs - I was seeing system freezes
right when rsyncing a highly fragmented, large file.
You are kind of doing all that to yourself. Combining _forced_
compression with denying the natural opportunity for the re-write of the
file to move it to nicely contiguous "new locations" and then pinning it
all in place with multiple snapshots you've created the worst of all
possible worlds.
The more you use optional gross-behavior options on some sorts of things
the more you are fighting the "natural organization" of the system. That
is, every system is designed around a set of core assumptions and
behavioral options tend to invalidate the mainline assumptions. Some
options, like "recursive" are naturally part of those assumptions and
play into them, other options, particularly things with "force" in the
name tend to be "if you really think you must, sure, I'll do what you
say, but if it turns out bad it's on _your_ head" options. Which options
are which is a judgment call, but the combination you've chosen is
definitely working in that bad area.
And keep repeating this to yourself :: "balance does not reorganize
anything, it just moves the existing disorder to a new location". This
is not a perfect summation, and it's clearly wrong if you are using
"convert", but it's the correct way to view what's happening while
asking yourself "should I balance?".
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
