Re: commands like "du", "df", and "btrfs fs sync" hang

[Kai Krakow <hurikhan77@gmail.com>]

Am Mon, 2 May 2016 09:19:13 -0400
schrieb "Austin S. Hemmelgarn" <ahferroin7@gmail.com>:

> On 2016-05-01 19:49, Duncan wrote:
> > Kai Krakow posted on Sun, 01 May 2016 18:54:18 +0200 as excerpted:
> >  
> >> It affects all file systems. The "btrfs fi sync" is used to finish
> >> my rsync backup and ensure everything is written before I'm trying
> >> to unmount it or the system goes back to sleep.
> >>
> >> "df" and friends also freeze on tmp (ramdisk) fs and vfat fs (my
> >> EFI boot partition).  
> >
> > That's just weird, there.  df on tmpfs triggers a stall as well?
> > Weird to the point I wonder if you're seeing a general block layer
> > bug... only involving btrfs if btrfs is somehow fowling up the
> > block layer for everyone else as well.  Whatever it is, it's
> > obviously far different than my first guess, which now looks
> > ridiculously wrong.  Oh, well...  
> The question is: is it actually on a ramdisk (with a separate
> filesystem on top of that), or is it on tmpfs?  The ramdisk method is
> used by some people because it lets you do some more interesting
> things, but tmpfs is much more efficient (in terms of both processing
> time, and RAM usage). If it's on a ramdisk, then it may be a block
> layer bug, but if it's on tmpfs, then it's a VFS layer bug instead.

Sorry for the confusion: It's actually tmpfs - NOT ramdisk.

> That said, if something i8n BTRFS is causing stalls in the block
> layer, that would definately explain what is going on, as that can
> cause all I/O to stall across the whole system.

It seems to be triggered by access to btrfs for me, tho I don't use
tmpfs that much, so this assumption is more or less bogus.


-- 
Regards,
Kai

Replies to list-only preferred.