Hi Phil,
Good idea to look at the other file systems. My (admittedly limited)
understanding of disconnected dentries is based on the Documentation/
filesystems/Exporting doc, which may be a bit outdated. It suggests
that lookup should return whatever d_splice_alias returns (assuming the
inode exists), which may return NULL when the dentry is disconnected?
Also, it seems clear that ENOENT cases require returning NULL.
-sam
Ok, I think we are converging on something here :) Your latest namei3
patch seems to do what you describe, except for the part about returning
whatever d_splice_alias() returns. I experimented by modifying line 213
of namei.c after applying your patch, so that rather than returning
"NULL", it returns "res".
On 2.6 kernels, this still passes all LTP tests and handles deleting
renamed directories without complaint. On 2.4 kernels it causes a
kernel crash when deleting renamed directories. I think both of these
results confirm what we see from other file systems: on 2.6 we should
pass along the return code of d_splice_alias(), while on 2.4 we should
always return NULL.
I doubt that there is a feature test for this- kinda hard to tell when
there is a semantic change to the vfs lookup function.
Do you think that we should go with your patch plus a "#ifdef
PVFS2_LINUX_KERNEL_2_4" wrapper to control whether it returns NULL or
res on that one line?
-Phil
_______________________________________________
Pvfs2-developers mailing list
Pvfs2-developers@beowulf-underground.org
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
