Hrm, this sounds a lot like a problem I've been having as well. Server
is 2.2.19 (RedHat) + reiserfs; client is 2.4.12. There are times when I
mv the contents of public_html to a new location, then rm -rf
public_html, then make public_html a symlink to the new location. On
the client, I think what I would get is an I/O error when trying to list
or cd to public_html. On the server everything is fine, and the only
fix for this I've found is rebooting the client. The original
public_html directory is on a knfsd exported reiserfs fs.
Hopefully this is informative; the bug has only bitten me 2 or 3 times
in several months, and I've not been able to reproduce it at will. :-\
regards,
David
Hans-Peter Jansen wrote:
> Hi Neil et al.,
>
> during the last days, Trond and me was able to hunt a problem down
> to $subject, which happens as follows:
>
> It occurs with all 2.4 kernels, I've tested so far, but for reference:
>
> Server: 2.4.18-pre3 on Dual P3/500 exports reiserfs partitions
> Client: Diskless 2.4.18-pre3 on Athlon 1.2 GHz
>
> When building lm_sensors-2.6.2 on the client, I could easily reproduce
> this:
>
> gcc -shared -Wl,-soname,libsensors.so.1 -o lib/libsensors.so.1.2.0
> lib/data.lo lib/general.lo lib/error.lo lib/chips.lo lib/proc.lo
> lib/access.lo lib/init.lo lib/conf-parse.lo lib/conf-lex.lo -lc
> rm -f lib/libsensors.so.1
> ln -sfn libsensors.so.1.2.0 lib/libsensors.so.1
> make: stat:lib/libsensors.so.1: Eingabe-/Ausgabefehler
> rm -f lib/libsensors.so
> ln -sfn libsensors.so.1.2.0 lib/libsensors.so
>
> In syslog, this message appears:
> Jan 15 00:21:03 elfe kernel: nfs_refresh_inode: inode 50066 mode changed,
> 0100664 to 0120777
>
> In this case, ln managed to create an invalid link in the above sequence.
> Really bad is, you cannot get around this within the client. Within the
> server, the link is ok, but on the client, ls -l lib throws a
> ls: lib/libsensors.so.1: Eingabe-/Ausgabefehler
>
> A comment from Trond << EOC
> It is telling you that the server has a blatant bug: it is first
> telling the client that the inode 50066 is a regular file, then
> it changes it to a link.
>
> When this happens, the RFCs state that the server is supposed to
> change the NFS filehandle. The client *does* check the filehandle, so
> if the server had updated it correctly, you would not have had a
> problem.
> EOC
>
> A least, Trond was able to get me around it with this patch, but
> I would be nice to fix the real problem instead (b/c the build
> feels noticable slower with it):
>
> --- linux-2.4.18-up/fs/nfs/dir.c.orig Fri Jan 11 23:06:38 2002
> +++ linux-2.4.18-up/fs/nfs/dir.c Mon Jan 14 23:52:17 2002
> @@ -619,6 +619,8 @@
> nfs_complete_unlink(dentry);
> unlock_kernel();
> }
> + if (is_bad_inode(inode))
> + force_delete(inode);
> iput(inode);
> }
>
> --- linux-2.4.18-up/fs/nfs/inode.c.orig Fri Jan 11 23:08:00 2002
> +++ linux-2.4.18-up/fs/nfs/inode.c Mon Jan 14 23:53:10 2002
> @@ -699,6 +699,8 @@
> return 0;
> if (memcmp(&inode->u.nfs_i.fh, fh, sizeof(inode->u.nfs_i.fh)) != 0)
> return 0;
> + if (is_bad_inode(inode))
> + return 0;
> /* Force an attribute cache update if inode->i_count == 0 */
> if (!atomic_read(&inode->i_count))
> NFS_CACHEINV(inode);
>
> An noted, this is a longer standing problem here, but with libsensors build,
> I could easily reproduce this. Do yoou?
>
> Any chance to get this fixed soon?
>
> Cheers,
> Hans-Peter
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
-- David L. Parsley Network Administrator, Roanoke College "If I have seen further it is by standing on ye shoulders of Giants." --Isaac Newton- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Jan 15 2002 - 21:00:51 EST