Csaba Henk

Email: <soc-chenk>

$ whoami

I'm from Hungary. I graduated at Eötvös Lorand University of Science with an MSC in Mathematics, in 2001. Since then I am a PhD student in Mathematics at the Central European University. My area of research is Foundations.

In the meantime I picked up some computer skills, that's how it can makes sense that I am here. My starting point was the LinuxFromScratch project, the most fantastic form of self-education I've seen.

I happen to administer a server for a company run by friends. We used to run on Linux but when a new machine has been bought, we wasn't careful enough so we faced with the outrageous Promise PDC20371 RAID controller within the shiny new box. Soon it turned out that the only open source OS which has support for it is FreeBSD 5.x, thus we switched to FreeBSD. That's how I met with the OS.

Since than I pretty much fell in love with FreeBSD, due to its well-known feature set: support for a waste range of third-party software, clean architecture, maintainability, stability.

My primary tool of administration is the Ruby language. It features a concise syntax, out-of-box support for most scenes of system administration, powerful, unconstrained semantics. I usually use it via a self-made shell (with full job control, etc.) atop of Irb, the interactive Ruby interpreter. You can find more info on it and other projects of mine at my project page.

Ssh based filesystem for FreeBSD

As a Google Summer of Code 2005 participant, my mission is to implement ssh based networked filesystem for FreeBSD.

Intro

As ESR says in The Cathedral and the Bazaar, Every good work of software starts by scratching a developer's personal itch. While I don't yet know how good work will the software be this project will end in, the story has begun by having a personal itch, for sure.

If you got the feeling, you'll know how cool it is when you can mount any remote machine's filesystem via net, given you have (normal, unprivileged) access there. Now I could go on and find the appropriate attributes for this feeling to make you impressed, but heck, I don't wanna waste my time for that, and we are not into literature now, and anyway, you can go and try it by yourself. It doesn't hurt, you just have to install Linux on your computer and one of the additional software listed below. The itch is... this fun is only for Linux. I began to use FreeBSD and I quite like it, but this functionality is not availabe for FreeBSD. FreeBSD users have to live without it. And now, now I suffer from withdrawal symptoms...

So when I heard that Google launches its Summer of Code program I decided to try to get Google pay for me for bringing this functionality to FreeBSD. The first step has been taken successfully... I've been chosen to be a SoC participant at FreeBSD. So now, shut up and code!

Let's take a look at the Linux front

Well, to be more concrete I tell you that you can get a server-agnostic remote filesystem by building it atop of ssh -- the most common remote access protocol in the Unix world these days. Linux users really have a choice:

  1. Shfs by the Zemljanka core team -- a standalone implementation based on direct remote program running capabilities of ssh. This is noteworthy as all the others utilize the sftp subsystem of ssh.

  2. Lufs (Linux Userland FileSystem) -- a general userspace filesystem framework by Florin Malita, with several concrete filesystems, among them there is one based on ssh. Note that both shfs and Lufs' ssh fs borrows many ideas from an earlier work of Malita, FTPfs.

  3. Miklós Szeredi's FUSE (Filesystem in Userspace) is slowly tending towards being the userspace filesystem framework for Linux. It is actively maintained, and, as it is rumored, it will be integrated into the 2.6.13 release of the kernel. It features two implementations of an ssh based networked file system:

    1. SSHFS is port of Malita's implementation to FUSE, cleaned up and optimized, by Szeredi himself.

    2. Gnomevfs-mount by Sandino Flores makes it possible to mount various things via Gnome's vfs library. As Gnomevfs supports the sftp scheme, you can use it for ssh based mounts, too. Gnomevfs-mount also utilizes FUSE as an userspace filesystem backend (well, if I understand correctly, not todays' FUSE, but a FUSE from one generation back, when it has been called AVFS (A Virtual File System)).

Musings as of 27th of June, 2005

