Re: Random file I/O regressions in 2.6

[Nick Piggin]

Andrew Morton wrote:
> Peter Zaitsev <peter@xxxxxxxxx> wrote:
>
> > On Thu, 2004-05-06 at 01:43, Andrew Morton wrote:
> >
> >
> > > One thing I note about this test is that it generates a huge number of
> > > inode writes.  atime updates from the reads and mtime updates from the
> > > writes.  Suppressing them doesn't actually make a lot of performance
> > > difference, but that is with writeback caching enabled.  I expect that with
> > > a writethrough cache these will really hurt.
> >
> > Perhaps.  By the way is there a way to disable update time modification
> > as well ?
>
>
> No, there is not.
>
>
> > It would make quite a good sense for partition used for
> > Database needs - you do not need last modification time in most cases.
>
>
> First up, one needs to remove the inode_update_time() call from
> generic_file_aio_write_nolock() and run the tests.  If this (and noatime)
> indeed makes a significant difference (probably on writethrough-caching
> disks) then yup, we should do something.
>
> `nomtime' would be simple enough.  But another option would be to arrange
> for a/m/ctime dirtiness to not cause an inode writeout in fsync(). 
> Instead, only sync the a/m/ctime-dirty inodes via sync, umount and pdflush.
>
> That way, the inodes get written every thirty seconds rather than once per
> second.
>
> It's probably not standards-compliant, but shoot me.  Who cares if the
> mtimes come up 30 seconds out of date after a system crash?
>
> `nomtime' would be simpler and safer to implement, but not as nice.
>
> But we need those numbers first.  I'll take a look.

Can they use fdatasync? Does it do the right thing on Linux?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/