There’s some good news and some bad news on the xiafs front. The good news is that the module loads into the kernel and mounts/unmounts xiafs filesystems just fine with the latest (as of this writing) Linux kernel, 3.10.1. The bad news is that I uncovered another bug (that I’m pretty sure is in the directory code) that affects at least the 3.10.1 and 3.2.0 versions, and probably the 2.6.32 one as well, where if you copy a bunch of files into a directory, delete them, and then copy a bunch more files into the directory, fsck will consider some but not all of the inodes and data zones to be “free, but marked in use”. I’ll need to fix this, but hopefully it’ll be fairly straightforward.
As I posted in an update to the original xiafs post earlier, I finally got the large filesystem mounting bug where it would cause kernel panics randomly upon mounting, unmounting, or rebooting (the exact time of the panic varied) fixed. The reason it was happening was both interesting and humbling; I had brought over some code initializing an array in the superblock info struct that didn’t really do much of anything anymore and certainly wasn’t needed, but I dutifully set it up and initialized it even though it wasn’t peforming any useful work anymore.
Turns out that I should have looked more closely at what it was doing, because I was writing off the end of the array. With smaller filesystems it was OK, since it either didn’t go past the array or didn’t overwrite anything that would cause the kernel to panic, but with filesystems larger than about 1.5 GB or so, it would overwrite something and eventually cause a kernel panic. Ooops. What I should have done was be more careful about what old kernel code I was bringing over, and paid more attention to a) what it did in the old version and b) what function it might actually perform now. Lesson learned, at least.
This was a reminder that cargo culting is bad, kids.
comments powered by Disqus