On Wednesday 31 March 2010 16:03:03 David Howells wrote: > Romain DEGEZ <romain.degez@xxxxxxxxxxxx> wrote: > > So you think this is related to ext4 ? > > No. I'm fairly certain I've worked out what the problem is now. > > What happens is that a cached NFS file is seen to have become out of date, > so NFS relinquishes the object and immediately acquires a new object with > the same key. > > Unfortunately, retirement of the old object is done asynchronously, so the > lookup/create to generate the new object may be done first. However, the > old object and the new object must exist at the same point in the backing > filesystem (i.e. they must have the same pathname). > > So the lookup for the new object sees that a backing file already exists, > checks to see whether it is valid and sees that it isn't. It then deletes > that file and creates a new one on disk. > > Then the retirement for the old file happens. It tries to delete the > dentry it has, but Ext4 complains because the inode attached to that > dentry no longer matches the inode number associated with the filename in > the parent directory. > > The trace below shows this quite well. [..snip..] Indeed, your diagnostic looks coherent :-) Thanks for this very neat explanation by the way. The next question is... do you have an idea to cleanly fix this issue ? :-) Regards, -- RD -- Linux-cachefs mailing list Linux-cachefs@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cachefs