I guess I'll make myself familiar mostly with Shfs -- its compact and mature, and I have already a basic familiarity with it. The other candidate could be FUSE SSHFS as it is mature enough, too, and I'd bet that code is rather high quality. But understanding a general API and its implementation seems to be much more work than understanding a lean-and-mean implementation. That's why I'd go for Shfs.

I don't know if I should use sftp or direct remote scripting. Maybe I should ask the Shfs guys who are the lone champions of the latter approach why did they go that way.

And/or get a clear picture about the sftp protocol.

By the way, questions... Among NetBSD's SoC projects I found one which falls into the same category as mine (ie., userspace filesystems):

Userspace file system hooks for NetBSD. I asked the guy doing it, Antti Kantee, what his plans are. Not much yet (well, it's not surprise), but he told he's not interested in creating concrete filesystems (at the moment), he is into making the framework.

Update. I've been changing mails with Miroslav Spousta, the man behind Shfs. He was very helpful and he suggested me to use the sftp subsystem -- the direct remote scripting they used was an interesting experiment but using stfp is more robust. So that's what I'll do then...

Musings as of 4th of July, 2005

On IRC I was told about a freebsd-hackers post on GmailFS. There I saw RobertWatson mentioning xFS, part of the Arla project. Well, now it's called nnpfs due to name conflicts. A pretty complete multiplatform userland vfs framework. nnpfs lacks a library component though which would make making concrete filesystems easy, see eg. this LKML post.

So I got the idea:

To not blindly jump into this bandwagon, I asked other people about this idea.

Either way, I'll stick with nnpfs, because of the following:

And I'll take FUSE/sshfs as the sample implemetation (and not shfs, as I used to plan), because:

So let's put together a lil' schedule-like thing. Starting with 4th of July, I have eight and a half week.

Eh?

Musings as of 7th of July, 2005

So, I found some really cool stuff on nnpfs. Eg, there is this thesis on porting arla to win2k which gives a nice description of how arla works. It turns out that not open() is the call which makes files fetched completely. No. But if you seek some offset in the remote file, the file will be pulled until that offset, just because the arla filecache doesn't support caching regions of files. To keep integrity of the cache, everything has to be pulled till the offset. (I guess RobertWatson was speaking about this, it was just me who misunderstood his explanation.) It seems to me, however, that this caching policy is chosen by arlad, the userspace part of arla, and not nnpfs, the kernel backend. I won't verify this assumption, though; read on and you'll see why.

But in fact I wanted to speak primarily about my other findings.

The basic problem is that despite its generic design, nnpfs is interfaced only with arlad which is quite a complex stuff. I wanted a simple client to get the feeling.

Christopher Marlowe has a sketch of implementing a dummy fs based on nnpfs. I mailed him, he gave some further pointers -- eg., it turned out that the nnpfs api is indeed documented in doc/nnpfs.txt (of the arla source tree)(I didn't notice it by myself, it's buried in a pile of texinfo files), and a very-very valuable resource: an ftpfs based on nnpfs!, by David Leonard. He attaches a detailed description of the design and implementation of the fs, history of the idea and problems he had to face with. The code in fact was written when nnpfs was called xfs, and I had to see that there were deeper api changes in nnpfs than replacing all occurrences of xfs with nnpfs (and of XFS with NNPFS). That is, it's far from being compilable out of the box. Well, I don't think that would be hard to get over.

But... Nononononono. That's not the way to go. Goodbye nnpfs.

In the meantime, I've been peeking into the FUSE source. Only the userspace yet, but it's clear that the protocol is so damn simple. Spawning a glue layer between nnpfs and fuse seems to be a pain. nnpfs api is hard. It seems to be easier to make a direct port of FUSE to FreeBSD than to properly translate nnpfs messages to FUSE ones. And if not a faithful translation... having a not-exactly-FUSE-compatbile-however-FUSE-like lib is pointless. Even if it were crossplatform (as nnpfs is). FUSE as such is the hot thing. FUSE, no strings attached.

The final event pushing me towards FUSE was finding the plan of Desktop VFS. It's something like GnomeVFS, a lib which can be used to access resources via various uri schemes. But, they explicitly plan having a FUSE backend, too. The tendency is that if someone feels that a filesystem would be a useful abstraction of the semantics she is dealing with, then she will go for FUSE. Because FUSE is hot (getting integrated into Linux, has many client fs-es) and sexy (welcome to the world of one-liner filesystems). Having problems with design and/or implementation won't change these facts. One particular problem: being non-crossplatform can vanish easily... just let's get that ball rolling.

Taking the nnpfs/ftpfs and hacking it until it will work with sftp (with or without a more general framework) won't have that much use for FreeBSD. But FreeBSD will have to acquire FUSE support, sooner or later. Why not now?

Musings as of 9th of July, 2005

OK, so I'm a bit calmer today, so let's re-evaluate my previous rant.

What I still want to stick to is aiming at a compatible FUSE implementation for FreeBSD, because

But these don't imply that nnpfs is not a suitable backend. I kept on evaluating this possibility. I tried to get the nnpfs/ftpfs working. That code has a rather clean, orthogonal design, with a somewhat obejct oriented flavour, and it's very close to being the "chain's missing link", ie. "libnnpfs". It seems that FUSE-compatible api could be easily built on the ftpfs codebase, too. I had some problems, see my post to arla-drinkers (and its followups). It would be easy to get over those, though, RobertWatson is helpful and capable.

Nevertheless, now I really decide to go for the direct FUSE port. The reason for this the mechanism, not policy idea. The communication between nnpfs and the userspace daemon is tightly bound with nnpfs' caching implementation. The daemon doesn't have total control over the system calls thrown at the filesystem: nnpfs passes them to the daemon only if it feels like to do so, and even if it does that, not the whole information is passed over.

Now we could argue about the merits and drawbacks of the nnpfs cache, but that's would just be escaping from the real problem. If we want to have a general userspace fs framework, it's bad to have such a special component wired in. As a userspace fs framework author, you can't say to your present and future clients, you have to use such-and-such caching, period.

So let's just make a direct FUSE port.

Musings as of 13th of July, 2005

I rediscovered Pavel Machek Podfuk, which is a userspace vfs championing code reuse: it builds a Coda client which utilizes Midnight Commander's vfs lib for file operations. It's also portable, as no kernel hacking is involved. The code has explicit support for Linux and Solaris, but is dated -- I wanted to try it (under Linux), but it depends on an old version of MC which didn't compile (no, I don't want to kill my time by getting over those problems).

