On Mon, 1 Sep 2014 18:22:22 -0700 Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > On Tue, Sep 02, 2014 at 10:08:22AM +1000, Dave Chinner wrote: > > Pretty obvious difference: avgrq-sz. btrfs is doing 512k IOs, ext4 > > and XFS are doing is doing 128k IOs because that's the default block > > device readahead size. 'blockdev --setra 1024 /dev/sdd' before > > mounting the filesystem will probably fix it. > > Btw, it's really getting time to make Linux storage fs work out the > box. There's way to many things that are stupid by default and we > require everyone to fix up manually: > > - the ridiculously low max_sectors default > - the very small max readahead size > - replacing cfq with deadline (or noop) > - the too small RAID5 stripe cache size > > and probably a few I forgot about. It's time to make things perform > well out of the box.. Do we still need maximums at all? There was a time when the queue limit in the block device (or bdi) was an important part of the write throttle strategy. Without a queue limit, all of memory could be consumed by memory in write-back, all queued for some device. This wasn't healthy. But since then the write throttling has been completely re-written. I'm not certain (and should check) but I suspect it doesn't depend on submit_bio blocking when the queue is full any more. So can we just remove the limit on max_sectors and the RAID5 stripe cache size? I'm certainly keen to remove the later and just use a mempool if the limit isn't needed. I have seen reports that a very large raid5 stripe cache size can cause a reduction in performance. I don't know why but I suspect it is a bug that should be found and fixed. Do we need max_sectors ?? NeilBrown
Attachment:
signature.asc
Description: PGP signature
