Agreed, it would be better to sync to disk after multiple files rather than serially; however, in the interest of not being concerned of a power outage during the process, one of the reason the disk cache is disabled, the choice was to fsync() each write.
-----Original Message----- From: Chris Mason [mailto:[EMAIL PROTECTED]] Sent: Monday, April 29, 2002 12:46 PM To: [EMAIL PROTECTED] Cc: Russell Coker; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [reiserfs-list] fsync() Performance Issue On Mon, 2002-04-29 at 12:32, Toby Dickenson wrote: > >One thing that has occurred to me (which has not been previously discussed as > >far as I recall) is the possibility for using sync() instead of fsync() if > >you can accumulate a number of files (and therefore replace many fsync()'s > >with one sync() ). > > I can see > > write to file A > write to file B > write to file C > sync > > might be faster than > > write to file A > fsync A > write to file B > fsync B > write to file C > fsync C Correct. > > but is it possible for it to be faster than > > write to file A > write to file B > write to file C > fsync A > fsync B > fsync C It depends on the rest of the system. sync() goes through the big lru list for the whole box, and fsync() goes through the private list for just that inode. If you've got other devices or files with dirty data, case C that you presented will always be the fastest. For general use, I like this one the best, it is what the journal code is optimized for. If files A, B, and C are the only dirty things on the whole box, a single sync() will be slightly better, mostly due to reduced cpu time. -chris