On 2016-11-29 00:14, Duncan wrote:
Graham Cobb posted on Mon, 28 Nov 2016 09:49:33 +0000 as excerpted:
On 28/11/16 02:56, Duncan wrote:
It should still be worth turning on autodefrag on an existing somewhat
fragmented filesystem. It just might take some time to defrag files
you do modify, and won't touch those you don't, which in some cases
might make it worth defragging those manually. Or simply create new
filesystems, mount them with autodefrag, and copy everything over so
you're starting fresh, as I do.
Could that "copy" be (a series of) send/receive, so that snapshots and
reflinks are preserved? Does autodefrag work in that case or does the
send/receive somehow override that and end up preserving the original
(fragmented) extent structure?
Very good question that I don't know the answer to as I've not seen it
discussed previously. (I'm not a dev, just a list regular and user of
btrfs myself, and my personal use-case involves neither snapshots nor
send/receive, so on those topics if I've not seen it covered previously
either here or on the wiki, I won't know.)
Someone else know?
Autodefrag does work in that case, but not because there's any special
handling for it. In the case of send/receive, the receiving side is
doing nothing that couldn't be done as a normal user (except possibly a
few ioctls to set subvolume UUID's), so any data it writes will be
subject to all processing done by the FS (so sending from an
uncompressed volume to one with compress=X will result in the data being
compressed on the receiving end too).
--
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
