Messages in this thread | | | Date | Thu, 30 Dec 1999 09:53:04 -0500 | From | Peter Rival <> | Subject | O_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/
| |