Date: Wed, 13 Feb 2008 09:03:59 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no> Cc: Csaba Henk <csaba-ml@creo.hu>, freebsd-fs@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Remove NTFS kernel support Message-ID: <20080213085903.U13849@fledge.watson.org> In-Reply-To: <86d4r2540f.fsf@ds4.des.no> References: <3bbf2fe10802061700p253e68b8s704deb3e5e4ad086@mail.gmail.com> <70e8236f0802070321n9097d3fy1b39f637b3c2a06@mail.gmail.com> <slrnfqrp6g.i6j.csaba-ml@beastie.creo.hu> <867ihdc34c.fsf@ds4.des.no> <20080212190207.GB49155@beastie.creo.hu> <86d4r2540f.fsf@ds4.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 12 Feb 2008, Dag-Erling Smørgrav wrote: > Csaba Henk <csaba-ml@creo.hu> writes: >> Dag-Erling Smørgrav <des@des.no> writes: >>> How much work would you guess it would take to reimplement the >>> userland part under a BSD license? >> Well, I just started to work on a from scratch FUSE daemon library. [...] >> So I think: fuse4bsd (ie, the kld + the mount util) + libfolly + sysctl fs >> could go to base under BSD license. It also might make sense to rebase >> ntfs-3g atop of folly -- although it won't help ntfs-3g being GPL'd. > > That doesn't matter; ntfs-3g can still be a port. > > What does matter is that if libfolly exports the same API as libfuse, we can > have a complete BSD-licensed FUSE implementation in the base system, with > minimal effort required to port FUSE-based file systems. Has there been any work to add more mature interfaces to fuse over the last couple of years? When I looked at it previously, and that was a year or two ago, fuse didn't work well with our notion of "referenced" vs. "open" vnodes, and required explicit data copies from cache files into the kernel to be exposed via fuse. These are both areas where nnpfs, the userspace file system framework for Arla, does much better, as they offer improved handling of memory mapping (which persists after file descriptor close(), as in execve() and with shared libraries) and performance (no need to feed data for files to the kernel, you can just point the kernel at a persistent cache file, possibly cached from a previous session, allowing normal faulting of cache data into memory rather than requiring that pages pass through user space). My understanding is that the NetBSD user space fs work offers a more mature back-end interface than fuse, but allows the less complex fuse API to be used, but I've not done any detailed reading. These are areas where I assumed that over time we'd see functional improvements in fuse, so I guess I'm wondering if that has happened? Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080213085903.U13849>