Re: fgetattr/fsetattr file operation

[Andreas Dilger <adilger@sun.com>]

On Jun 04, 2009  10:42 -0700, Brian Molnar wrote:
> > On Thu, Jun 4, 2009 at 3:27 AM, Miklos Szeredi <miklos@szeredi.hu> wrote:
> > Can you tell us a bit more about your use case, and how you worked
> > around the limitation?
> 
> In this FS, when a process opens a file for write mode access, it
> maintains its own private copy of the file until it comes time to
> close. Upon close, this private copy is "committed" and replaces the
> file on-disk. Meanwhile, while the file is open for writing (before
> close) the file on-disk remains untouched (both data and metadata).
> Thus, any metadata-changing operations that take place against the
> file descriptor must only be seen to the process(es) using that file
> descriptor. The intended behavior is that an fstat(2) against the file
> descriptor will return the attributes corresponding to the
> uncommitted, private copy and a path-based stat(2) will return the
> attributes of the file on-disk.

This sounds very strange - different processes (or even the same
process using different file handles) will see different results
for fstat() which are yet different from stat().  I can't imagine
that applications would like this at all.

> To achieve this behavior,

Maybe you should go back and explain why this behaviour is useful,
before we burden the kernel with it.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.