On Dec 09, 2003 14:10 -0800, Poul Petersen wrote: > > Are you using this machine as an NFS server, and possibly the clients > > have cached the inode numbers for no-longer-existent inode numbers? > > Yes - this is a NFS server, a rather busy one at that. I'm currently > seeing this error occur 5 or 8 times per day, though the frequency seems to > be tapering off since the last fsck/resize/fsck which occurred on > Dec 3 15:14. I've included the Date/inode#/time data below. That is one of the reasons that IBM never supported filesystem shrinking on AIX JFS. NFS clients could cache their file handles indefinitely AFAIK, although it may be that the clients will be rebooted, unmount/remount the filesystem, or eventually drop those handles, which is why the frequency is decreasing I guess. I don't know if Linux JFS, XFS, and maybe reiserfs support shrinking either. Even so, the number of times shrinking a filesystem is useful vs. NFS clients having stale inodes weighs heavily in favour of allowing shrinking. > Looking at the times at least one of those has got to be triggered by > an automated process given that it seems to occur with startling consistency > around 4:20 am. Should I try and figure out which clients might > have cached these inodes and simply reboot them? Probably yes. tcpdump can probably help you a lot there - just record the source address for NFS requests and correlate them to the error messages. Cheers, Andreas -- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://www-mddsp.enel.ucalgary.ca/People/adilger/ _______________________________________________ Ext3-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ext3-users
