A little while ago Kevin Musick from Teldar donated the BeServed source code to the Haiku Project, so we contacted him about it and arranged an interview. Thom Holwerda from OS News was also invited to ask a few questions, which provide some welcome perspective and encourages some cross-site promotion. (edit: I see Thom posted his side...)

Here's what Kevin has to say:


Tell us a little about yourself, what is the one thing you are most passionate about these days?

At the risk of sounding too contrived, I’m probably most passionate about my family. I am also excited about some of the opportunities in my current line of work.


What are you currently working on these days?

I served as Chief Technology Officer of a national settlement services firm until late in 2005. By that point I had created an application for merging consumer credit information from the United States’ three repository firms and sold that business to TransUnion. Following a two-year consulting agreement with the acquirer, I created a business and the accompanying software application for valuing mortgage-backed securities. Neither of these projects were as technically interesting as BeServed, but they’ve more readily paid the bills. I’m currently consulting in the consumer credit industry.


How did you come up with the idea for BeServed, was there any catalyst or spark that inspired you?

I needed a project for a thesis paper and was intrigued by the BeOS platform. It was apparent to me that the Be File System (BFS) had unique value that couldn’t be realized over NFS, CIFS, or other network file systems. I felt this would ultimately limit the use of attributes because they couldn’t follow files stored on network resources. The BeServed project allowed me to work extensively with BeOS while completing research on the performance impact of file metadata, i.e. BFS attributes, on network file systems. Sales of the resulting product further allowed me to cover expenses associated with its development and some costs of my education in general.


What does the future hold for Teldar the company now that its flagship product has been given to Haiku?

I founded Teldar in the days just prior to widespread Internet commercialization. We tackled a few software projects, but nothing that was overwhelmingly successful. I later did a little work on the GNU Mach microkernel and contemplated a commercial distribution of the GNU Hurd operating system, but it was difficult to make a good business case for that at the time. I later used Teldar as essentially a holding company for the BeServed intellectual property, in case Be or anyone else eventually wanted to acquire the technology. As a business entity, Teldar’s usefulness has run its course.


What are some of the shortcomings of BeServed that the Haiku Developers should be aware of?

One troubling issue was the need for unique inode numbers. Mounting multiple file systems, including Windows-based systems that required algorithmically-generated inode numbers, could cause inode number duplication, leading to kernel panic. I toyed with a solution where files were referenced in remote procedure calls by filename rather than inode number, as in Microsoft’s SMB/CIFS. In this case, faux inode numbers would be generated by the BeServed file system add-on that would pacify the local BeOS kernel. An internal structure would be maintained to map between these inode numbers and the files they referenced. Alas, I never had the opportunity to see that work to its fruition.


Was the threading model in BeOS a challenge for BeServed development, and can you speak on whether this will affect I/O performance from a high level perspective?

The threading model certainly complicated interface development, such as that used in the MyNetwork and FileSharing applications. MyNetwork essentially browsed and mounted BeServed shares over the network, and the FileSharing application configured shared folders on a host.

Aside from that, I don't recall that the BeOS threading model posed a challenge. The original user-space network layer (I believe it was called net_server) was by far the most limiting factor in terms of performance and reliability.


It's a known issue right now with Haiku's I/O scheduler that it is sub-optimal. Would this subsystem have to be cleaned up before we would see real benefits to BeServed's addition to Haiku?

I don't have experience running Haiku, but performance would be the chief concern. BeServed, like any network file system, can conduct significant network traffic via remote procedure calls. Each of these calls has a timeout period that, when exceeded, triggers packet retransmission. If delays are introduced that cause frequent timeouts to occur, the system may spend significant time performing redundant work. This behavior could occur with any network file system.

BeServed did, however, utilize TCP connections as opposed to the connectionless UDP approach used in NFS, which alleviated the need to perform adaptive retransmission, packet ordering, and such. BeServed also employs a Dynamic Name Lookup Cache (DNLC), packet bursting, lagging packet buffers, and other algorithms intended to deliver the most
optimal performance given the environment.


What are some of the features that you had planned for BeServed that didn't come to light? Would these be suitable for use in Haiku?

