Suggestions for Dual - Boot Hard Drive Partitioning

[GreyGeek]

BTW, unless this has changed recently, you can't make a whole subvolume NOCOW without making the entire file system NOCOW. You can set directories as NOCOW using CHATTR +C, but not a mounted subvolume.

So if for example you wanted to do this to /var/lib/mysql, you could make a subvol for /var/lib and then a directory for mysql and set mysql as NOCOW.

I'm aware that the docs always refer to normal directories and files while talking about nocow. However, notice in the image that I posted above that Leap 15 creates the @var subvolume (subdirectories and files don't exist yet) with "no copy on write" turned on, but all the other subvolumes have the default COW. The mount option allows nodatacow "for files", but everything in Linux is a file.

https://btrfs.wiki.kernel.org/index....data_blocks.3F

Can I mount subvolumes with different mount options?

The generic mount options can be different for each subvolume, see the list below. Btrfs-specific mount options cannot be specified per-subvolume, but this will be possible in the future (a work in progress).
Generic mount options:

• nodev, nosuid, ro, rw, and probably more. See section FILESYSTEM INDEPENDENT MOUNT OPTIONS of man page mount(8).

Yes for btrfs-specific options:

• subvol or subvolid

Planned:

• compress/compress-force, autodefrag, inode_cache, ...

No:

• the options affecting the whole filesystem like space_cache, discard, ssd, ...

From the kernel mailing list:

... the data integrity (and compression) features are
turned off when something is set NOCOW, whether that "something" is an
individual file or the whole subvolume (mounted with nodatacow).

However, that's not as bad a situation as one might initially think.
Many of the applications that do routine internal-file-writes already
have at least basic data integrity management of their own, as they've
been more or less forced to in ordered to have any stability at all since
filesystems traditionally do not have data integrity management of their
own. This being the case, they're already somewhat prepared to detect
and do limited recovery from file corruption, perhaps losing the last
couple transactions but preserving the data as a whole.

However, caveats exist. This info is four years old. I suspect that things have only improved.

Regardless, NOCOW and not doing snapshotting (because it triggers COW anyway) on gig-plus internal-write files remains a very good idea.

As I understand it, then,
https://wiki.archlinux.org/index.php...ing_subvolumes

Note: From Btrfs Wiki Mount options: within a single file system, it is not possible to mount some subvolumes with nodatacow and others with datacow. The mount option of the first mounted subvolume applies to any other subvolumes.

If I create subvolume A and under it create subvolume B then B adopts the properties of A. IF A is nodatacow then so will be.

But, that page has been depreciated and this page applies:
https://btrfs.wiki.kernel.org/index....#MOUNT_OPTIONS
but it talks only about files and directories.

Of, if push comes to shove, I can create a lone subvolume, /var, on a drive different from my boot drive (not my system btrfs) and mount it as /var with nodatacow in /etc/fstab. But then, can I snapshot it? Yes? No? I think yes, but I'd have to try it.

[oshunluvr]

Look like SUSE worked this one out: https://github.com/SUSE/kiwi/issues/218

[GreyGeek]

Look like SUSE worked this one out: https://github.com/SUSE/kiwi/issues/218

Appears so.

Since nodatacow removes both COW and datasumming I'm assuming that a snapshot of @var containing /ib/mysql, for example, would turn off nodatacow, make the snapshot, and turn it back on. Then the snapshot would begin filling fast as the database engine proceeded to write to the various blocks within /lib/mysql as transactions were performed.

I have no experience with MySQL but with PostgreSQL the thing to do would be to have users exit their PostgreSQL clients, and with everyone out the admin would perform a backup using pg_dump, or a restore using pg_restore. This, of course, would be outside the purview of Btrfs, in addition to making @ and @home snapshots. But, creating @var would allow backing up @var alone or @ and @home without having to back up @var at the same time.

[oshunluvr]

Yes, AFAIK snapshots automatically force COW.

I use PostgreSQL lightly here and at work (but at work not on a btrfs fs), but I think the primary issue with COW and databases is micro-writes are more easily corrupted. We're probably talking four or five decimal places to the right of 0, but still an increased chance. If you're a heavy user, you'd likely be doing something else file system-wise anyway.

If you're a light user, the likelihood of corruption is probably tolerable when you consider the ease of making backups and dual-distro use of a database like in my case. I mostly have a fairly large but relatively stable media database (meta-data not the actual media files). A corruption might mean what? I would have to re-set up the media info (cover, screenshot, title, etc.). Not really a life-or-death situation.