Re: btrfs resize partition problem

Duncan
Sun, 17 Nov 2013 20:05:34 -0000

Russell Coker posted on Sun, 17 Nov 2013 23:05:04 +1100 as excerpted:

> My home server has / and /home on a SSD and a RAID-1 array of 2*3TB
> disks mounted on /big.  I have had a number of BTRFS related problems
> with that system and BTRFS for / hasn''t made it easier to solve
them.

Once drive sizes got big enough, the way I solved the how-to-fix-root
problem here is by keeping two (or three) identically sized root and root-
bak partitions around.  Periodically, when I''m content that the system
in
general is stable-state and working well[1], I''ll blow away the backup-
root and snapshot-copy the working root over to it again.  (That''s why
I
like having a third copy too, what happens if something goes wrong with
the working copy at just the moment I''ve blown away the backup in
ordered
to redo it?)

And with separate partitions for /home, multi-media, packages/update,
/boot, and /var/log (plus /tmp and /run on tmpfs in memory), the root
partition, containing basically the entire installed operating system
including all apps and their system-level configuration and data plus
installed-package database[2], is /only/ 8 gigs in size, df reporting 25%
used so there''s a nice, comfortable safety margin.  That means I keep
(at
least) three 8-gig root partitions in various places, working-root,
primary and secondary backup-root.

In addition to functioning as full root backups, each of the three is
independently bootable by simply changing the root= parameter fed to the
kernel at boot time, and in fact, my grub2 menu is setup so I can choose
any of the three direct from it, without even having to drop to the grub
commandline.  As a result, if root needs a proper fsck or if an after-all
~arch/testing profile update broke something critical and I can''t boot
the working root, I simply choose the primary or secondary backup root,
and have a full working system (manpages/documentation, X-desktop and
browser, even media players!) exactly the same as it was when I took that
backup.

My actual drive setup is currently two SSDs where I run btrfs partitions
mostly in raid1 mode, and a larger legacy spinning-rust drive with the
media partition (and its primary backup) and additional non-btrfs backups
of the main system, plus another (external) spinning-rust drive with
further backups.  Since btrfs is still experimental, for the purposes of
backup policy I worst-case btrfs as totally lost and keep backups as if I
didn''t have the SSDs and btrfs at all.  (Which means in all I actually
have something like working copy plus six levels of backup for root, the
working copy and primary backup on btrfs on the ssds that I don''t count
because btrfs is experimental, the fallback working copy and two backups
on the internal spinning rust reiserfs should the experimental label of
btrfs live up to its name, and the two external drive last-resort
backups, tho they''re actually rather outdated ATM, but I could fallback
to them if I had to.)

---
[1] Stable state, working well:  I''m on gentoo, a rolling-release
distro,
running ~arch aka testing, not stable, and in fact I''m often running
live-
git pre-release versions of this or that as well, so sometimes I do /not/
consider the system in a stable state!

[2] Installed-package database:  Remember, gentoo''s rolling-release, so
keeping track of what''s actually installed is important.  One disaster-
recovery experience some years ago taught me the importance of that when
I had the installed-package database on a partition separate from root
with all the actual installed-packages it was tracking, and I ended up
restoring from backups where the installed-package database was from a
different date and thus out of sync with what was /actually/ installed!
*NEVER* *AGAIN*!  They''re on the same filesystem now, so they stay in
sync and restore together!

--
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman