Am Mon, 2 May 2016 09:19:13 -0400 schrieb "Austin S. Hemmelgarn" <ahferro...@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. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
