From: Kent Overstreet <kent.overstreet@gmail.com>
To: "Marcin Mirosław" <marcin@mejor.pl>
Cc: linux-bcache@vger.kernel.org
Subject: Re: [bcachefs] time of mounting filesystem with high number of dirs aka ageing filesystem
Date: Tue, 18 Oct 2016 04:45:19 -0800 [thread overview]
Message-ID: <20161018124519.thhcgopwaf5g5lg5@kmo-pixel> (raw)
In-Reply-To: <2427b898-586a-d176-e2c2-34ec0fc1cd55@mejor.pl>
On Tue, Oct 18, 2016 at 02:14:47PM +0200, Marcin Mirosław wrote:
> W dniu 09.09.2016 o 11:00, Kent Overstreet pisze:
> > On Fri, Sep 09, 2016 at 09:52:56AM +0200, Marcin Mirosław wrote:
> >> I'm using defaults from bcache format, knobs don't have description
> >> aboutwneh I should change some options or when I should don't touch it.
> >> On this, particular filesystem btree_node_size=128k according to sysfs.
> >
> > Yeah, documentation needs work. Next time you format maybe try 256k, I'd like to
> > know if that helps.
>
> Hi!
>
> # bcache format --help
> bcache format - create a new bcache filesystem on one or more devices
> Usage: bcache format [OPTION]... <devices>
>
> Options:
> -b, --block=size
> --btree_node=size Btree node size, default 256k
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ it's not true
It is if your bucket size is big enough - btree node size can't be bigger than
bucket size.
> # bcache format /dev/mapper/system10-bcache
> /dev/mapper/system10-bcache contains a bcache filesystem
> Proceed anyway? (y,n) y
> External UUID: 1a064a62-fb61-42c8-8f0e-68961ad37d4c
> Internal UUID: c2802bef-fbc4-414a-9fb0-e071943582c8
> Label:
> Version: 6
> Block_size: 512
> Btree node size: 128.0K
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>
> I see another problem, I observed it due to long mount time.
> I'm creating many dirs:
> # for x in {0..31}; do eatmydata \
> mkdir -p /mnt/test/a/${x}/{0..255}/{0..255}; done
>
> # find /mnt/test|wc -l
> 2105378
>
> df -h shows:
> /dev/mapper/system10-bcache 9,8G 421M 9,4G 5% /mnt/test
>
> next I removing all those dirs. Umount, mount:
> [ 6172.131784] bcache (dm-12): starting mark and sweep:
> [ 6189.113714] bcache (dm-12): mark and sweep done
> [ 6189.113979] bcache (dm-12): starting journal replay:
> [ 6189.114201] bcache (dm-12): journal replay done, 129 keys in 88
> entries, seq 28579
> [ 6189.114214] bcache (dm-12): journal replay done
> [ 6189.114214] bcache (dm-12): starting fs gc:
> [ 6189.118244] bcache (dm-12): fs gc done
> [ 6189.118246] bcache (dm-12): starting fsck:
> [ 6189.119220] bcache (dm-12): fsck done
>
> So mount time is still long, even with empty fileystem.
> df shows:
> /dev/mapper/system10-bcache 9,8G 421M 9,4G 5% /mnt/test
>
> # find /mnt/test|wc -l
> 1
>
> It looks that creating and removing dirs doesn't clean some internal
> structures.
The issue is that right now btree node coalescing is only run as a batch pass
when mark and sweep GC runs (it has nothing to do with GC, it just runs at the
same time in the current code). At some point we need to come up with a good way
of triggering it as needed.
Try triggering a gc, and then check mount time:
echo 1 > /sys/fs/bcache/<uuid>/internal/trigger_gc
next prev parent reply other threads:[~2016-10-18 12:45 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-07 20:09 [bcachefs] time of mounting filesystem with high number of dirs Marcin
2016-09-07 21:12 ` Kent Overstreet
2016-09-09 1:56 ` Kent Overstreet
2016-09-09 2:07 ` Christopher James Halse Rogers
2016-09-09 7:52 ` Marcin Mirosław
2016-09-09 9:00 ` Kent Overstreet
2016-09-12 12:59 ` Marcin
2016-09-13 2:35 ` Kent Overstreet
2016-10-05 12:51 ` Marcin Mirosław
2016-10-06 13:01 ` Kent Overstreet
2016-10-18 12:14 ` [bcachefs] time of mounting filesystem with high number of dirs aka ageing filesystem Marcin Mirosław
2016-10-18 12:45 ` Kent Overstreet [this message]
2016-10-18 12:51 ` Marcin Mirosław
2016-10-18 13:04 ` Kent Overstreet
2016-10-18 13:13 ` Marcin Mirosław
2016-10-18 13:19 ` Kent Overstreet
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=20161018124519.thhcgopwaf5g5lg5@kmo-pixel \
--to=kent.overstreet@gmail.com \
--cc=linux-bcache@vger.kernel.org \
--cc=marcin@mejor.pl \
/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