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: missing /sbin/fsck.btrfs
Date: Wed, 27 Nov 2013 06:14:30 +0000 (UTC)	[thread overview]
Message-ID: <pan$22672$ac84637f$865cf9fc$7ac893ec@cox.net> (raw)
In-Reply-To: 2D538DF7-452A-420F-9826-C2059564C0A5@colorremedies.com

Chris Murphy posted on Tue, 26 Nov 2013 21:55:09 -0700 as excerpted:

> If I change the bootloader kernel paramter line from ro to rw, and
> simply wipe out the roofs entry from fstab, I still have a bootable
> system. Is there a good reason why rootfs on btrfs should initially
> mount ro? It seems the legacy reason for this is so rootfs is available,
> yet can still have fsck run on it, after which it's remounted rw. None
> of that applies to btrfs does it?

I did that for awhile with reiserfs.  Pass rw on the kernel commandline 
and skip the whole fsck and remount read-write.

But then I realized it was getting mounted rw, but the other mount 
options weren't getting set, because they weren't passed on the kernel 
commandline (that was before I knew about rootflags= and likely before it 
was documented in kernel-parameters.txt, tho it possibly existed), so I 
went back to ro mounting so I could get noatime, etc, with the remount.

Now of course one could pass rootflags= on the kernel commandline too, 
and make rw just another part of that, particularly since btrfs has a 
whole lot of other mount options one might like to pass 
(autodefrag,compress=lzo,noatime...).  Further, at least for those 
building their own kernel the builtin kernel commandline could be used, 
thus avoiding the hassle of having to actually pass all that stuff in 
from the bootloader.

But meanwhile, I've recently become a ro-rootfs-by-default convert.  I 
now routinely run a read-only root, unless I'm actively updating or 
reconfiguring something and need a read-write root for that.  But it ro 
as booted, remounted rw only for changes, then mounted ro once again.

That's actually a far more stable and safe way to run, particularly since 
I'm running a still not entirely stable btrfs rootfs, since as long as 
it's mounted ro, a system crash is extremely unlikely to cause any damage 
at all.  It's worth noting that traditionally, rootfs was never fully 
unmounted for shutdown anyway, only mounted ro, since it normally 
couldn't be unmounted because executable files were still open for 
reading/execution.  (I understand that systemd, when run from an 
initramfs, can now fully unmount real-root, leaving only the in-memory 
initramfs mounted, but that's not the way things traditionally worked.)

Which is nice, since it means the entire operating system, or at least 
all of it that's on rootfs, is available to help recover other 
filesystems that /were/ mounted read-write at the time of a crash, and 
/did/ have open files...  Having the full system including manpages, a 
browser, etc, available for recovery is a whole lot nicer than trying to 
recover rootfs with the normally extremely limited tools and 
documentation available in the initramfs, for sure!

-- 
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-27  6:14 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-26  6:40 missing /sbin/fsck.btrfs Chris Murphy
2013-11-26  7:18 ` Duncan
2013-11-26  7:53   ` dima
2013-11-26 18:43   ` Chris Murphy
2013-11-26 22:36     ` Duncan
2013-11-27  4:55   ` Chris Murphy
2013-11-27  6:14     ` Duncan [this message]
2013-11-27  0:51 ` Dave Chinner
2013-11-27  3:06   ` Chris Murphy
2013-12-01 23:01     ` Dave Chinner
2013-12-30 17:18       ` Tom Gundersen
2014-01-06 14:55         ` Karel Zak
2013-11-27 11:19   ` Tom Gundersen

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$22672$ac84637f$865cf9fc$7ac893ec@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).