From: Adrian Bastholm <adrian@javaguru.org>
To: quwenruo.btrfs@gmx.com, linux-btrfs@vger.kernel.org
Subject: Re: btrfs problems
Date: Thu, 20 Sep 2018 19:23:35 +0200 [thread overview]
Message-ID: <CAMrg+aQV97Cv4WgH-DQvwDikFydrxD-zeJajUk3iLk1oKf12_A@mail.gmail.com> (raw)
In-Reply-To: <405d08b1-9f22-1038-67c3-c055477029d4@gmx.com>
On Mon, Sep 17, 2018 at 2:44 PM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>
> Then I strongly recommend to use the latest upstream kernel and progs
> for btrfs. (thus using Debian Testing)
>
> And if anything went wrong, please report asap to the mail list.
>
> Especially for fs corruption, that's the ghost I'm always chasing for.
> So if any corruption happens again (although I hope it won't happen), I
> may have a chance to catch it.
You got it
> >
> >> Anyway, enjoy your stable fs even it's not btrfs
> > My new stable fs is too rigid. Can't grow it, can't shrink it, can't
> > remove vdevs from it , so I'm planning a comeback to BTRFS. I guess
> > after the dust settled I realize I like the flexibility of BTRFS.
> >
I'm back to btrfs.
> From the code aspect, the biggest difference is the chunk layout.
> Due to the ext* block group usage, each block group header (except some
> sparse bg) is always used, thus btrfs can't use them.
>
> This leads to highly fragmented chunk layout.
The only thing I really understood is "highly fragmented" == not good
. I might need to google these "chunk" thingies
> We doesn't have error report about such layout yet, but if you want
> everything to be as stable as possible, I still recommend to use a newly
> created fs.
I guess I'll stick with ext4 on the rootfs
> > Another thing is I'd like to see a "first steps after getting started
> > " section in the wiki. Something like take your first snapshot, back
> > up, how to think when running it - can i just set some cron jobs and
> > forget about it, or does it need constant attention, and stuff like
> > that.
>
> There are projects do such things automatically, like snapper.
>
> If your primary concern is to make the fs as stable as possible, then
> keep snapshots to a minimal amount, avoid any functionality you won't
> use, like qgroup, routinely balance, RAID5/6.
So, is RAID5 stable enough ? reading the wiki there's a big fat
warning about some parity issues, I read an article about silent
corruption (written a while back), and chris says he can't recommend
raid56 to mere mortals.
> And keep the necessary btrfs specific operations to minimal, like
> subvolume/snapshot (and don't keep too many snapshots, say over 20),
> shrink, send/receive.
>
> Thanks,
> Qu
>
> >
> > BR Adrian
> >
> >
>
--
Vänliga hälsningar / Kind regards,
Adrian Bastholm
``I would change the world, but they won't give me the sourcecode``
next prev parent reply other threads:[~2018-09-20 23:08 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-16 13:58 btrfs problems Adrian Bastholm
2018-09-16 14:50 ` Qu Wenruo
[not found] ` <CAMrg+aTNK1cBG7rGVfudpydD6hMJz9UW0-3mdS8Yx4tqAQZE6Q@mail.gmail.com>
2018-09-16 20:11 ` Fwd: " Adrian Bastholm
2018-09-16 20:54 ` Chris Murphy
[not found] ` <ecac52ad-70ed-e0e3-5660-1717f0d4f5e0@gmx.com>
2018-09-17 11:55 ` Adrian Bastholm
2018-09-17 12:44 ` Qu Wenruo
2018-09-17 12:59 ` Stefan K
2018-09-20 17:23 ` Adrian Bastholm [this message]
2018-09-20 19:39 ` Chris Murphy
2018-09-20 21:35 ` Adrian Bastholm
2018-09-20 22:15 ` Chris Murphy
2018-09-20 22:21 ` Remi Gauvin
2018-09-22 6:49 ` Duncan
2018-09-16 18:35 ` Chris Murphy
[not found] ` <CAMrg+aQw-sjXpaff=cS6X2-CWDRfOy1f8orQsEsy48xrsuPe3g@mail.gmail.com>
2018-09-16 20:12 ` Fwd: " Adrian Bastholm
[not found] ` <CAJCQCtQPniv4eJSsbT24bma9Gv6_T44zoq9owSYmPNmKO7hXaA@mail.gmail.com>
2018-09-16 20:13 ` Adrian Bastholm
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=CAMrg+aQV97Cv4WgH-DQvwDikFydrxD-zeJajUk3iLk1oKf12_A@mail.gmail.com \
--to=adrian@javaguru.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.com \
/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).