From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Got 10 csum errors according to dmesg but 0 errors according to dev stats
Date: Sat, 23 May 2015 16:52:19 +0000 (UTC) [thread overview]
Message-ID: <pan$9da5d$8559e11b$1dc0dccb$67ad3c9d@cox.net> (raw)
In-Reply-To: 1432385390.4187.15.camel@googlemail.com
Philip Seeger posted on Sat, 23 May 2015 14:49:50 +0200 as excerpted:
> Is this a known side effect, that files could get corrupted if no
> balance is run (not counting the balance with 4.0 which doesn't work due
> to that commit) after an ext4 conversion?
I'm not sure.
What I am sure of is that I'd not trust a btrfs converted from ext* until
the saved subvol is deleted, and a defrag and balance run. Even then,
I'd personally be more comfortable with a fresh mkfs.btrfs, and copy over
from backup, tho I know reality is that btrfs /needs/ a working
conversion program or it'll never take off as the default successor to
the ext* crown, as it wants to be. I simply don't trust that conversion,
as I've seen too many people have problems with their btrfs after doing
the conversion from ext*.
Balance-conversions between raid modes of btrfs are a little different,
and somewhat more trustworthy... to me, anyway.
To be fair, it might well be a personal bias of mine against ext* in the
first place, as I never really was comfortable with it for various
reasons. Among others, I think enough kernel devs see ext* as simple
enough to meddle with that it gets more changes than it really should
have, ext3's period with data=writeback as the default being a primary
example. Reiserfs, my personal favorite, and xfs, and now btrfs, all
seem to be different enough that the hacking is left to the folks that
really know the filesystem, with others leaving it to the experts as
they're afraid to touch it, at least more so than ext*. Anyway, it's
quite possible I have enough of a bias there that it taints anything
converted from it more than it should as well. Either way, I personally
just don't trust ext* conversions, and would rather see people do
mkfs.btrfs and copy over from backup, as I think the filesystem is
cleanly native btrfs that way, and has less problems as a result.
But you really need a second opinion before trusting /that/, because as I
said, it might simply be my personal bias talking.
--
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-05-23 16:52 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-10 14:37 Got 10 csum errors according to dmesg but 0 errors according to dev stats Philip Seeger
2015-05-10 14:58 ` Philip Seeger
[not found] ` <CABR0jERqzkdTJxX_1S5WEZHDzX8=O8P7r+Bk0mesPLsR2n=w8A@mail.gmail.com>
2015-05-10 17:32 ` Philip Seeger
2015-05-11 1:41 ` Russell Coker
2015-05-12 0:14 ` Philip Seeger
2015-05-12 1:04 ` Paul Jones
2015-05-12 1:37 ` Chris Murphy
2015-05-15 18:40 ` Philip Seeger
2015-05-15 18:33 ` Philip Seeger
2015-05-17 1:53 ` Philip Seeger
2015-05-17 8:19 ` Duncan
2015-05-17 8:36 ` Omar Sandoval
2015-05-17 8:57 ` Duncan
2015-05-23 12:49 ` Philip Seeger
2015-05-23 16:52 ` Duncan [this message]
2015-05-27 20:25 ` Philip Seeger
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$9da5d$8559e11b$1dc0dccb$67ad3c9d@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).