> Can there be some weird file system inconsistency fsck doesn't spot? Yes. Well, almost certainly. When I was writing the program that became resize_ffs when it was imported into NetBSD, I had a bug which led to the kernel panicking when using the resized filesystem. jtk found it - but the relevance now is that fsck completely missed the subtle filesystem corruption it involved. I don't know whether fsck has been fixed to catch that, but, if so, I'm sure there's another inconsistency nobody's taught fsck to catch, and it could be yours. (Mind you, fsck does know how to catch many . and .. errors. But maybe someone missed one. And, lest you chase a red herring, the issue I dealt with does not match your symptoms; see resize_ffs.c for more.)
I'd suggest poking around the oddities with fsdb or some such userland tool. I'd also have suggested using clri (and then fsck) rather than rmdir to deal with the other directory, but that's water under the bridge now. (rmdir writes to places other than the directory being removed....) Has the place you're getting the odd EBADF errors been created after you deleted the former mystery? I'm wondering if perhaps it got the same inode or the same disk block or some such. Another possibility occurs to me. You write of a 23-hour RAIDframe reconstruction, so you probably are dealing with large filesystems. When I was working with a 7T filesystem, I found peculiar errors which I eventually tracked down to two effective sectors actually being represented by the same piece of disk, meaning each one held whatever was last written to either of them, something filesystems do not deal with well. In my case this was due to a 32-bit bug, but I'm thinking perhaps you're dealing with something more subtle - perhaps one of your drives works fine both before and above the LBA48 boundary but folds the sector exactly at the boundary onto some other or some such; reading quirk lists makes me think such a thing is depressingly plausible. (If you think that particular problem might be it I have a test program you might want, designed to catch just such things.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B