As a general "rule of thumb", full partitions are slow partitions
irrespective of filesystem structures. There are probably filesystems
that work well when full for some specific types of I/O, but *random*
I/O is going to suck on a rotating seeking set of platters if there
are very few places to write new stuff and previously written stuff is
scattered over many tracks and sectors.
blktrace is your friend if you want to help debug btrfs on this use case. ;-)
On Mon, Sep 19, 2011 at 10:56 AM, Greg KH
Hi Jeff,
The day after the openSUSE conference, Jos showed me his laptop and a problem with it under the most recent Tumbleweed kernel (and older kernels as well.)
He is copying a very large (3Gb) file to his btrfs partition from a USB external drive (running ext3) such that if it succeeds, the partition will almost be full (only a few Mb left). This should be fine, but it almost kills the system, slowing responsiveness down to nothing being possible to do at all on the box until the copy completes 15+ minutes later. It is possible to eventually interrupt the copy, and when that happens, the system returns back to life.
Copying the other way (from the btrfs partition to the USB disk), works absolutly fine, so it doesn't seem like the system is hurting from memory pressure on anything else.
Is this a currently-known issue on btrfs when the filesystem is almost out of space and it just takes forever to find empty blocks in which to put things, or is it something that we should log in a bugzilla entry and try to get resolved?
thanks,
greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
-- http://twitter.com/znmeb http://borasky-research.net "A mathematician is a device for turning coffee into theorems." -- Paul Erdős -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org