> 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. To achieve this behavior, the change I made to the FUSE fs code is such that when a lookup is performed during a file open(2), the file's dentry is immediately invalidated, so that we essentially get a 'private' dentry and inode, and subsequent path-walks won't find it. Then when the file is opened, I stuff the file struct pointer into dentry->d_fsdata. Then when the getattr is called, I check if the dentry is disconnected and contains a non-null d_fsdata, and if so, forward it to an fgetattr handler using the file pointer. The code is deliciously hacktastic, and adds the cost of all these unnecessary dentry invalidations and lookups. Plus, I haven't even tested it thoroughly, so I'm sure it's gonna screw up some other things. The desired approach here is to just cut to the chase and be able to handle stats made directly to the file descriptor with an fgetattr operation using the underlying file struct. Cheers, - Brian -- 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
