On Mon, 2012-07-16 at 11:43 -0400, Chris Mason wrote: > On Mon, Jul 16, 2012 at 04:55:44AM -0600, Mike Galbraith wrote: > > Seems btrfs isn't entirely convinced either. > > > > [ 2292.336229] use_block_rsv: 1810 callbacks suppressed > > [ 2292.336231] ------------[ cut here ]------------ > > [ 2292.336255] WARNING: at fs/btrfs/extent-tree.c:6344 use_block_rsv+0x17d/0x190 [btrfs]() > > [ 2292.336257] Hardware name: System x3550 M3 -[7944K3G]- > > [ 2292.336259] btrfs: block rsv returned -28 > > This is unrelated. You got far enough into the benchmark to hit an > ENOSPC warning. This can be ignored (I just deleted it when we used 3.0 > for oracle). Ah great, thanks. I'll whack it in my tree as well then. > re: dbench performance. dbench tends to penalize fairness. I can > imagine RT making it slower in general. It seems to work just fine for my normal workloads, and cyclictest is happy, so I'm happy. Zillion threads is 'keep the pieces' to me ;-) If you think the patch is ok as is, I'll go ahead and submit it after I let dbench hammer on it overnight at least. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html