From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 14 00:16:22 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 44998733; Fri, 14 Mar 2014 00:16:22 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 158E2211; Fri, 14 Mar 2014 00:16:21 +0000 (UTC) Received: from [192.168.1.157] (pool-173-52-87-124.nycmny.fios.verizon.net [173.52.87.124]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ryao) by smtp.gentoo.org (Postfix) with ESMTPSA id 8DE2133FCEE; Fri, 14 Mar 2014 00:16:20 +0000 (UTC) References: <5321EF7E.7000500@gentoo.org> <53223140.9030208@gentoo.org> <532231EA.5090601@gentoo.org> Mime-Version: 1.0 (1.0) In-Reply-To: <532231EA.5090601@gentoo.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (10B146) From: Richard Yao Subject: Re: GSoC proposition: multiplatform UFS2 driver Date: Thu, 13 Mar 2014 20:16:20 -0400 To: Julio Merino Cc: "freebsd-hackers@freebsd.org" , CeDeROM X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 00:16:22 -0000 On Mar 13, 2014, at 6:32 PM, Richard Yao 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 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.