Regarding CPU vs disk hanging ... fifteen minutes ago, after
doing a "mount -oclear_cache", then a "mount -ospace_cache",
to clear some space cache errors reported by btrfs check,
I changed a shell's working directory into the top directory
of the freshly remounted btrfs file system, and then entered
"cd dir\t", where that tab was the completion character for
my shell.
That shell is still hung in the kernel, on a "disk sleep" fifteen
minutes later, and one of my CPU cores is pegged at 100%,
and the disk activity light is not coming on at all.
Apparently the way that btrfs gets all those nice features is
by placing a lower priority on fast, reliable, responsive,
robust, multi-tasking and on rock solid data integrity under
all manner of simultaneous operations.
What in god green's earth can kernel file system code be
doing that takes fifteen minutes (so far, in this case) or
fifty minutes (in the case I first reported on this thread?
This is not disk bound activity ... it's kernel code bound.
That's insane ... and sad.
--
Paul Jackson
p...@usa.net
--
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
