© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
I'm also seeing another nfs4 issue in the logs, stuff like:
bad fileid, expected foo got bar
But it didn't look too bad - the fileid/inode concerned was the root of the NFS4 mount, and I figured some non-critical code inside nfs somewhere was just seeing inode of the mountpoint instead of the directory mounted on the mountpoint, or something along those lines. It didn't seem to immediately cause any problems, but did puzzle me a bit.
Now however, I think its possible the bad fileid issue may be related to this more serious oops on umount bug.
I am just speculating, as I have no knowledge of the source code, but the bad fileid errors I see ALWAYS involve the mountpoint where the nfs share is being mounted. So [erhaps the code to handle bad fileids is a trigger for dentry leak and therefore cause oops on umount?
In any case, please fix these dentry cache errors soon. It is disappointing when the NFSv4 lottery crashes servers and clients year after year, kernel after kernel.
Do we really need to sacrifice stability and lose data just to add new features to nfsv4?
Can we not fix 1 bug without creating 10 more?
Is it time to declare nfs4 fatally flawed and impossible to implement reliably - and then move it out of the kernel and into fuse?