On 2015-12-09 05:53, Duncan wrote: > Christoph Anton Mitterer posted on Wed, 09 Dec 2015 05:36:37 +0100 as > excerpted: > >> On Fri, 2015-11-27 at 01:02 +0000, Duncan wrote: >> [snip snap] >>> #2 The point I was trying to make, now, to mount it you'll mount not a >>> native nested subvol, and not a directly available sibling >>> 5/subvols/home, but you'll actually be reaching into an entirely >>> different nesting structure to grab something down inside, mounting >>> 5/subvols/root/home subvolume nesting down inside the direct >>> 5/subvols/root sibling subvol. >> >> Okay so your main point was basically "keeping things administrable"... > > =:^) > >>> one of which was that everything that the package manager installs >>> should be on the same partition with the installed-package database, so >>> if it has to be restored from backup, at least if it's all old, at >>> least it's all equally old, and the package database actually matches >>> what's on the system because it's in the same backup! > >> I basically agree, though I'd allow few exceptions, like database-like >> data that is stored in /var/ sometimes and that doesn't need to be >> consistent with anything but iself... e.g. static web pages >> (/var/www)... postgresl DB, or sks keyserver DB... and so on. > > Of course. But such data isn't usually managed by the package manager, > so splitting off a partition or subvolume or whatever, is fair game. > > IOW, /var can and should still be on /, but /var/www and the like can be > on some other subvolume or filesystem. > Agreed. It's not too bad fixing a Gentoo system (as long as /var/lib/portage/world is still correct, you can just nuke the installed package database and emerge world, it'll take time, but it will get your system in a guaranteed consistent state). On something using dpkg or rpm though, it's got the potential to be almost impossible to recover from without a significant amount of low-level knowledge of the package manager's installation database.
smime.p7s
Description: S/MIME Cryptographic Signature