Re: [Not TLS] Re: mount option nodatacow for VMs on SSD?

["Austin S. Hemmelgarn" <ahferroin7@gmail.com>]

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).