Suggestions for Dual - Boot Hard Drive Partitioning

[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.

[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]

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

[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]

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.

[oshunluvr]

Back to openSUSE, I think they use XFS for home for performance reasons. /var is NOCOW because databases are stored there, but why /root /opt and /usr/local in separate subvols? In the old days of little hard drives, you might mount /opt and /usr/local on a different filesystem to add space to your install, but why now? Separating root makes no sense at and I don't know what /srv would hold. Same for /boot - why move that unless you were using LVM or full encryption?

[oshunluvr]

I'm sure someone has reasons for them all.

For me, mysql puts its default tablespace in /var, and that's a nuisance; I'd really like to roll back a dodgy update without rolling back mysql. And not backing up /tmp with the rest of @ would be a win.

I agree some custom setups have advantages but the openSUSE scheme isn't a one-size-fits-all so why are they doing it?

For my server, I have /var/www and /var/lib/plexmediaserver in subvolumes just for the reason you describe. Also, I'm transition from 14.04 to 18.04 so I can boot to either and my Nextcloud and Apache2 files (var/www) and my Plex Media Library (/var/lib/plexmediaserver) work and look the same in either install.

If your mysql is in /var/<SOMETHING> moving it to a subvolume and mounting is is cake. I usually put /tmp in RAM but you could easily move it too. I would make sense to pull out whatever didn't need to be in a full backup and put them in their own subvolumes, but it makes initial setup somewhat more work. In m setup, I have to remember to backup those two additional subvolumes but I automate backups so no big deal.

[jlapinsk4]

I don't know. I installed Neon LTS User Edition from an ISO and use the repositories that it connects to. I've never attempted to install Neon from a PPA and I don't (didn't) know if such a PPA exists (existed).

Thank you! I just "won" a used laptop on Ebay that I intend to use as a back up system. Once I get it up and running I plan to migrate to Plasma Neon.

[jlapinsk4]

I ran into some strange installation issues when I install Suse or Gecko myself. I have been able to get the system to boot each time (but I have not tried to dual boot). I ran into some issues with Manjaro as well but I think they may have been related to the way I made the live USB drive. I do want to take a look at Manjaro, hear great things about it.

[GreyGeek]

Suggestions for Dual - Boot Hard Drive Partitioning

I’m sure SUSE devs have a basic use case in mind for using two filesystems, and putting all of /home on XFS, but having xfsdump copying /Home one file at a time, regardless of how fast it is, can’t match the speed of COW in Btrfs. Using xfs_copy requires shutting the system down or using xfs_freeze. I researched its xfsdump speed and found almost no info, which was surprising. One report talked about taking 5,700 seconds to back up 273 Gb, reading between the lines.

As far as your requirements are concerned:

Mount /dev/disk/by-uuid/xxxxxxxxxx /mnt

btrfs subvol create /mnt/@tmp

Edit fstab to bind @tmp to /tmp

Umount /mnt

Reboot

Since /tmp is now a subvolume its contents will not be included in a snapshot of @, just the way @home’s contents are not included in a snapshot of @. When making “backups” of your system @tmp can be ignored. IF, of course, /tmp’s contents are deleted on a regular basis and some app hasn’t taken to use it for data retention.

Do the exact same thing for /var, which can then be snapshotted without necessarily snapshotting @ or @home.

After creating @var and before unmounting /mnt copy the contents of /var to @var.
mv/mnt/@/var/* /mnt/@var
This action will, no doubt, require the DB engine be shutdown.

And, like VirtualBox’s virtual drives, @var has to be created as a “nocow” subvolume for the same reasons.

There is no problem with creating a snapshot of a subvolume mounted with nodatacow. But since cow is required to create a snapshot, when you create one on a subvolume with nodatacow it will essentially ignore nodatacow; acting as it normally would. Nocow still remains on the subvolume after snapshotting. So, while snapshotting, MySQL can remain in operation. Its snapshot disk space usage will probably expand rapidly to match the subvolume, but I’m just guessing.

Btrfs send & receive of @var to archival storage (local a/o off-site) can then be done in the background while the server continues to serve.

Win-win.

And the only FS involved is Btrfs.

[jlittle]

I'm sure someone has reasons for them all.

For me, mysql puts its default tablespace in /var, and that's a nuisance; I'd really like to roll back a dodgy update without rolling back mysql. And not backing up /tmp with the rest of @ would be a win.

[GreyGeek]

For a reference, here is what OpenSUSE Leap 15 offered me for subvolumes on installation.



Notice what it wants to do with /home!!! Assign 652Gb out of 698Gb as XFS.

OpenSUSE Leap 15 isn't really a Btrfs installation, it is mostly an XFS installation. Combined, it makes a hybrid monster. One would have to follow two backup & restore paradigms to maintain it.

Wow. They have jumped off the deep end. It is a distro I will never return to. And I thought all modern distros were pretty much equal except for KDE. Was I ever wrong. I take back all I said about "you can't go wrong using OpenSUSE".

[oshunluvr]

Well, I did a fresh install of K18.04 and it did not reset the default subvolume so it must be an openSUSE only thing. Also, with the default subvol set at 5 like it's supposed to be, the root volume mounts easily as it has before.

Again, I can't understand why they do all of this purposeful obfuscation? Why make 13 subvolumes only to practically hide them by changing the default subvolume? What a piece of crap.

[oshunluvr]

Add to that the really poor way the installer sets up fstab if you don't use the "Guided" or default installation and it's a no-go for me. Too much work just to get it usable for no reason. It didn't even use the swap at installation unless you manually entered it.

If you want an alternative to Kubuntu to boot to once in a while, try Manjaro. It's totally different from Debian based systems but installed easily and runs quickly. Worth a look...

[oshunluvr]

With it set to 5 I can boot Kubuntu OK but not openSUSE. It's grub menu depends on the default subvolume apparently. Definitely a bug.