linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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``

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