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.
If you’ve upgraded your Mac to Maverics and tried to build bsdgames-osx, you probably found that the compiler compains bitterly about redefinition of typedef ‘va_list’ is a C11 feature and bombs out horribly. The bug in question is in the system headers, too, so fixing the code is obviously out of my hands. There’s an easy fix, though.
Add CFLAGS=“-std=c11” when running bsdmake to build the games, and it compiles fine. That option works fine when building bsdgames-osx on Mountain Lion as well, but does NOT work on Lion.
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. There are many reasons you wouldn’t want to use it in production, but it’s less likely to set your system on fire now (although of course I can’t promise that it won’t).
Courtesy of kognate over on github, we have a 2.19.1 minor point release of bsdgames-osx. It seems that something changed between the version of clang I have installed and the one he has installed, so he added stdbool.h to mille and made a few other changes to get it to compile. These changes get it compiling happily with Apple LLVM version 5.0. You can see more on the pull request’s discussion.
There is an updated homebrew formula as well, if you’re interested.
On another note, I think this is the first time someone’s submitted a pull request to one of my git repos. It’s kind of a weird feeling.
Equipment: 16” Dobsonian, 55mm, 12mm TeleVue eyepieces, OIII filter, Paracorr.
New objects observed: NGC 7008, NGC 7129, NGC 7160, NGC 7788, NGC 7790, Frolov 1
Previously viewed objects: NGC 6826 (Blinking Planetary Nebula), NGC 6939
There were two reasonably clear nights in a row. That doesn’t happen real often.
I spent some time looking for Herschel 400 galaxies, but sadly right now there don’t seem to be a whole lot of them out. I tried for a few, but none of them were visible on this night. It has to be a very nice night indeed, however, to be able to see most 10th and 11th magnitude galaxies from my house (although I’ve pulled it off on occasion), and this wasn’t quite good enough. Galaxies can be tricky like that anyway.
This was another night of open clusters and planetary nebulae. NGC 6826 (the Blinking Planetary Nebula) was easy, but NGC 7008 was much harder. I was able to see it as a faint smudge, larger than I expected, with the OIII filter. Once again the OIII filter shows its worth looking for a very specific kind of object. I’ve never had much luck with any other kind of filter, but the OIII has performed well for me.
The open clusters were, as usual, nothing to get too excited over. I happened to notice that there was some non-Herschel 400 open cluster near NGC 7788 & 7790, so I looked at that one too. It’s apparently “Frolov 1”, which is some relatively unassuming open cluster. Not very special, but I was a little surprised to see that it does not seem to be on the NGC list.
Confession time: I know they’re important, and some of them are strikingly impressive, but on the whole I think open clusters are my least favorite astronomical object. I’ll observe them if they’re there, I’m trying to complete a catalog, or there’s something particularly neat about them, but most of the time they’re kind of boring. Often I’m not even sure how you tell that they’re a thing. This is not always the case, of course; sometimes they’re beautiful, and sometimes they’re very obviously a discrete group of stars, but a lot of the time I think they look like some stars that just happen to be near each other.
Perhaps I’m a philistine, but I prefer galaxies and globular clusters, at least when I can see them. Open clusters might look more impressive in proper dark sky conditions, but when I’m out in the woods I don’t want to spend time hunting down my least favorite objects.
Equipment: 16” Dobsonian, 55mm, 12mm TeleVue, 6mm eyepieces, 2x Barlow, OIII filter, Paracorr.
New objects observed: NGC 6755, NGC 6781, NGC 752, NGC 1245
Previously viewed objects: Messier 31, Messier 32, NGC 7009
I got a good night for observing for the first time in nearly two months. Ugh. I was mostly pursuing Herschel 400 objects this night, but did spend some time observing the Andromeda Galaxy for a while. It looked pretty good, especially for being in the city – not only was the nucleus nice and bright, but there were hints of the rest of the galaxy around it, even the barest hints of the dust lanes. It wasn’t easy to see, but I could definitely tell something was there. Messier 32 was easy as always, but this was not a night that I was able to get Messier 110 at home, sadly. I did it once (from home; I’ve seen it remotely several times), but not this night.
Otherwise, it was an open cluster and planetary nebula sort of night. The open clusters I observed weren’t anything to write home about, but I wanted to knock them off the list anyway. They are, at least, among the easier Herschel 400 objects to see in the city. NGC 6781 was a pretty tough planetary nebula, but I was able to see it faintly with the OIII filter. The Saturn Nebula was easy, although I did not see the weird protuberances that give it its name this time. On a lark I decided to try using my 2x Barlow that I’ve barely ever touched with the 12mm TV, but it didn’t work out very well. I know some people like Barlows, but I’ve never had much luck with them. Many of the galaxies on the Herschel 400 are extremely difficult or impossible to see from my house, and I don’t get very excited about open clusters. I think I’ll spend more time chasing planetary nebulae around for a while.
I am pleased to announce the release of version 2.19.0 of bsdgames-osx. This release adds ching and wtf to the package. Both taken from the NetBSD sources, ching is the venerable I Ching generator from back in the Version 7 days that was long encumbered by AT&T copyrights. The C program itself was rewritten for 4.4BSD and had no AT&T code, but the data file was encumbered until Caldera open sourced the Ancient Unixes a while back. The other new program, wtf, expands acronyms like TCP, UDP, or WTF.
As always, the homebrew formula has been updated. The homebrew formula for bsdgames-osx also has a HEAD option, so you can install the very latest code out of git with brew install bsdgames-osx –-HEAD, if you decide you wanted to do that.
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. Directory entries were one of those things. The minix fs dentries were fixed length, so all you had to do was set the inode number to 0 to delete the entry. Xiafs, however, extends the previous directory entry to cover the deleted entry (ext2 works this way as well, I believe). This requires passing the previous dentry into the unlink function along with the entry being deleted, so I had to change the find and delete entry functions to do that. That was pretty straightforward.
After I did that, the “free, but marked in use” errors went away, but fsck was still deeply unhappy about directory entries after adding, then deleting, a bunch of files to a directory. The problem here was that xiafs expects to read all of its data in 1024 byte blocks (theoretically it could support larger blocks, but that was never implemented). In the old kernels it would just read the data off the disk itself, but now you use the page cache to fetch data off the disks. This is a good thing, but the pages come in in 4096 byte chunks. The xiafs directory code expects the directory entries to be aligned along 1024 byte boundaries, and just joining directory entries together willy nilly would result in unaligned records spanning blocks. The filesystem would still work, but fsck would scream about the error. Limiting the dentry record lengths to 1024 bytes wasn’t a solution, because all of the dentries combined within the 1024 byte block need to fit. The easiest case to think of is “.” and “..” when the directory is empty – “.” has a record length of 12, and “..” has a record length of 1012 bytes. New dentries get added, reducing the length of the last record until the 1024 bytes are filled. When that happens, dir->i_size is increased and a new 1024 byte directory entry is added. Deleted entries are joined to the previous entry, but they can’t be longer than 1024 bytes and cannot extend past the end of the block.
My solution is here. In plain(ish) English, what it’s doing is after it checks to make sure that the current and previous dentry are not the same, and sets the previous dentry to the correct value if needed, it takes the position in the 4KB page of the previous entry, ANDs it by 1023 (the xiafs block size minus one) to figure out what the position would be in a 1024 byte block, and adds the lengths of the previous dentry and the dentry being deleted to that position. If that value is less than or equal to the xiafs block size, it adds the deleted dentry’s length to the previous entry and sets the pos and len variables to their new values. Otherwise, it just sets the dentry’s inode to 0.
It was a bit tricky, but now it seems to work as well as can be expected. It is, after all, a filesystem with a 2GB volume limit and 64MB max file size, so while porting it was very interesting, I obviously don’t expect much serious work do be done with it. It’s done everything I wanted to do with it, though.
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.
Equipment: 16” Dobsonian, 55mm, 12mm TeleVue eyepieces, Paracorr.
New objects observed: NGC 6882, NGC 6885, NGC 7062, NGC 7296
Previously viewed objects: Coathanger (Cr 399), NGC 7082
The skies were looking pretty good this evening, so I ended up taking the telescope out. The moon’s getting bigger, and this will probably be the last night for a while that I’ll be able to go out observing for at least a couple of weeks. I had a notion to wake the kids up and show them Saturn, but unfortunately by the time I started setting up Saturn was too low and behind a tree. I’ll have to try it again some other time.
The sky was pretty clear, but it wasn’t the best sky I’ve ever seen in Tacoma. I ended up mostly looking for open clusters. I tried for a few very faint objects, and some down in the Sagittarius and Scorpio area, but it was not to be this night. It wasn’t a total loss, since I got some new open clusters from the Herschel 400, but it wasn’t my best night ever. I should, though, start looking for more planetary nebulas I think. I haven’t spent a lot of time looking for those lately, and they’re pretty cool.
All in all, a pleasant enough, if not amazing, observing session. Sadly it was cut short because I was overcome with extreme tiredness, or I might have been able to stay out longer.