Messages in this thread | | | Date | Thu, 6 May 2004 14:49:33 -0700 | From | Andrew Morton <> | Subject | Re: 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/
| |