On Mon, Feb 23, 2015 at 11:47:16AM +0100, Didier Kryn wrote: > As far as I understand, COW means that the whole file is > rewritten everytime you change a single byte in it (or is it only > some "extent"?). That's a real mess when you are continuously > appending to files hundreds of megabytes large, which is the job of > a log server.
No, only a single block. This is sometimes unwanted as it causes fragmentation -- your nice contiguous extents will split into small page/leaf-sized blocks all around, but NOCOW is still a terrible idea. It breaks pretty much all reasons one might want btrfs over an old-style filesystem (other than compression and checksums). NOCOW breaks the semantics behind reflinks and snapshots, which mean you can't use them for cloning stuff, backups, etc, anymore. Thus, every single program that uses NOCOW without an explicit request from the admin is broken and shouldn't be used anywhere near btrfs. > If you happen to loose the log files, you don't loose precious data. If you have two clones, writing to one will overwrite the other. If you try to roll back to an old snapshot, whether for forensic or data recovery reasons, the log is lost. > Nevertheless I would rather use a different filesystem for /var for > example and keep btrfs for /usr and /home. Having all dpkg-managed files (ie, / except /home, /srv, perhaps /var/cache and friends if you micromanage) on a single btrfs subvolume is required for proper atomic snapshots. -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
