GSoC proposition: multiplatform UFS2 driver

[Richard Yao]

On Mar 13, 2014, at 6:32 PM, Richard Yao <ryao at gentoo.org> wrote:

> On 03/13/2014 06:29 PM, Richard Yao wrote:
>> On 03/13/2014 06:12 PM, Julio Merino wrote:
>>> On Fri, Mar 14, 2014 at 2:48 AM, Richard Yao <ryao at gentoo.org> wrote:
>>>> On 03/12/2014 12:54 PM, CeDeROM wrote:
>>>>> My proposition is to create universal UFS2 driver that would work on
>>>>> Windows, Linux, and maybe other OS, so we can use native UFS2 as data
>>>>> partition among various OS.
>>>> 
>>>> I like this idea. In particular, I would like to have UFS2 SU+J
>>>> available for use in certain Linux VMs and was thinking about this
>>>> possibility earlier in the week. However, I no longer qualify to be a
>>>> GSoC student and I do not have time to do it myself.
>>>> [...]
>>>> Speaking as a kernel filesystem hacker (with most of my experience in
>>>> Linux), I think this could be too ambitious depending on how you add
>>>> detail. In particular, Linux has a moving target of a VFS (which causes
>>>> much pain) and Windows' IFS is very different from the SunOS VFS that
>>>> has become the basis for implementing multiple filesystems on different
>>>> UNIX implementations and copy-cats.
>>> [...]
>>> 
>>> Something worth pointing out here: in NetBSD, and thanks to rump, you
>>> can already get the *verbatim* in-kernel code of UFS2 built on a
>>> variety of host platforms. You could very easily turn the existing
>>> file system code into a FUSE file-system for Linux, for example, or
>>> write the necessary shims to bundle the code into a kernel driver.
>> 
>> This would work, but I think it dramatically reduces the value of the
>> result.
>> 
>>> In other words and in my opinion: rewriting file system code from
>>> scratch is outside of the scope of GSoC, but writing the glue code for
>>> the above to happen doesn't sound too crazy. (The only problem may be
>>> if NetBSD's UFS2 driver is not compatible with FreeBSD's... but I
>>> believe they should be for the "basic stuff".)
>>> 
>>> Some links:
>>> 
>>> https://github.com/rumpkernel/buildrump.sh
>>> http://wiki.netbsd.org/rumpkernel/
>> 
>> There is no need to write the code from scratch. He would just need to
>> take the existing code and wrap it so that it builds as part of a kernel
>> module for other kernels. The only things that need to be written is
>> glue code for mapping *BSD interfaces to foreign ones. I do not think it
>> is much more complex than writing a FUSE filesystem driver, especially
>> given the existence of user-mode Linux. That would permit the filesystem
>> driver for Linux to be developed in userland on FreeBSD, much like a
>> FUSE driver. Once the wrapper is written, the things that need revision
>> to support other kernels should be rather clearly defined.
>> 
>> http://user-mode-linux.sourceforge.net/
>> 
>> That being said, I do not like the idea of using NetBSD's UFS2 code. It
>> lacks Soft-Updates, which I consider to make FreeBSD UFS2 second only to
>> ZFS in desirability.
> 
> Something worth pointing out here that I missed is that rump could be
> used to develop a port of FreeBSD UFS2 to NetBSD. ;)

After looking at Rump in more detail, I have to retract these statements. I think a variation of this suggestion where UFS2 SU+J is ported to Rump and Rump is used to port it to other operating systems would work marvelously.