Date: Thu, 16 Jun 2005 22:08:03 -0400 From: Allan Fields <bsd@afields.ca> To: jwd@freebsd.org, scottl@samsco.org, jspedron@club-internet.fr Cc: freebsd-fs@freebsd.org Subject: Summer of Code: Magic Links, FiST/vnode stacking?, ReiserFS Message-ID: <20050617020803.GC95979@afields.ca>
next in thread | raw e-mail | index | archive | help
--O5XBE6gyVG5Rl6Rj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 Reise= rFS to FreeBSD and much of the work on Reiser3 read-only support has alread= y 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 effor= ts to bring write support, time permitting. The next logical step would be to work on porting the Reiser4 journalling c= ode 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. Personal= ly, I think many of the problems w/ Reiser4 are over-rated and would be int= erested 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 minim= al 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, --=20 Allan Fields --O5XBE6gyVG5Rl6Rj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQFCsjCC90UNcjm0VUERAmR2AKCtiRUeG5ilwqn2uLP7UrvtUOV6cACfWzn4 b1fDLqBS+HcwH3zdMfH2OZU= =vuhz -----END PGP SIGNATURE----- --O5XBE6gyVG5Rl6Rj--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050617020803.GC95979>