Summer of Code: Magic Links, FiST/vnode stacking?, ReiserFS

[Allan Fields]

Hi,

The deadline seems to have already passed, so I don't know if it's
too late for Summer of Code stuff. But thought I'd bring it up
anyway..

I have an interest in some of the tasks posted for the Summer of
Code.  I might have an interest in magic links implementation under
FreeBSD.

I've been experimenting with file systems for a while now and did
a presentation at BSDCan 2004 about the VFS, vnode stacking and
FiST.  Though I didn't yet finish my FiST porting efforts, I still
have an interest in these areas of the kernel, this might be an
opportunity to get more involved in file systems again.


* ReiserFS Port:

There has been some interest previously expressed in seeing a port of ReiserFS to FreeBSD and much of the work on Reiser3 read-only support has already been done in the ReiserFS for BSD port [http://www.dumbbell.fr ] by Jean-Sebastion Pedron.  Jean has indicated he wouldn't mind continuing his efforts to bring write support, time permitting.

The next logical step would be to work on porting the Reiser4 journalling code which is a large amount of code.  This would be a port of the "dancing tree"/B-Tree+ algorithms and associated code [http://namesys.com ] and I'm not sure if I'm just echoing a previous suggestion to do as much.  Personally, I think many of the problems w/ Reiser4 are over-rated and would be interested in at least evaluating Reiser4 as a workable alternative.


* Fix unionfs/nullfs bugs:

This is one that came up at BSDCan numerous times and has been
posted to the lists.  An example usage is for jails where it
would be helpful to rely on these.


* FiST / vnode stacking (Coordinating w/ Erez Zadok?):

This is one I wanted to see move forward on *BSD.  What FiST offers
is a unified approach for template file systems which can aid in
cross-platform development of filesystem code (potentially) saving
a significant amount of developer effort and duplication.  It's
been around for a number of years now and FreeBSD templates do
exist.  The Size-Changing Algorithm (SCA) code is Linux specific,
so I'm not certain of the status.

Areas left to address: FreeBSD Templates (remaining build issues,
keep templates up to date, etc.), SCA: Size-Changing-Algorithm (some
work on this internally w/ the Stony Brook team?), Cache Coherency
issues, etc.

[http://www.fsl.cs.sunysb.edu , http://www.filesystems.org ]

Desirable/Related File System Ports: ncryptfs and/or ecryptfs,
gzipfs, unionfs


* Magic Links (+ generally enhanced file system semantics):

First of all a question: why Magic Links, and why now?  Has there
been a demand for them?

I have some interest in this specific area, and discussed implementation
details with the original DragonFly authors a few years back..
I've also heard some people who are dead opposed to these types of
links.

On the conservative side: semantics should be kept as clean as possible,
some have called this type of thing "featurism".  I think most BSD
folks would agree we don't want to see special-case logic in the mainstream
kernel if at all possible.  Though the amount of code touched here is minimal
and it's a question if this is really a "special case" or not.

On the more liberal side: next generation semantics are just waiting
to be brought into the Unix world and leaders who are pushing the
trend include Linux vendors and Apple.

I would actually like to see a superset of what is proposed here
to bring a whole new layer of enhanced file system semantics to *BSD
in a clean way.  Generally, can this concept be expanded to include
enhanced semantics for symbolic links such as unbreakable links,
etc.?  There are a whole set of variations on this theme and
combinations of primitives when dynamic targets are applied to a
link, the key is how to make it useful and the least disruptive to
the existing file system model.

I understand it would be nice to start off with some simple, easy
to implement features and go from there, but I see a whole area of
semantics that remains to be addressed in Unix.

More on this in the future perhaps...
[snip]

Thanks,
-- 
Allan Fields
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20050616/d0e6f54f/attachment.bin