Do you still have the filesystem with the undeletable directory?
If so, can you run xfs_db and email me the contents of that directory?
The commands would be:
xfs_db> blockget -n
xfs_db> ncheck lost+found.x
xfs_db> inode <inum>
# if not a shortform directory, ie. the above does not output
"u.sfdir2.etc", do the following sequence for all the blocks
in the extent map, or at least offset 0 and 8388608 if they
xfs_db> dblock <n>
With this output, I should be able to recreate a similar
directory and test xfs_repair for problems.
> -----Original Message-----
> From: xfs-bounce@xxxxxxxxxxx [mailto:xfs-bounce@xxxxxxxxxxx]
> On Behalf Of Paul Slootman
> Sent: Saturday, 12 August 2006 7:15 PM
> To: xfs@xxxxxxxxxxx
> Subject: Re: cache_purge: shake on cache 0x5880a0 left 8 nodes!?
> On Fri 11 Aug 2006, Paul Slootman wrote:
> > Unfortunately, the filesystem panicked again last night.
> > This was after the double repair, and rebooting into 22.214.171.124, which
> > shouldn't have the bug, right?
> > I'll run another repair now :-(
> And again.
> Curious fact appeared: the lost+found directory from the first time
> (which I had moved to lost+found.x) could not be removed
> "Directory not
> empty". This would indicate that the CVS repair version (of 2
> days ago)
> does not properly build the lost+found directory.
> I've now zapped that directory with xfs_db, and am running
> the (daily?!)
> xfs_repair at this moment. As the filesystem is 1.1TB, it
> takes a couple
> of hours :(
> Paul Slootman