Stale NFS file handle

[mossroy]

It's the second time I have this problem.

The error message "Stale NFS file handle" appeared on various commands, after a power-cut.
My root filesystem is on a ext2-formatted SDHC card.

I took the card and did a e2fsck on it on my computer : it had several broken files in /etc and /var/log/messages
After a repair, the filesystem seems ok, and everything seems fine.

Anyway, I wonder why a simple power-cut can damage the filesystem of my sd card. The power-cut was not due to overvoltage or storm : it was an intentional cut, to be able to work on the power wires of my apartment.

Maybe if the card was formatted with ext3, it would be safer? But I did not manage to make it work with ext3 (see http://plugcomputer.org/plugforum/index.php?topic=183.msg3467#msg3467)

Did you have the same problems? Any idea of how to avoid that?

[restamp]

Generally, this message occurs when you have an NFS mounted file system and the file the client has an open file descriptor for no longer exists on the NFS server, or perhaps its inode has changed or something of that nature.  It really has nothing to do with ext2 or ext3 file systems per se.

Are you seeing this on your Plug, or on another machine?  Do you have any file systems NFS mounted?  Are you perhaps using TFTP to boot and remotely mounting your root filesystem, rather than using what is on the device itself?

[mossroy]

I don't use NFS at all on the sheevaplug.
I did not install NFS on it (but maybe it is installed : any way to check that? In /etc/init.d I have a mountnfs.sh and mountnfs-clean.sh, but no nfs-*.sh)

I see the error messages on the plug itself (connected via ssh).
I don't use tftp. I sometimes use sftp to access files from my main computer (but it was not even powered on).
I also use rsync to backup the plug on my computer.

I think it must be related to the corruption of my filesystem. Because the e2fsck repair made the error message disappear

[birdman]

The error message "Stale NFS file handle" appeared on various commands, after a power-cut.

That should only be reported by a client that has an NFS file system mounted from a server.  It can occur if yoiu have a handle to a file which has been replaced from a 3rd system, or if the server itself reboots and has to fix the file-system (so that its version number changes). This latter bit sounds close to what you see, except you say you aren't running NFS.  In that case you shouldn't see the message at all.  So somewhat odd.

I took the card and did a e2fsck on it on my computer : it had several broken files in /etc and /var/log/messages
After a repair, the filesystem seems ok, and everything seems fine.

On a power cut the in-memory data won't have been flushed, so recent changes may be missing.  With ext3 the journal at least keeps the meta-data correct (so the file contents may not be exactly as expected, but the filesystem structures will be - it turns the problem from a system one to an application level one)

Maybe if the card was formatted with ext3, it would be safer?

Yes - doesn't need a reformat, though, you can add a journal to an ext2 (with tune2fs?)

[JiriH]

Hi,
I also had a similar problem, but on another machine (not sheeva). And according to what I found here:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/391094
it is a not only related to nfs but to some ESTALE state from glibc. In my case I did:
>touch /forcefsck
>reboot
and after reboot system forces fs  check on root fs and most probably stale handles are fixed.

I wish you luck

Jiri

[mossroy]

Thanks a lot JiriH !

It's probably the reason of this error message.

Now, I'm still worried that the filesystem can get corrupted after a simple power-cut.
Last time I tried, U-boot did not let me boot on a ext3 filesystem (Bad magic number), although it works great on a ext2 filesystem.

[birdman]

Now, I'm still worried that the filesystem can get corrupted after a simple power-cut.
Last time I tried, U-boot did not let me boot on a ext3 filesystem (Bad magic number), although it works great on a ext2 filesystem.

You could create a small /boot partition as ext2, then have the rootfs as ext3.  Since /boot isn't in active use while the system is running (if it's mounted you can update uImage on the running system) you should have the best of both worlds - a boot usable by uboot, and a rootfs that has aj journal.
IIRC this is what was done with GRUB-booting systems when ext3 first came along and it didn't support that.

[JiriH]

I also suggest to create small boot partition. This I learned using gentoo distribution  And it helps me several times.