linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: btrfs resize partition problem
Date: Sun, 17 Nov 2013 20:05:34 +0000 (UTC)	[thread overview]
Message-ID: <pan$cc148$5523c730$89b04fcf$f580ae04@cox.net> (raw)
In-Reply-To: 201311172305.04091.russell@coker.com.au

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


      reply	other threads:[~2013-11-17 20:05 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-16 20:37 btrfs resize partition problem Dejan Ribič
2013-11-16 22:19 ` Duncan
2013-11-17 12:05   ` Russell Coker
2013-11-17 20:05     ` Duncan [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='pan$cc148$5523c730$89b04fcf$f580ae04@cox.net' \
    --to=1i5t5.duncan@cox.net \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).