On Jun 04, 2009 10:42 -0700, Brian Molnar wrote: > > On Thu, Jun 4, 2009 at 3:27 AM, Miklos Szeredi <miklos@xxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
