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 partition gets remounted as read only
Date: Mon, 21 Sep 2015 15:02:23 +0000 (UTC)	[thread overview]
Message-ID: <pan$28fb6$e21baff8$67f806d3$ecee1b58@cox.net> (raw)
In-Reply-To: CAOTVeoEVxAMHJ8Rw-YfAUmuvNUs3pAcEGgA7bXgOC1fToW9HYQ@mail.gmail.com

Incorporeal Waffle posted on Mon, 21 Sep 2015 14:30:21 +0000 as excerpted:

> I tried converting my root partition (originally ext4) to btrfs.

There's some known bugs with btrfs-convert currently, with current or 
very recent discussion on-list about how to fix it, if you check the 
archives.

In the more general case, while the present bugs will no doubt be fixed, 
I (a user, not a dev) don't recommend using convert, as in the best case, 
it's a compromise, with better results if you treat the existing ext* as 
a backup and start with a brand new btrfs using mkfs.btrfs.

The admin's rule of backups states that if you care about the data, it's 
backed up, and if it's not backed up, in practice, you're defining the 
data as not worth the time and resources to back up, any claims to the 
contrary not withstanding.  (Meanwhile, a would-be backup that hasn't 
been tested restorable isn't considered a backup, because the backup 
isn't defined as complete until it is tested.)

>From that perspective, there's little reason to do a filesystem 
conversion, since if you care about the data, it's backed up and can be 
restored to a brand new filesystem, with a better layout than a 
filesystem that started as something else is likely to ever achieve, and 
if you don't care about the data, then there's no reason not to start out 
with a clean filesystem in the first place.

So while having a convert tool is "nice", even when it's working 
correctly, the best choice is to avoid using it, starting with brand new 
clean filesystem and copying existing data, if any, into it from backups 
so it is laid out ideally for the new filesystem, instead of the 
compromise of trying to work around the location of existing data and 
metadata, in a layout that should work, granted (and it's definitely a 
bug that it's not doing so today), but is unlikely to be ideal for a 
different filesystem than the one it started out as.

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


  parent reply	other threads:[~2015-09-21 15:02 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-21 14:30 Btrfs partition gets remounted as read only Incorporeal Waffle
2015-09-21 14:36 ` Marc MERLIN
2015-09-21 15:02 ` Duncan [this message]
2015-09-21 15:05   ` Hugo Mills

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$28fb6$e21baff8$67f806d3$ecee1b58@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).