Excerpts from Stephane Chazelas's message of 2011-07-09 16:36:50 -0400: > 2011-07-09 13:25:00 -0600, cwillu: > > On Sat, Jul 9, 2011 at 11:09 AM, Stephane Chazelas > > <stephane_chaze...@yahoo.fr> wrote: > > > 2011-07-08 11:06:08 -0400, Chris Mason: > > > [...] > > >> I would do two things. First, I'd turn off compress_force. There's no > > >> explicit reason for this, it just seems like the mostly likely place for > > >> a bug. > > > [...] > > > > > > I couldn't reproduce it with compress_force turned off, the > > > inode_cache reached 600MB but never stayed high. > > > > > > Not using compress_force is not an option for me though > > > unfortunately. > > > > Disabling compression doesn't decompress everything that's already > > compressed. > > Yes. But the very issue here is that I get this problem when I > copy data onto an empty drive. If I don't enable compression > there, it simply doesn't fit. In that very case, support for > compression is the main reason why I use brtfs here. >
Great, we're on the right track. Does it trigger with mount -o compress instead of mount -o compress_force? This is very likely to be a bug in compress_force, so the extra verification will help. -chris -- 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
