Two more on these: On Thu, 2015-11-26 at 00:33 +0000, Hugo Mills wrote: > 3) When I would actually disable datacow for e.g. a subvolume that > > holds VMs or DBs... what are all the implications? > > Obviously no checksumming, but what happens if I snapshot such a > > subvolume or if I send/receive it? > After snapshotting, modifications are CoWed precisely once, and > then it reverts to nodatacow again. This means that making a snapshot > of a nodatacow object will cause it to fragment as writes are made to > it. AFAIU, the one the get's fragmented then is the snapshot, right, and the "original" will stay in place where it was? (Which is of course good, because one probably marked it nodatacow, to avoid that fragmentation problem on internal writes).
I'd assume the same happens when I do a reflink cp. Can one make a copy, where one still has atomicity (which I guess implies CoW) but where the destination file isn't heavily fragmented afterwards,... i.e. there's some pre-allocation, and then cp really does copy each block (just everything's at the state of time where I stared cp, not including any other internal changes made on the source in between). And one more: You both said, auto-defrag is generally recommended. Does that also apply for SSDs (where we want to avoid unnecessary writes)? It does seem to get enabled, when SSD mode is detected. What would it actually do on an SSD? Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature
