Planet FreeBSD

Posts to mailing lists relating to the graphical console have increased with the growing popularity of the amd64 port. I’m not at all surprised about this. In fact, I’ve seen it coming. That’s why I started vtc(4) development many moons ago. With KGI declared dead, vtc(4) may have grown another leg to stand on: a breeding ground for future KGI development. A new leg does not mean that vtc(4) has a more viable future. The fact that vendors of graphics cards keep their hardware under NDA is a real hurdle for vtc(4) and having proper drivers for graphics hardware is central to the design and implementation. If not for getting the higher resolution, real drivers are needed to get any kind of acceptable performance out of the hardware. Good performance is another hurdle that needs to be overcome. I just ran a kernel with vtc(4) under Parallels (a virtualization package that runs on Mac OS X for Intel processors) and scrolling was painful to watch. Interestingly, Parallels simulates Intel graphics hardware and Intel has documented what which is important to vtc(4). It would be interesting to write a driver for GMCH hardware with accelerated bitblt operations and see if there’s a performance increase. That’s an interesting experiment…

Ok, the work on fast fsck is finished. I integrated it with fsck_ffs(8).

I also changed the way how gjournaled file system is created. Now you need to use ‘-j’ option for newfs(8) to create gjournaled file system. You can also use ‘tunefs -j enable’ on an existing file system. You don’t need to provide ‘gjournal’ mount option any more, but when file system is gjournaled it will be visible in mount options.

I removed a hack of how gjournal was looking for gjournaled file systems. It is much nicer now.

Currently fsck will scan all cylinder groups, which is fast, but it could be a lot faster when I could add cs_nunrefs field to csum structure – file system keeps statistics about all cylinder groups after the super-block and having an information about which cylinder groups have unreferenced inodes would save us a lot of seeking. Unfortunately it will change UFS on-disk layout which is not acceptable at this point.

Now that I have implemented the conditional long branch emulation, it’s inevitable that I need to work on the long branch call form. This, however, requires some side-tracking. Emulating the brl.call instruction requires stack unwinding because it needs to get the value of ar.ec as it was at the time of the trap. It’s also possible that the brl.call instruction writes to one of the preserved branch registers. In that case, we need to know if that branch register was saved and where. Luckily, the runtime architecture states that b0 is to be used to save the return address, so we may ignore writing to other branch registers at first. Nonetheless, stack unwinding is necessary. This, by all means, is a good thing, because we need it in other situations as well — situations we’re not correctly handling now. Maybe I should import the latest libuwx first…

After publishing patches I implemented few suggestions from Robert Watson.

I also implemented better handling of journal overflow. Now one can define at which point journal switch is forced. This can be defined in percents via kern.geom.journal.force_switch. Not ideal, but much better than panicing.

BIO_FLUSH support was added to da(4) disks.

I’m in the process of reimplementing how removed, but still open objects (files, directories) are handled in case of a power failure or system crash.

Currently there is a magic .deleted/ directory where such objects are moved. On boot mount(8) can simply ‘rm -rf .deleted/*’.

The solution I’m implementing currently is to increase a counter in cylinder group (CG) when such situation takes place (objects is removed, but still open). When it is closed, I simply decrease the counter. On boot, a much faster fsck version checks the counter in every CG and if it is greater than 0, it scans all inodes in the CG. If it finds allocated inode, but with linkcnt=0, it cleans the inode, ie. remove all allocated blocks, marks as unallocated, etc.

Because of the complexity of UFS on-disk layout it is not a trivial task. To remove an inode completely I need to:

1. Go through the list of direct blocks pointers and mark the blocks in freeblock bitmaps as free.

2. The same as in 1, but for indirect blocks (single, double and triple).

3. Watch out for fragments. Fragments are only used for small files (which use only direct pointed blocks) and a fragment can be only at the end of the file.

4. Update blocks and fragements counters in three places.

5. Update clusters bitmap.

6. Update pointer of the last used block and fragment if needed.

7. Zero-fill the entire inode.

8. Mark an inode as free in inode’s bitmap.

9. Update inodes related counters in three places.

10. Update pointer of the last used inode.

11. Pray for success.

Most of the things I already implemented, but this is not the code I’d like to show. I’m thinking about extending libufs(3), because now its usefullness is very limited.

This is my first entry in my first blog. Let’s see how it looks.

I finally managed to get audio/amarok updated to 1.4.0a – it was a pain to get it to build, especially on 4.x which required no less than 13 patches.. sheeesh..
Obviously, I got a mail from the amarok developers 2 hours before the commit, telling me that they just released 1.4.1 – typical…

So I guess the circle begins again.
Btw, still no gstreamer support, so I guess we’ll have to make do with xine for a little while longer..

Anyway, if you use amarok – then go update..