Hi again, After stress testing a gfs filesystem for 24 hours fsck.gfs complains about "Found unlinked inode". This scared me so I reran the test again but got the same result. My test consists of two nodes running bonnie++, postgresql and pgbench against a single file system. Every five minutes one of the nodes is shot. The weird part is that on both occasions the thing fsck.gfs complained about was an "unlinked inode" corresponding to a postgresql pid file. This is a file created (and deleted) every time postgresql is failed over to another node. It is also the last file on the filesystem being deleted when postgresql was shutdown before the filesystem was umounted and fsck.gfs was run. Can anybody explain why this pid file triggered this fsck error twice and not any of the thousands of files created and deleted by bonnie++? Does this mean the filesystem is corrupt, or is this an expected behavior for files deleted directly before a filesystem is umounted? BTW: I'm not able to reproduce this by simply mounting the filesystem, starting/stopping pgsql and umounting. I need to leave the test running over night. I've also performed some tests directly on the SAN device and as far as I can tell it's working as expected. OS: RHEL5 Advanced platform [root@test-db1 ~]# fsck.gfs /dev/testdb/pg_fs Initializing fsck Clearing journals (this may take a while). Journals cleared. Starting pass1 Pass1 complete Starting pass1b Pass1b complete Starting pass1c Pass1c complete Starting pass2 Pass2 complete Starting pass3 Pass3 complete Starting pass4 Found unlinked inode at 2375183 <-- This is a postgresql pid file Add unlinked inode to l+f? (y/n)y l+f directory at 11411 Added inode #2375183 to l+f dir Pass4 complete Starting pass5 Converting 1 unused metadata blocks to free data blocks... Converting 277 unused metadata blocks to free data blocks... ... ... Regards, Jonas -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