It made me to take a quick glance at the possibility of a Coda -> FUSE bridge. I just found yet another LKML thread on FUSE merger, and a post of the thread, where exactly this is what is being discussed (to make it more interesting, in a dialog between authors of Podfuk and FUSE). It shows that Coda has a similar problem to that of nnpfs: penalized random access due to integrated caching. (As a side effect, it also strengthens my impressions that touching nfs is bad for your health). This issue has been also discussed in a Coda ml post about Podfuk's ftpfs (though it's old and that info might be out of date).

Just to make sure: now I'm dealing with the direct port and not killing much time on looking for alternatives. Coda was just an interesting mental experiment (the lkml post pretty much saved me from wasting time on evaluating Coda [or from being left within doubts about The Right Thing]).

Musings as of 15th of July, 2005

I pulled down latest FUSE from CVS, and diffed it against latest release. The distribution contains a file named Filesystems, in which you can read about FUSE-based vfs implementations. The diff for this file was: 

diff -Naur fuse-2.3.0/Filesystems fuse/Filesystems
--- fuse-2.3.0/Filesystems      Thu Jun  2 11:50:18 2005
+++ fuse/Filesystems    Fri Jul 15 09:35:41 2005
@@ -362,3 +362,69 @@
   mount your audio cd.

 ==============================================================================
