[request for inclusion] Filesystem in Userspace
Miklos Szeredi
Do you have any objections to merging FUSE in mainline kernel?
It's been in -mm for the 2.6.11 cycle, and the same code was released
a month ago as FUSE-2.2. So it should have received a fair amount of
testing, with no problems found so far.
The one originally merged into -mm already addressed all major issues
that people found (most importantly the OOM deadlock thing), and
though there were some minor changes in the interface since then, I
feel that the current kernel interface will stand up to the test of
time.
Thanks,
Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton
>
> Do you have any objections to merging FUSE in mainline kernel?
I was planning on sending FUSE into Linus in a week or two. That and
cpusets are the notable features which are 2.6.12 candidates.
- crashdump seems permanently not-quite-ready
- perfctr works fine, but is rather deadlocked because it is
similar-to-but-different-from ia64's perfmon, and might not be suitable
for ppc64 (although things have gone quiet on the latter front).
- nfsacl should be OK for 2.6.12 if Trond is OK with it.
- cachefs is a bit stuck because it's a ton of complex code and afs is
the only user of it. Wiring it up to NFS would help.
- dm multipath is OK for 2.6.12
- reiser4 is less clear. Once all the review comments have been addressed
and we start seeing a bit of vendor pull for it, maybe.
Christoph Hellwig
> Hi Andrew!
>
> Do you have any objections to merging FUSE in mainline kernel?
>
> It's been in -mm for the 2.6.11 cycle, and the same code was released
> a month ago as FUSE-2.2. So it should have received a fair amount of
> testing, with no problems found so far.
>
> The one originally merged into -mm already addressed all major issues
> that people found (most importantly the OOM deadlock thing), and
> though there were some minor changes in the interface since then, I
> feel that the current kernel interface will stand up to the test of
> time.
Please give me or some other filesystem person some time to look over
it, there were a few things that looked really fishy.
And apologies for not having time to look at it earlier, but I'm a little
bit too busy right now.
David Gibson
> Miklos Szeredi <mik...@szeredi.hu> wrote:
> >
> > Do you have any objections to merging FUSE in mainline kernel?
>
> I was planning on sending FUSE into Linus in a week or two. That and
> cpusets are the notable features which are 2.6.12 candidates.
>
> - crashdump seems permanently not-quite-ready
>
> - perfctr works fine, but is rather deadlocked because it is
> similar-to-but-different-from ia64's perfmon, and might not be suitable
> for ppc64 (although things have gone quiet on the latter front).
Not to mention that the ABI is still changing with each release...
> - nfsacl should be OK for 2.6.12 if Trond is OK with it.
>
> - cachefs is a bit stuck because it's a ton of complex code and afs is
> the only user of it. Wiring it up to NFS would help.
>
> - dm multipath is OK for 2.6.12
>
> - reiser4 is less clear. Once all the review comments have been addressed
> and we start seeing a bit of vendor pull for it, maybe.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist. NOT _the_ _other_ _way_
| _around_!
http://www.ozlabs.org/people/dgibson
Marcelo Tosatti
Hi,
On Wed, Mar 02, 2005 at 12:31:23PM -0800, Andrew Morton wrote:
> Miklos Szeredi <mik...@szeredi.hu> wrote:
> >
> > Do you have any objections to merging FUSE in mainline kernel?
>
> I was planning on sending FUSE into Linus in a week or two. That and
> cpusets are the notable features which are 2.6.12 candidates.
>
> - crashdump seems permanently not-quite-ready
>
> - perfctr works fine, but is rather deadlocked because it is
> similar-to-but-different-from ia64's perfmon, and might not be suitable
> for ppc64 (although things have gone quiet on the latter front).
I once asked Mikael about using PMC's from kernel-space, he told me it wouldnt
be too hard to make them usable via kernel-space through perfctr.
Is perfmon's API useable to kernel users?
That sounds like a good point in favour of a given implementation, no?
Miklos Szeredi
> >
> > It's been in -mm for the 2.6.11 cycle, and the same code was released
> > a month ago as FUSE-2.2. So it should have received a fair amount of
> > testing, with no problems found so far.
> >
> > The one originally merged into -mm already addressed all major issues
> > that people found (most importantly the OOM deadlock thing), and
> > though there were some minor changes in the interface since then, I
> > feel that the current kernel interface will stand up to the test of
> > time.
>
>
> Please give me or some other filesystem person some time to look over
> it, there were a few things that looked really fishy.
Please do. Although I think the most complex part of FUSE is the
device handling, which is not really "filesystem" code. The
filesystem part is mostly really straightforward.
Still the more people look at it, the better.
> And apologies for not having time to look at it earlier, but I'm a little
> bit too busy right now.
Take your time, I don't want to hurry merging into mainline, but
things went very quiet lately on the bug front.
Thanks,
Miklos
Mikael Pettersson
> Miklos Szeredi <mik...@szeredi.hu> wrote:
> >
> > Do you have any objections to merging FUSE in mainline kernel?
>
> I was planning on sending FUSE into Linus in a week or two. That and
> cpusets are the notable features which are 2.6.12 candidates.
>
> - crashdump seems permanently not-quite-ready
>
> - perfctr works fine, but is rather deadlocked because it is
> similar-to-but-different-from ia64's perfmon, and might not be suitable
> for ppc64 (although things have gone quiet on the latter front).
perfctr has one API update pending, and then the API should be
in it final-ish form. David Gibson at IBM has done a ppc64 port,
which is about ready to be merged, and someone else has just
started working on a mips port.
/Mikael
Andrew Morton
>
> Andrew Morton writes:
> > Miklos Szeredi <mik...@szeredi.hu> wrote:
> > >
> > > Do you have any objections to merging FUSE in mainline kernel?
> >
> > I was planning on sending FUSE into Linus in a week or two. That and
> > cpusets are the notable features which are 2.6.12 candidates.
> >
> > - crashdump seems permanently not-quite-ready
> >
> > - perfctr works fine, but is rather deadlocked because it is
> > similar-to-but-different-from ia64's perfmon, and might not be suitable
> > for ppc64 (although things have gone quiet on the latter front).
>
> perfctr has one API update pending, and then the API should be
> in it final-ish form. David Gibson at IBM has done a ppc64 port,
> which is about ready to be merged, and someone else has just
> started working on a mips port.
>
That sounds good. Where do we stand now with ia64? Do we just end up
agreeing to differ?
Anton Altaparmakov
> Miklos Szeredi <mik...@szeredi.hu> wrote:
> >
> > Do you have any objections to merging FUSE in mainline kernel?
>
> I was planning on sending FUSE into Linus in a week or two.
I would certainly vote for FUSE going in. Even if it has some bits that
could be improved the code works well. It has been in global use for
quite a while. We use it in a production environment on four servers and
over 650 workstations to provide a "magic symlink filesystem" (i.e.
symlink XYZ points to different place depending on which user looks at it)
and we have not experienced any problems. I have also done other testing
with a layering fs using fuse and that was very stable (but slower than
the symlink approach which is why we went for that).
FUSE may not be perfect but lets face it - which code is? And more
importantly a lot of code in the kernel is broken (for at least some
people) yet it is in the kernel and FUSE does work well...
Just my 2p.
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
Mikael Pettersson
> Mikael Pettersson <mi...@csd.uu.se> wrote:
> >
> > Andrew Morton writes:
> > > Miklos Szeredi <mik...@szeredi.hu> wrote:
> > > >
> > > > Do you have any objections to merging FUSE in mainline kernel?
> > >
> > > I was planning on sending FUSE into Linus in a week or two. That and
> > > cpusets are the notable features which are 2.6.12 candidates.
> > >
> > > - crashdump seems permanently not-quite-ready
> > >
> > > - perfctr works fine, but is rather deadlocked because it is
> > > similar-to-but-different-from ia64's perfmon, and might not be suitable
> > > for ppc64 (although things have gone quiet on the latter front).
> >
> > perfctr has one API update pending, and then the API should be
> > in it final-ish form. David Gibson at IBM has done a ppc64 port,
> > which is about ready to be merged, and someone else has just
> > started working on a mips port.
> >
>
> That sounds good. Where do we stand now with ia64? Do we just end up
> agreeing to differ?
I think so, yes.
The ia64 perfmon has some features perfctr doesn't have,
but my perfctr API changes will allow perfctr to grow its
feature list and adapt to HW changes without breaking the API.
Its unlikely that perfctr will ever implement everything
perfmon does, but multiplexing and overflow sample buffering
are two features that should be added at some point.
/Mikael
Andrew Morton
>
> > > perfctr has one API update pending, and then the API should be
> > > in it final-ish form. David Gibson at IBM has done a ppc64 port,
> > > which is about ready to be merged, and someone else has just
> > > started working on a mips port.
> > >
> >
> > That sounds good. Where do we stand now with ia64? Do we just end up
> > agreeing to differ?
>
> I think so, yes.
>
> The ia64 perfmon has some features perfctr doesn't have,
> but my perfctr API changes will allow perfctr to grow its
> feature list and adapt to HW changes without breaking the API.
> Its unlikely that perfctr will ever implement everything
> perfmon does, but multiplexing and overflow sample buffering
> are two features that should be added at some point.
Oh well, at least we tried. perfctr supports a lot of architectures and a
fair few people want it, so let's get this merged up.
Let's get the ppc64 port included too, just in case that forces
late-breaking API changes.
Kevin P. Fleming
> - cachefs is a bit stuck because it's a ton of complex code and afs is
> the only user of it. Wiring it up to NFS would help.
Yes, please! I have an application for CacheFS between an NFS client and
server (all Linux) very soon :-)