[dm-devel] [Lsf-pc] [LSF/MM TOPIC] a few storage topics

[Jan Kara]

On Thu 26-01-12 11:25:56, Vivek Goyal wrote:
> On Wed, Jan 25, 2012 at 02:35:52PM +0800, Wu Fengguang wrote:
> > On Tue, Jan 24, 2012 at 11:15:13PM -0700, Andreas Dilger wrote:
> > > On 2012-01-24, at 8:29 PM, Wu Fengguang wrote:
> > > > On Tue, Jan 24, 2012 at 09:39:36PM +0100, Jan Kara wrote:
> > > >> On Tue 24-01-12 15:13:40, Jeff Moyer wrote:
> > > >>>> Maybe 128 KB is a too small default these days but OTOH noone prevents you
> > > >>>> from raising it (e.g. SLES uses 1 MB as a default).
> > > >>> 
> > > >>> For some reason, I thought it had been bumped to 512KB by default.  Must
> > > >>> be that overactive imagination I have...  Anyway, if all of the distros
> > > >>> start bumping the default, don't you think it's time to consider bumping
> > > >>> it upstream, too?  I thought there was a lot of work put into not being
> > > >>> too aggressive on readahead, so the downside of having a larger
> > > >>> read_ahead_kb setting was fairly small.
> > > >> 
> > > >>  Yeah, I believe 512KB should be pretty safe these days except for
> > > >> embedded world. OTOH average desktop user doesn't really care so it's
> > > >> mostly servers with beefy storage that care... (note that I wrote we raised
> > > >> the read_ahead_kb for SLES but not for openSUSE or SLED (desktop enterprise
> > > >> distro)).
> > > > 
> > > > Maybe we don't need to care much about the embedded world when raising
> > > > the default readahead size? Because even the current 128KB is too much
> > > > for them, and I see Android setting the readahead size to 4KB...
> > > > 
> > > > Some time ago I posted a series for raising the default readahead size
> > > > to 512KB. But I'm open to use 1MB now (shall we vote on it?).
> > > 
> > > I'm all in favour of 1MB (aligned) readahead.
> > 
> > 1MB readahead aligned to i*1MB boundaries? I like this idea. It will
> > work well if the filesystems employ the same alignment rule for large
> > files.
> > 
> > > I think the embedded folks
> > > already set enough CONFIG opts that we could trigger on one of those
> > > (e.g. CONFIG_EMBEDDED) to avoid stepping on their toes.
> > 
> > Good point. We could add a configurable CONFIG_READAHEAD_KB=128 when
> > CONFIG_EMBEDDED is selected.
> > 
> > > It would also be
> > > possible to trigger on the size of the device so that the 32MB USB stick
> > > doesn't sit busy for a minute with readahead that is useless.
> > 
> > Yeah, I do have a patch for shrinking readahead size based on device size.
> 
> Should it be a udev rule to change read_ahead_kb on device based on device
> size, instead of a kernel patch?
  Yes, we talked about that and I think having the logic in udev rule is
easier. Just if we decided the logic should use a lot of kernel internal
state, then it's better to have it in kernel.

> This is assuming device size is a good way to determine read ahead window
> size. I would guess that device speed should also matter though isn't it.
> If device is small but fast then it is probably ok to have larger read ahead
> window and vice versa.
  Yes, but speed is harder to measure than size ;)

								Honza
-- 
Jan Kara <jack at suse.cz>
SUSE Labs, CR