Contributed by johan on from the no-vampire-hunters-please dept.
Todd Fries (todd@) sent this story about what he and Janne Johansson (jj@) did during c2k9. This is exciting news for all those of you who are into massively distributed FSes or just plain work/study at a large company or a large school where the Andrew filesystem is in use.
Arla is a free afs implementation that has made many improvements since it was last updated in the OpenBSD tree, notably block level caching. If we were super-men and lept tall source trees with a single bound, we'd just import the new and improved polished version and be done with it.
However, this is the real world, and as such we have to do things in small steps to make sure we get it right. To get from here to there, we would need to re-invent the hackish scripts to transform arla's new chosen name (nnpfs) into the one in OpenBSD (xfs), and look forward to future painful merges. The other choice would be to rename xfs in OpenBSD to nnpfs, and then we could much more easily update to the new arla. We have chosen the latter. Turns out even this one small step (700k diff) caused us to stumble. We managed to require a surprise libc major bump (major bumps happen in OpenBSD with any change, including syscall renaming), botch the MAKEDEV `commit source, regen, commit rcsid updated MAKEDEV files' procedure, and botch the the syscalls.master similar procedure. In all, it took 12 commits to do what in hindsight should have taken 6 and would have happened later. The next step is to merge any OpenBSD changes into the latest Arla release (0.90.0) and do lots of testing and double checking to make sure it is ready for commit. At least we know there will not be any afs related libc major bumps coming next time around... preliminary testing suggests there is a bug as well, writing to afs causes file truncation in special circumstances, so we'll need to solve this before any possibility of getting this in. Hacking is about whats useful and fun for developers, and for me personally I look forward to having block level caching. It will make a world of difference playing avi files from afs whose indexes are at the end of the file, and in OpenBSD presently, the Arla implementation must cache all blocks up to the block you are reading. 300Mb times 100Mbit means several minute waits to start playing a multimedia file, *yawn*.
Thank you Todd for taking your time to summarize on the latest developments in OpenBSD AFS support.
(Comments are closed)