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.