Once again, the modern-xiafs kernel module has been updated, this time to cover kernels 4.9.6 and 4.10.1. (Strictly speaking it was updated a few weeks or so ago, but only now am I getting around to noting that fact.) These kernels each have separate branches (linux-4.9.6 and linux-4.10.1, respectively) that need to be used to build the right module for that kernel. As usual, even if your current kernel doesn’t exactly match one of the kernels modern-xiafs has been built against, a branch that’s close to it may work.
The modern-xiafs kernel module has been updated to work with (at least) the 4.7.10 and 4.8.7 versions of the Linux kernel. That code is in the current master, but also lives in the linux-4.7.10 branch.
There’s also a small fix for mkfs.xiafs - there was a bug with setting the umask (or, at least, there was a typo in the original program and it was trying to set the umask in a totally obsolete way) that made it so any filesystem created with it would have totally open permissions.
It’s rather been a while since I’ve worked on the xiafs module, but while I was flying to NYC last week I ended up working on it some on the plane and got it caught up with more the recent Linux kernels.
Specifically, kernel version 4.0.9 still works with the 3.16.4 branch, so there were no changes there. Kernel version 4.1.3 and kernel version 4.4.0 had very small updates, so they have their own branches.
The modern-xiafs kernel module for Linux kernel 3.16.4 still works, with no modification, for the 3.18.11 and 3.19.3 kernels. Presumably it will work with other 3.18 and 3.19 series, along with 3.16 and 3.17 kernels, but that hasn’t been tested yet.
I’ve been busy with work and goiardi lately, but I recently checked to see how modern-xiafs did against the 3.16.4 and 3.17.0 Linux kernels. The file ops functions changed subtly again, so there’s a small update to modern-xiafs to work with those kernels. The same update fixes it for both kernels, at least, so there’s only one version of the module for both kernels.
Usual warnings and statements from before, as always, still apply.
Another kernel version, another uneventful update. Once again, the modern-xiafs module needed no update to build, load, and mount filesystems with the 3.15.3 kernel. As before, the README has been updated, but that’s it; all previous warnings still stand, just like last time.
I just went and tested the Linux 3.13.5 modern-xiafs module against Linux 3.14.2, and it built, loaded, and works just fine. The README has been updated to reflect that fact, but there’s nothing else to add; all previous warnings about xiafs before still stand, as said before.
Once again, the new version 3.13 series of the Linux kernel has required an update to modern-xiafs. This particular update was quite small, although not quite as small as the update for 3.12.1. There’s not a lot more to add; all the previous warnings and statements about xiafs from before still stand.
I’m pleased to reveal that I’ve completed an annotated version of the xiafs sources, to hopefully provide an understandable explanation of what’s going on inside a filesystem kernel module. It’s no Lion’s Book or anything, but I hope that it’s informative in its own way. If it sounds interesting, take a look.
The modern-xiafs module, a delightfully useless thing that allows modern Linux kernels to mount and use the ancient xiafs filesystem, has been updated to work with Linux 3.12.1. This was the smallest update yet (one function in inlude/linux/mm.h had been changed). Nothing else of note is in this update, and previous warnings not to use it in production (which would be pretty stupid, seeing as it has those max 2GB volume/64MB file size limitations) and that it could conceivably set your computer on fire or run off with your cookware/checkbook/long term companion remain in effect.
I took a break from sending Kerbals across the solar system to update modern-xiafs to work with the 3.11.1 Linux kernel. This, I’m happy to say, was a small and quick update; the only changes needed were to xiafs_readdir because they went and changed the directory operations in the kernel subtly for some reason.
There isn’t anything of note here otherwise. Xiafs seems to work as expected with no currently known gotchas.
This is pretty nice. I’m happy to say that the bug mentioned in the previous post, where deleting a bunch of entries from a directory, then copying new ones in, would cause fsck to complain about bad directories and some inodes and zones to be “free, but marked in use” has been fixed.
It was an interesting problem. To simplify the xiafs port, I had hollowed out the minixfs code to build on because xiafs was originally an extension of the Minix filesystem, but not everything carried straight over between the two filesystems.
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”.
For the last couple of months, I’ve been working off and on on porting xiafs, an ancient Linux filesystem and competitor to ext2 that lost out and was dropped from the Linux kernel back in 1999, to a modern kernel. I’m happy to say that I’m able to announce the release of modern-xiafs on github. Currently it works with the 2.6.32 kernel that shipped with Debian squeeze, but I intend to get up up to date with the latest kernel versions shortly.