Hi, On Sat, 2009-08-08 at 19:19 -0400, Wendell Dingus wrote: > Well, I just ran fsck.gfs2 against this filesystem twice with a 10-minute > pause between them. As such: > # fsck -C -t gfs2 -y /dev/mapper/VGIMG0-LVIMG0 > > Output of second run: > fsck 1.39 (29-May-2006) > Initializing fsck > Recovering journals (this may take a while)... > Journal recovery complete. > Validating Resource Group index. > Level 1 RG check. > (level 1 passed) > Starting pass1 > Pass1 complete > Starting pass1b > Pass1b complete > Starting pass1c > Pass1c complete > Starting pass2 > Pass2 complete > Starting pass3 > Pass3 complete > Starting pass4 > Pass4 complete > Starting pass5 > Unlinked block found at block 37974707 (0x24372b3), left unchanged. > ..snip about 30 total of these.. > Unlinked block found at block 96603710 (0x5c20e3e), left unchanged. > Pass5 complete > Writing changes to disk > gfs2_fsck complete > > When it was done I remounted the filesystem and tried to "rm -rf /raid1/bad" > which is a subdir in the root of this filesystem that contains the zero-byte > file that was the focal point of this grief to start with. > > Results: > That looks like a bug in fsck at least as it should be dealing with the unlinked blocks that it finds, not ignoring them. Chances are that the block which is causing the issues belongs to one of the unlinked blocks (inodes I think it should say) Steve. -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
