Date: Thu, 13 Mar 2014 20:16:20 -0400 From: Richard Yao <ryao@gentoo.org> To: Julio Merino <jmmv@freebsd.org> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, CeDeROM <cederom@tlen.pl> Subject: Re: GSoC proposition: multiplatform UFS2 driver Message-ID: <C68CB76D-A1DA-48FF-A7E0-874F90A22788@gentoo.org> In-Reply-To: <532231EA.5090601@gentoo.org> References: <CAFYkXjm1fCQDSvHTHSpmAbLPqNz0kwaWf%2BajLdaoBD3bLnMDAA@mail.gmail.com> <5321EF7E.7000500@gentoo.org> <CAFY7cWCqTUmASq3vSiRGtoiUOg4Us--o-VOxEp5L5R7wNN%2B2tw@mail.gmail.com> <53223140.9030208@gentoo.org> <532231EA.5090601@gentoo.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 13, 2014, at 6:32 PM, Richard Yao <ryao@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@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. >>>>=20 >>>> 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. >>> [...] >>>=20 >>> 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. >>=20 >> This would work, but I think it dramatically reduces the value of the >> result. >>=20 >>> 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".) >>>=20 >>> Some links: >>>=20 >>> https://github.com/rumpkernel/buildrump.sh >>> http://wiki.netbsd.org/rumpkernel/ >>=20 >> 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. >>=20 >> http://user-mode-linux.sourceforge.net/ >>=20 >> 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. >=20 > 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 t= hink a variation of this suggestion where UFS2 SU+J is ported to Rump and Ru= mp is used to port it to other operating systems would work marvelously.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C68CB76D-A1DA-48FF-A7E0-874F90A22788>