Re: Re[4]: Rough (re)start with btrfs

[Chris Murphy <lists@colorremedies.com>]

On Sat, May 4, 2019 at 3:31 AM Hendrik Friedel <hendrik@friedels.name> wrote:
>
>  >I should have read this before replying earlier.
>  >
>  >You can also do a one time clean mount with '-o
>  >clear_cache,space_cache=v2' which will remove the v1 (default) space
>  >cache, and create a v2 cache. Subsequent mount will see the flag for
>  >this feature and always use the v2 cache. It's a totally differently
>  >implementation and shouldn't have this problem.
>
> So, you have a suspicion already about what caused the problem? Why is
> v2 then not default? Is it worth chasing the Bug in v1?

v2 is expected to become the default soon

There's known contention for certain workloads when using v1 because
the cache information is stored as if it were a hidden data file,
whereas v2 uses its own btree. But from the sound of it Qu has enough
information to maybe track down the v1 problem and fix it, and
probably should be fixed as v1 is the default and is still supported
and will be forever. But the time frame for a fix may be a while, I'm
not sure.


> For me, the question now is, whether we should chase this Bug or not. I
> encountered it three times while filling a 8TB drive with 7TB. Now, I
> have 1TB left and I am not sure I can reproduce, but I can try.

I don't think it's necessary unless Qu specifically asks.


>
>  >Qu would know better but usually developers ask for sysrq+w when
>  >there's blocked tasks.
>
> I am wondering, whether there is a -long term- a better way than this.
> Ideally, btrfs would automatically create a
> btrfs-bug-DD-MM-YY-hh-mm-ss.tar.gz with all the info you need and inform
> the User about it and where to issue the bug.

No Linux file system has such a thing. And to create such a package
would happen in user space, not the kernel code. Most of Btrfs is
kernel code, same as ext4 and XFS and other file systems. What is
usually the case, if the file system gets confused, it should dump
information into the kernel messages, and the file system developers
do control what kinds of info, error, and warning kernel messages get
dumped into dmesg. Normally that's enough. But since Btrfs is in the
kernel, it depends on other things that happen in the kernel and it's
sometimes necessary to get more information on demand. There really
isn't a way to automate sysrq - you wouldn't want to constantly dump
that amount of information into kernel message buffer and then burden
the system logger with quite a lot of extraneous information.



>
>  >You know what? Try changing the scheduler from mq-deadline to none.
>  >Change nothing else. Now try to reproduce. Let's see if it still
>  >happens.
>
> Wouldn't it make sense first to try to reproduce without changing
> anything?

I assumed it was a persistent problem rather than a transient one. So
yes you should first discover the reproduce steps. That's ideal too
for the developers because often they need to reproduce to see on
their own system what's going on, and often times they have Btrfs
debug option set in their kernels which most distros do not enable. So
they can see more things than we do.

Once you have a reproducer, then you can change the scheduler and see
if your reproduce steps still reproduce the problem.



>
>  >Also, what are the mount options?
> rw,noatime,nospace_cache,subvolid=5,subvol=/
> But noatime and nospace_cache I added just today.

OK that all looks good.


-- 
Chris Murphy