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
next prev 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).