Am Tue, 7 Feb 2017 15:27:34 -0500 schrieb "Austin S. Hemmelgarn" <ahferro...@gmail.com>:
> >> I'm not sure about this one. I would assume based on the fact that > >> many other things don't work with nodatacow and that regular defrag > >> doesn't work on files which are currently mapped as executable code > >> that it does not, but I could be completely wrong about this too. > > > > Technically, there's nothing that prevents autodefrag to work for > > nodatacow files. The question is: is it really necessary? Standard > > file systems also have no autodefrag, it's not an issue there > > because they are essentially nodatacow. Simply defrag the database > > file once and you're done. Transactional MySQL uses huge data > > files, probably preallocated. It should simply work with > > nodatacow. > The thing is, I don't have enough knowledge of how defrag is > implemented in BTRFS to say for certain that ti doesn't use COW > semantics somewhere (and I would actually expect it to do so, since > that in theory makes many things _much_ easier to handle), and if it > uses COW somewhere, then it by definition doesn't work on NOCOW files. A dev would be needed on this. But from a non-dev point of view, the defrag operation itself is CoW: Blocks are rewritten to another location in contiguous order. Only metadata CoW should be needed for this operation. It should be nothing else than writing to a nodatacow snapshot... Just that the snapshot is more or less implicit and temporary. Hmm? *curious* -- Regards, Kai Replies to list-only preferred. -- 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
