Re: [bcachefs] time of mounting filesystem with high number of dirs

On Mon, Sep 12, 2016 at 02:59:35PM +0200, Marcin wrote:

<zfs mode on> Why do I ever need fsck?;) <zfs mode off>

hah :)

Maybe, near final version of bcachefs, fsck should be started only after
unclean shutdown?

It's not about unclean shutdown at all, bcache/bcachefs has always been written
to not care about clean vs. unclean shutdown. We don't even have any way of
telling whether the last shutdown was clean or unclean because we really don't
care.

But in the final release we will definitely make it run much less often - right
now, the concern is bugs, anything that fsck finds would be the result of a bug
and if we do ever have that kind of inconsistency I want to know about it sooner
rather than later.

HDD won't die in the next year or two, are you concerned especially on
SSD support in bcachefs?

I'm definitely paying more attention to SSD performance than HDD, but I do want
to make it perform well on HDDs too.

quoted

quoted

quoted

quoted

# time find /mnt/test/ -type d |wc -l
10564259

quoted

quoted

real    10m30.305s
user    1m6.080s
sys     3m43.770s

quoted

quoted

# time find /mnt/test/ -type f |wc -l
9145093

quoted

quoted

real    6m28.812s
user    1m3.940s
sys     3m46.210s

Do you know around how long those find operations take on ext4 with 
similar
hardware/filesystem contents? I hope we don't just suck at walking 
directories.

ext4 with default, 4kB sector size needs at least one hour (I didn't
wait to the end of test). I think that such comparision with ext4 or
testing with other btree_node_size needs simple bash script. I'll wait
with it until OOM fixes will be available in bcache-dev. I've often got
problems with allocation failure when I played with bcachefs,ext4 and
milions of directories.

Oh wow, I guess we're not doing so bad after all :)

Sorry I forgot to reply to your email about the OOMs - those messages are
actually nothing to worry about, we have a mempool we use if that allocation
fails (I'll change it to not print out that message now, just got sidetracked).

I noticed that bcachefs needs a lot lot of less space for keeping info
about inodes. Are metadata compressed? If yes then I should do
comparison of filesystems with and without compression.

There is a sort of metadata compression (packed bkeys), but it's not something
you can or would want to turn off. That's only for keys though, not values (i.e.
inodes).

For inodes, the reason we're taking less space is that since we're storing
inodes in a btree, they don't have to be fixed size (or aligned to a power of
two) - which means we don't have to size them for everything we might ever want
to stick in an inode, like ext4 does, we can have just the essential fields in
struct bch_inode and add optional fields later if we need to.

Additional question:
Should be https://github.com/koverstreet/linux-bcache/issues using?

Yeah... I'm not a huge fan of github's issue tracker but I'm not going to run
one myself, and we do need to start using one.