lkml.org 
[lkml]   [2004]   [May]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Random file I/O regressions in 2.6
Peter Zaitsev <peter@mysql.com> 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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:02    [W:0.147 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site