On Thu, May 2, 2019 at 11:41 PM Hendrik Friedel <hendrik@xxxxxxxxxxxxx> wrote: > > Hello, > > -by the way: I think my mail did not appear in the list, but only > reached Chris and Qu directly. I just tried to re-send it. Could this be > caused by > 1) me not a subscriber of the list > 2) combined with me sending attachments > I did *not* get any error message by the server. > > >> I was tempted to ask, whether this should be fixed. On the other hand, I > >> am not even sure anything bad happened (except, well, the system -at > >> least the copy- seemed to hang). > > > >Definitely needs to be fixed. > > > >With full dmesg, it's now clear that is a real dead lock. > >Something wrong with the free space cache, blocking the whole fs to be > >committed. > > > So, what's the next step? Shall I open a bug report somewhere, or is it > already on some list? > > >If you still want to try btrfs, you could try "nosapce_cache" mount option. > >Free space cache of btrfs is just an optimization, you can completely > >ignore that with minor performance drop. > > > I will try that, yes. > Can you confirm, that it is unlikely, that I lost any data / damaged the > Filesystem? Not likely. You can do a scrub to check for metadata and data corruption. And you can do an offline (unmounted) 'btrfs check --readonly' to check the validity of the metadata. The Btrfs call traces during the blocked task are INFO, not warnings or errors, so the file system and data is likely fine. There's no read, write, corruption, or generation errors in the dmesg; but you can also check 'btfs dev stats <mountpoint>' which is a persistent counter for this particular device. -- Chris Murphy
