Re: [Request for inclusion] Filesystem in Userspace

Re: [Request for inclusion] Filesystem in Userspace

[Jan Engelhardt]

>Unless, of course, by "polluted" you mean that output of "cat
>/proc/self/mounts" becomes longer.

Precisely that. I recall there once was "you're exceeding the maximum number of
filesystems" or such, has that "bug"/"non-feature" been lifted?



Jan Engelhardt
-- 
Gesellschaft für Wissenschaftliche Datenverarbeitung
Am Fassberg, 37077 Göttingen, www.gwdg.de

Re: [Request for inclusion] Filesystem in Userspace

[Mike Waychison]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jan Engelhardt wrote:
>>Unless, of course, by "polluted" you mean that output of "cat
>>/proc/self/mounts" becomes longer.
> 
> 
> Precisely that. I recall there once was "you're exceeding the maximum number of
> filesystems" or such, has that "bug"/"non-feature" been lifted?
> 

Two issues are resolved in current 2.6:

  - /proc/mounts used to be limitted to a page of data, fixed mid 2.4
  - there used to be a limit of pseudo-block backed filesystems in a
system, which was fixed by distros by using multiple majors, fixed
properly in 2.6.4-rc1


- --
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  The opinions expressed in this email are held by me,
and may not represent the views of Sun Microsystems, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBm616dQs4kOxk3/MRAgmbAJ9M9h6/Jp94h9cAr3u167CFLSa/5QCfYng3
w6QNoKtus1zExR7pRXXhVqQ=
=23z1
-----END PGP SIGNATURE-----

[request for inclusion] Filesystem in Userspace

[Miklos Szeredi]

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.

Thanks,
Miklos

Re: [request for inclusion] Filesystem in Userspace

[Andrew Morton]

Miklos Szeredi <miklos@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).

- 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.

Re: [request for inclusion] Filesystem in Userspace

[Marcelo Tosatti]

Hi, 

On Wed, Mar 02, 2005 at 12:31:23PM -0800, Andrew Morton wrote:
> Miklos Szeredi <miklos@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?

Re: [request for inclusion] Filesystem in Userspace

[Christoph Hellwig]

On Wed, Mar 02, 2005 at 07:17:13PM +0100, Miklos Szeredi wrote:
> 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.

Re: [request for inclusion] Filesystem in Userspace

[David Gibson]

On Wed, Mar 02, 2005 at 12:31:23PM -0800, Andrew Morton wrote:
> Miklos Szeredi <miklos@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

Re: [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.
> 
> 
> 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

Re: [request for inclusion] Filesystem in Userspace

[Mikael Pettersson]

Andrew Morton writes:
 > Miklos Szeredi <miklos@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

Re: [request for inclusion] Filesystem in Userspace

[Andrew Morton]

Mikael Pettersson <mikpe@csd.uu.se> wrote:
>
> Andrew Morton writes:
>  > Miklos Szeredi <miklos@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?

Re: [request for inclusion] Filesystem in Userspace

[Anton Altaparmakov]

On Wed, 2 Mar 2005, Andrew Morton wrote:
> Miklos Szeredi <miklos@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/

Re: [request for inclusion] Filesystem in Userspace

[Mikael Pettersson]

Andrew Morton writes:
 > Mikael Pettersson <mikpe@csd.uu.se> wrote:
 > >
 > > Andrew Morton writes:
 > >  > Miklos Szeredi <miklos@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

Re: [request for inclusion] Filesystem in Userspace

[Andrew Morton]

Mikael Pettersson <mikpe@csd.uu.se> wrote:
>
>  > > 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.

Re: [request for inclusion] Filesystem in Userspace

[Kevin P. Fleming]

Andrew Morton wrote:

> - 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 :-)