On Sat, May 4, 2019 at 3:31 AM Hendrik Friedel <hendrik@xxxxxxxxxxxxx> 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
