Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 13 Apr 2008 09:39:29 -0700
From:      Alfred Perlstein <alfred@freebsd.org>
To:        Jeff Roberson <jroberson@jroberson.net>, arch@FreeBSD.ORG
Subject:   Re: f_offset
Message-ID:  <20080413163929.GE95731@elvis.mu.org>
In-Reply-To: <20080413160829.GA42972@zim.MIT.EDU>
References:  <20080412132457.W43186@desktop> <20080413160829.GA42972@zim.MIT.EDU>

next in thread | previous in thread | raw e-mail | index | archive | help
* David Schultz <das@FreeBSD.ORG> [080413 09:05] wrote:
> On Sat, Apr 12, 2008, Jeff Roberson wrote:
> > It's worth discussing what posix actually guarantees for f_offset as well 
> > as what other operating systems do.  POSIX actually does not guarantee any 
> > behavior with simultaneous access.  Multiple readers may read the same 
> > position in the file concurrently and update the position to different 
> > offsets.  Multiple writers may write to the same file location, although 
> > the io should be serialized by some other means.  Posix allows for and 
> > Solaris, Linux, and historic implementations of f_offset work in the 
> > following way:
> 
> This is not entirely true. In particular, files opened with
> O_APPEND have stronger guarantees, and this behavior can be
> useful. For example, I imagine that a database that opens its log
> file with O_APPEND can depend on being able to write log entries
> concurrently without losing any data. (There are also stronger
> requirements for pipes, FIFOs, etc.)
> 
> As I recall, empiricial evidence shows that SunOS 5.10 and FreeBSD
> both make stronger guarantees than Linux in the presence of
> multiple concurrent writers. I haven't tested readers or looked
> at the fdesc code for any of these.

O_APPEND is kept inside of f_flags and passed down into the VOP layer
so that the filesystem can "do the right thing", basically always
append and get rid of the f_offset problem.  Sort of.

-- 
- Alfred Perlstein



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080413163929.GE95731>