[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Ext2-devel] Re: Linux performance bug: fsync() for files with zero links



On 28-Feb-2006 Erik Mouw wrote:
> On Fri, Feb 24, 2006 at 06:25:20PM -0700, Andreas Dilger wrote:
>> On Feb 25, 2006  05:32 +0500, Victor Porton wrote:
>> > Linux kernel (as of 2.6.15.4) has the following performance bug:
>> > 
>> > Syncing (fsync() or fdatasync()) files with zero links (deleted files) in not
>> > no-op, as it should be.
>> > 
>> > See details, a test C program, and the rationale in the URL below:
>> > 
>> > http://b2e.ex-code.com/index.php/soft/2006/02/24/linux_performance_bug_zero_links_fsync
...
> It even makes sense on a single machine with multiple programs still
> accessing the same file. You want fsync() and fdatasync() to work
> regardless of the amount of links. Not doing so could subtly break
> programs. For example:

Erik, what you said above is wrong.

There are no need to sync this file to disk (except of when we are out of
memory). It is enough to sync the buffers in MEMORY.

>From man write(2):

       write  writes  up  to  count  bytes  to the file referenced by the file
       descriptor fd from the buffer starting at buf.  POSIX requires  that  a
       read()  which  can  be  proved  to  occur  after a write() has returned
       returns the new data.  Note that not all file systems  are  POSIX  con-
       forming.

Accordingly my understanding of the above paragraph there are no need to
do any kinds of syncing after write for the purpose of other processes to
read updated data. POSIX already warrants it and we do not need fsync() for
this.

Somebody with kernel programming experience please update the Linux kernel CVS
to not uselessly sync files with zero links. I am right, this should.be
implemented.

(However, this may be made an optional (either config time or run time) feature
because my suggestion may sometimes (rarely) cause data loss in DELETED files
preventing their undeletion. Indeed I deem that we reasonably could do this
feature not optional as it would harm data safety only a little, but your
mileage whether to do it optional may vary.)

-- 
Victor Porton (porton ex-code com) - http://porton.ex-code.com


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]