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


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