I was just scratching the surface of network printing, for one thing. I also envisioned using BeServed to create a BeOS-centric online storage offering similar to what Apple did with iDisk. While numerous companies sprang up in the document hosting space, most were WebDAV interfaces and none would accommodate BFS metadata. At this point, I don’t know that an iDisk clone is as compelling as general-purpose file and printer sharing.

BeServed also included the BeSure authentication server, which was effectively a domain management application. Shared directories could be given separate permissions based upon the credentials supplied at mount time, but a full-blown access control list mechanism for per-file privileges within the file system would have been nice. Moreover, local users had essentially root access on BeOS, so the rights assigned with BeServed could be circumvented if a user had local access, or remote shell access, to a host BeOS machine. Correcting this would have required fundamental security changes within the core OS.

I had also hoped to get a PowerPC version running, but demand was never that high and I didn't have a suitable machine to work with. I did make the underlying RPC layer aware of the "endianness" of the host processor, but it never went any further.


Which OS platform was harder to develop on and why?

I would say the Windows platform posed the most challenges, primarily because it isn’t POSIX compliant and therefore required the greatest customization. Windows also identifies files by name and not an inode number, so to remain compatible with file system add-ons in BFS those numbers needed to be algorithmically generated.

The original BeOS networking layer, prior to BONE, also caused a few headaches. The context switching made it painfully slow and it was wrought with limitations and incompatibilities in comparison to more mature BSD-style implementations. It may have worked well for Web-browsing over dial-up connections, but was woefully ill-prepared for the scalability requirements of high-traffic network applications.


The following questions come from Thom Holwerda of OSNews:


What do you hope BeServed contributes to Haiku?

In any project of Haiku’s size and duration, there inevitably are periods where people can be overcome by the size and complexity of work that remains. Having been disconnected from the efforts of the open BeOS movement for a few years, I have a nice retrospective view of its progress. Consequently, my chief wish is that opening up BeServed could be an opportunity for the team to look back in favor on its tremendous accomplishments and potentially be a catalyst for greater community involvement in the future. Aside from those lofty things, I certainly hope that it has some value as a general-purpose file and printer sharing infrastructure. If not, perhaps the underlying proprietary remote procedure call interface has some potential.


What was the 'final straw' that made you give the code to Haiku?

I haven’t had the opportunity to work on the BeServed project in several years, and it seemed such a shame to waste all that effort. When I realized the progress that had been made on Haiku, I was hopeful that the team could put the code base to better use than I could.


Was BeServed a success back when Be was still operating?

That depends on your evaluation criteria. I’d say that I achieved the obvious goal of enabling network file sharing from within BeOS, though there were still some stability and performance improvements in flight when I was no longer able to sustain development work. Additionally, it was originally intended to serve as thesis paper research, and given that my work was well received by my academic sponsors I’d say it was successful from that standpoint. However, it can’t be regarded as commercially successful. While I covered the costs of its development, I profited only a few pennies per hour of work. Had the technology been acquired by Be, Inc. then perhaps the pro forma would be more compelling.


Do you see a possible solution for the attribute problem (where other operating systems disregard BFS attributes)?

I tinkered with an implementation of attributes on Linux that used a Berkeley database file to store attributes, using the local inode number as a key value. This was a rather makeshift solution that I never had the opportunity to evaluate using sufficiently busy networks and large file systems.


Do you see any future for yourself in the Haiku world?

I can’t completely close the door on that given my longtime interest in operating system research. However, I’m sufficiently tied to other initiatives at this point that will preclude any involvement in the near future.

We asked Axel Dorfler to comment on the plans in store for Haiku in the future, with the simple question:

Axel, what are the plans for BeServed now that it is in the Haiku subversion repository?

We already have a networking file system in our repository that enables BFS features like attributes over the network. It's not completely finished though, and is currently for BeOS only (like BeServed), and also misses servers for other operating systems as BeServed does.

When the time comes to create the Haiku solution for shared resources over the network, we will try to take the best parts from both file systems, and combine/complete/replace them in a useful way. My hope is that the donation of BeServed will improve and speed up the creation of a networking file system for Haiku.

Thanks Kevin, Thom, and Axel for participating in this interview, we will are looking forward to seeing this additional code be put to good use.