File Systems

UFS的目录项中的文件名字段是定长的(参见sys/ufs/dir.h)，这样也许我们可以把symlink的内容(如果够短的话)保存到目录项，而不是inode所指定的fragment上，从而访问symlink可以节省最多两次I/O操作。

在 这里。ZFS提出了很多很有意思的概念，值得一看。

比较感兴趣的几个地方：(1)Solaris的byteswap实现；(2)DSL；(3)ZIL。暂时还没有仔细看ZIL，但这里有一个很有意思的设计：

Recent commits apparantly fixed the livelock issue. This saves my own server (this one) finally. Thanks Suleiman and Alexendar! You heros!!

gjournal is one of the Google Summer of Code projects that is FreeBSD related. It provides data journalling service that will be useful for frequent randomized area writing, just like write clustering.

Today, the first public alpha version has been released.

Please note that this is not intentional to replace SoftUpdates nor a real journalling file system, as the metadata consistency protection is different than just do data writing journalling. However, this indicates a good way of providing better performance for file systems.

So he has finally (after about six or more months) imported read-only ResierFS, congratulations, dumbbell, you have made a quite impressive change!

Since 6-ism VFS interface is quite different from 5-ism, so this change is not likely to be merged IMO. Read-write is also not likely to be available soon, but anyway, ReiserFS is a nice FS and supporting it is a good move.

Today another GPL kernel has problem with a 4TB RAID5 array, it thought that it is 2.1TB (on boot) and refuse to initialize it with its native file systems, including ReiserFS. On contrary, FreeBSD 5.4 and 6.0 works smoothly with a GENERIC kernel. Oh well…

As title. We *need* to struggle to make the upcoming 6.0-RELEASE a good release . I hope we can show the great improvements taken place in 6-CURRENT and hopefully we can cut 6-STABLE this June.

Highlights on recent 6-CURRENT that was not merged (and may never be merged):

• MPSAFE VFS
• Integrated VFS hashing (generallized, traditionally it’s different on ufs, msdosfs, etc)
• 64bit-ize of several utilities, to ensure better usage of large storage.

And finally, it happend.

On Monday, one of our server, running FreeBSD, panic’ed with “ffs_clusteralloc: map mismatch”. This message is quite uncommon and should only happen when there is some “event” with the memory or hard disk.

I have suggested our administrator to reboot and do “fsck” on the volume, since it has very small block size and can not be checked background (I have made a change to warn about this to FreeBSD, and was MFC’ed to 5-STABLE so you will get the feature in 5.4-RELEASE). Unfortunatelly, the check is so slow and we start to suspect whether there is some hardware problem.

1. We should not caclucate the superblock summary, since it can at most lag 30 seconds’ change, and doing the caclucate is painful delay. What we should do is to transfer the responsibility to background fsck
2. newfs(8) should warn about the snapshot is actually unable to create, in case fssize is greater than maxfilesize.

The patch for 1) is available at http://people.freebsd.org/~delphij/ffs/patch-sbsummary. I will work on 2) shortly, as it’s quite simpler than 1).

Finally NetBSD has released their 2.0-RELEASE, which is a significant progress of the NetBSD development.

NetBSD is widely known as the most portable operating system in the world. It currently supports fifty four different system architectures, all from a single source tree, and is always being ported to more. NetBSD 2.0 continues the long tradition with major improvements in file system and memory management performance, major security enhancements, and support for many new platforms and peripherals.

Jean-Sébastien Pédron [jspedron club-internet.fr] has announced that he has ported ReiserFS 3.6 (from kernel 2.6.7) to FreeBSD (with only Read-Only support this time).

Scott Long suggests to import these to base because 6-CURRENT will have a focus on the file system. I suggested that we have a directory under somewhere in the src/ tree to keep these Linux bits so we can backport their fixes more easily and it should be better for us to rip these things out when we have re-written something from scratch.