Coda File System

Coda kernel module supports ReiserFS (as of Linux 2.4.4)

From: Jan Harkes <>
Date: Mon, 14 May 2001 09:40:00 -0400
I just thought some people might like to know that as of Linux 2.4.4
the patches to support storing containerfiles in ReiserFS got accepted
and integrated into the mainstream kernel.

We are now able to handle container files in at least ext2fs, reiserfs,
and ramfs. Tmpfs, vfat, and others will not work, I don't know how much
interest there is for these, the changes shouldn't be that hard.

Here follows a somewhat more technical description of the changes,
mostly for other userspace FS implementations that are using the Coda
kernel module. Sorry guys, I broke your stuff ;)

Supporting container files in a ReiserFS file system involves keeping an
open filehandle around in the kernel module to correctly deal with the
fact that reiserfs journals it's metadata updates as soon as the
filehandle is closed.

The kernel module is using a new upcall (CODA_OPEN_BY_FD) to which venus
returns an open filedescriptor for the container file. Venus has had
support for this upcall since release 5.3.9 (released October 5th 2000),
so for most people the changes should be transparent. However UserFS
implementations that use the Coda kernel module (e.g. podfuk) are
probably broken by this change.

By passing down a filedescriptor instead of device/inode number pair it
is now possible to store containerfiles in filesystems that have an
anonymous blockdevice or are completely missing a usable iget
implementation (e.g. ramfs). Tmpfs and several other filesystems are
still not supported because we are still using generic_file_read/write
to access the underlying container files instead of fs-specific
operations. The required changes for this should be trivial, but I don't
know how much interest there is in supporting these.

Finally is also support for correctly passing errors back to userspace.
This required splitting up CODA_CLOSE into 2 new upcalls, CODA_STORE and

Errors can be returned as a result of the store upcall. However the
userspace object should only be destroyed after release has been
received as many times as a CODA_OPEN upcall was processed. The current
Coda userspace doesn't support these new upcalls yet, the kernel falls
back to using the old CODA_CLOSE upcall as soon as EOPNOTSUPP is returned.

Received on 2001-05-14 09:40:05