lkml.org 
[lkml]   [1999]   [Dec]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectO_SYNC: How well do we support it?
Hi all,

I've run into what appears to be a problem with Linux's handling of
the O_SYNC flag to open() that has left some of my non-believing
colleagues, er, snickering. The basic essence of the story is that it
appears that all file IO is done asynchronously.

I've created a modified AIM VII workload that performs only
synchronous operations (the tests sync_disk_rw, sync_disk_wrt, and
sync_disk_cp for those that know). Even when running a simulated 50
users on a single disk, or 400 users on 35 disks (all ext2), the disk
access pattern is clearly batched even from a "blinky-light"
perspective.

I've taken a look through the write() code path
(sys_write()->ext2_file_write()->generic_file_write()) and none of the
functions even looks to see if the file is opened synchronously. It
looks like we just walk through, dump the buffer into the pagecache, and
then wait for someone to come along and clean up the dirty pages.

So, am I 1) wrong, 2) smoking something, or 3) expecting behavior
not required by POSIX et. al.? Then one interesting thing to note in
all this is that AIM does all of its work with anonymous files (open(),
unlink(), write() in a loop, close() is the pattern for all these
tests). Oh, of course - this is with any late 2.3 kernel, tested with
2.3.29 and 2.3.34+Eric Youngdale's SCSI queueing patches. Anyone have
any ideas? Thanks!

- Pete


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

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