+Name: Fuse-J-shfs
+
+Author: Paul "Joey" Clark / joey at hwi ath cx
+
+Homepage: http://hwi.ath.cx/twiki/bin/view/Neuralyte/FuseJshfs
+
+Description:
+
+  Fuse-J-shfs lets you easily implement a virtual filesystem in Unix
+  shellscript.  And naturally, it already has some handy vfs
+  implementations you can use straight away: gzip, rar, sparse, ...
+
+==============================================================================
+Name:  SMBNetFS
+
+Author: Mikhail Kshevetskiy / kl at laska dorms spbu ru
+
+Homepage: http://smbnetfs.airm.net/
+
+Description:
+
+  SMBNetFS is a Linux filesystem that allow you to use samba/microsoft
+  network in the same manner as the network neighborhood in Microsoft
+  Windows.
+
+==============================================================================
+Name: NTFS-FUSE
+
+Author: Yura Pakhuchiy / pakhuchiy at gmail com
+
+Homepage: http://linux-ntfs.sf.net/
+
+Description:
+
+  NTFS-FUSE is part of ntfsprogs package (utily name - ntfsmount). It's rely
+  on libntfs. NTFS-FUSE support file overwrite changing it size and can
+  list/read/write/add/remove named data streams via xattr interface.
+
+==============================================================================
+Name: BTSlave (BitTorrent File System)
+
+Author: Bill Cox / bill at viasic com
+
+Homepage: http://btslave.sourceforge.net/
+
+Description:
+
+  BTSlave allows users to mount a BitTorrent .torrent file as a file
+  system.
+
+==============================================================================
+Name: GfarmFS-FUSE
+
+Author: Takuya Ishibashi / takuya at soum co jp
+
+Homepage: http://datafarm.apgrid.org/software/gfarmfs-fuse.en.html
+
+Description:
+
+  GfarmFS-FUSE enables you to mount a Gfarm filesystem in userspace.
+  Grid Datafarm is a Petascale data-intensive computing project
+  initiated in Japan. The challenge involves construction of a Peta-
+  to Exascale parallel filesystem exploiting local storages of PCs
+  spread over the world-wide Grid.
+
+==============================================================================

I really don't know what's the proper reaction -- laughing or crying -- for the idea of releasing all this boiling hackery on good old FreeBSD... ;) W00t!

Musings as of 8th of August, 2005

As you can see, I didn't put here anything since a while...

I wasn't musing anymore, I was reading code for getting a clue how to implement certain functionalities, I was coding and I spent lengthy debugging sessions to discover the trivial mistakes which caused mysterious panics.

However, recently I opened another wiki page under the name FuseFilesystem. I got a mail lacking a recent musing here. So there are people tracing this page! Neat. So this note is for them: go there, there is something to play with :)

I'd also like to tell about a recent finding. in this post to the Fuse devel list, Johan Rydberg refers to a doc on the fuse userspace/kernel interface he announced back in November of last year. However, that doc then somehow didn't really catch the eye of Miklós (although he made some technical comments), and it didn't become official. Maybe this time? The doc is cool, here is a direct link.

Musings as of 16th of August, 2005

Hey, now you can mount Fuse under FreeBSD! Though you can't yet do much more... See FUSEFS.

And to note, one controversy has been resolved: licensing. The following seems to be the sane licensing: LGPL for the userspace -- as that's Miklós' work -- and BSDL for the FreeBSD module -- as that's my work and we are in the BSD world. But... there is one thing by Miklós which I used: the header which defines the interface between the kernel and userspace. And that's GPL'd (as it's part of a Linux kernel module)...

I mailed to Miklós, and he agreed to release that file with a BSD+GPL dual license. Thanks Miki!

Musings as of 26th of August, 2005

filesystem is useable.

Musings as of 31th of August, 2005

Yes, it works. Now it features buffered I/O, that is, you can say it's "complete". Go and trash your box with it.

CategoryHomepage

CsabaHenk (last edited 2019-07-31T17:37:04+0000 by AlanSomers)