2.4 vs 2.6

2.4 vs 2.6

[Vijay Chauhan]

[-- Attachment #1: Type: text/plain, Size: 146 bytes --]

Hi,
Can anyone tell me what are the differences in the linux kernel 2.4 version
and 2.6 version related to NFS implementation

TIA,

Vijay

[-- Attachment #2: Type: text/html, Size: 231 bytes --]

Re: 2.4 vs 2.6

[Neil Brown]

On Thursday May 25, kernel.vijay@gmail.com wrote:
> Hi,
> Can anyone tell me what are the differences in the linux kernel 2.4 version
> and 2.6 version related to NFS implementation

How much detail do you want?

Apart from adding NFSv4, the main difference is the authentication
cache with support for up-calls.
In 2.4, exportfs and mountd had to tell the kernel about any export
information that it might need to know.
In 2.6, the kernel can ask mountd, and mountd will provide information
on-demand.

NeilBrown


-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: 2.4 vs 2.6

[Neil Brown]

On Friday May 26, neilb@suse.de wrote:
> On Thursday May 25, kernel.vijay@gmail.com wrote:
> > Hi,
> > Can anyone tell me what are the differences in the linux kernel 2.4 version
> > and 2.6 version related to NFS implementation
> 
> How much detail do you want?
> 
> Apart from adding NFSv4, the main difference is the authentication
> cache with support for up-calls.
> In 2.4, exportfs and mountd had to tell the kernel about any export
> information that it might need to know.
> In 2.6, the kernel can ask mountd, and mountd will provide information
> on-demand.
> 
> NeilBrown

Ofcourse, that is just the server.  There have been lots of changes to
the client as well including RPCSEC support and much much more.

What exactly do you need to know?

NeilBrown


-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: 2.4 vs 2.6

[mehta kiran]

Hi,

1. I noticed that 2.6 kernel is not aware of=20
   exportfs until client tries to mount. It only
   after this that proc nfsd filesystem shows this
   in list of exports due to upcall.
   Was 2.4 kernel aware of exportfs when the
   filesystem was first exported or mounted ?

2. Can you let me know advantage 2.6 export approach
   over 2.4 export approach ?=20
   Is this approach required due to=20
   security/authentication integration with NFS(say=20
   ip->name conversion for security ) ?

Thanks,
 kiran

--- Neil Brown <neilb@suse.de> wrote:

> On Thursday May 25, kernel.vijay@gmail.com wrote:
> > Hi,
> > Can anyone tell me what are the differences in the
> linux kernel 2.4 version
> > and 2.6 version related to NFS implementation
>=20
> How much detail do you want?
>=20
> Apart from adding NFSv4, the main difference is the
> authentication
> cache with support for up-calls.
> In 2.4, exportfs and mountd had to tell the kernel
> about any export
> information that it might need to know.
> In 2.6, the kernel can ask mountd, and mountd will
> provide information
> on-demand.
>=20
> NeilBrown
>=20
>=20
>
-------------------------------------------------------
> All the advantages of Linux Managed Hosting--Without
> the Cost and Risk!
> Fully trained technicians. The highest number of Red
> Hat certifications in
> the hosting industry. Fanatical Support. Click to
> learn more
>
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D107521&bid=3D248729&dat=3D=
121642
> _______________________________________________
> NFS maillist  -  NFS@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs
>=20


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around=20
http://mail.yahoo.com=20


-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications i=
n
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D107521&bid=3D248729&dat=3D=
121642
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: 2.4 vs 2.6

[J. Bruce Fields]

On Fri, May 26, 2006 at 01:19:05AM -0700, mehta kiran wrote:
> Hi,
> 
> 1. I noticed that 2.6 kernel is not aware of 
>    exportfs until client tries to mount. It only
>    after this that proc nfsd filesystem shows this
>    in list of exports due to upcall.
>    Was 2.4 kernel aware of exportfs when the
>    filesystem was first exported or mounted ?
> 
> 2. Can you let me know advantage 2.6 export approach
>    over 2.4 export approach ? 
>    Is this approach required due to 
>    security/authentication integration with NFS(say 
>    ip->name conversion for security ) ?

The kernel has to know whether an incoming IP address matches, say,
"*.umich.edu."  But we don't want to add an entire DNS client
implementation to the kernel.  And we also can't preload the kernel with
every possible IP address that might match *.umich.edu.  So we allow
the kernel to ask mountd for that information when it needs it.

This isn't actually necessary for an NFSv2/v3 server, because mountd
always gets a "mount" request from any client before the kernel gets any
NFS requests from that client, so mountd can tell the kernel about the
new client then.

But NFSv4 clients don't contact mountd first.  Neither do v2/v3 clients
that are failing over from another server.  So you need the upcalls to
handle those cases.

That justifies the auth_unix_ip upcall, anyway; I'm less sure about the
others.

--b.


-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: 2.4 vs 2.6

[Neil Brown]

On Friday May 26, bfields@fieldses.org wrote:
> On Fri, May 26, 2006 at 01:19:05AM -0700, mehta kiran wrote:
> > Hi,
> > 
> > 1. I noticed that 2.6 kernel is not aware of 
> >    exportfs until client tries to mount. It only
> >    after this that proc nfsd filesystem shows this
> >    in list of exports due to upcall.
> >    Was 2.4 kernel aware of exportfs when the
> >    filesystem was first exported or mounted ?
> > 
> > 2. Can you let me know advantage 2.6 export approach
> >    over 2.4 export approach ? 
> >    Is this approach required due to 
> >    security/authentication integration with NFS(say 
> >    ip->name conversion for security ) ?
> 
> The kernel has to know whether an incoming IP address matches, say,
> "*.umich.edu."  But we don't want to add an entire DNS client
> implementation to the kernel.  And we also can't preload the kernel with
> every possible IP address that might match *.umich.edu.  So we allow
> the kernel to ask mountd for that information when it needs it.
> 
> This isn't actually necessary for an NFSv2/v3 server, because mountd
> always gets a "mount" request from any client before the kernel gets any
> NFS requests from that client, so mountd can tell the kernel about the
> new client then.

Not exactly necessary, but without it we depend on 'rmtab' to record
which clients have the filesystem mounted across a server reboot, and
it is not possible to maintain an rmtab file reliably.

> 
> But NFSv4 clients don't contact mountd first.  Neither do v2/v3 clients
> that are failing over from another server.  So you need the upcalls to
> handle those cases.
> 
> That justifies the auth_unix_ip upcall, anyway; I'm less sure about the
> others.

The nfsd.fh upcall - which maps a file-handle-fragment to a directory -
can be used to implementing on-demand loading of filesystems,
e.g. CDroms from a CD library.  We don't actually do that now, but we
could.
It also means that if a filesystem isn't currently being used by a
client, (where 'currently' means in the last 30 minutes I think), then
you can unmount it without having to unexport it.  This is (arguably?)
a good thing.

nfsd.export is needed because once auth.unix.ip and nfsd.fh have
provided their information - it combines the two together to get
export options.

auth.domain was a mistake that is gone in recent kernels.

That leaves nfs4.nametoid and nfs4.idtoname.  I'm sure they do
something useful.... :-)

Hope that completes the clarification.

NeilBrown


-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: 2.4 vs 2.6

[mehta kiran]

--- Neil Brown <neilb@suse.de> wrote:

> On Friday May 26, bfields@fieldses.org wrote:
> > On Fri, May 26, 2006 at 01:19:05AM -0700, mehta
> kiran wrote:
> > > Hi,
> > >=20
> > > 1. I noticed that 2.6 kernel is not aware of=20
> > >    exportfs until client tries to mount. It only
> > >    after this that proc nfsd filesystem shows
> this
> > >    in list of exports due to upcall.
> > >    Was 2.4 kernel aware of exportfs when the
> > >    filesystem was first exported or mounted ?
> > >=20
> > > 2. Can you let me know advantage 2.6 export
> approach
> > >    over 2.4 export approach ?=20
> > >    Is this approach required due to=20
> > >    security/authentication integration with
> NFS(say=20
> > >    ip->name conversion for security ) ?
> >=20
> > The kernel has to know whether an incoming IP
> address matches, say,
> > "*.umich.edu."  But we don't want to add an entire
> DNS client
> > implementation to the kernel.  And we also can't
> preload the kernel with
> > every possible IP address that might match
> *.umich.edu.  So we allow
> > the kernel to ask mountd for that information when
> it needs it.
> >=20
> > This isn't actually necessary for an NFSv2/v3
> server, because mountd
> > always gets a "mount" request from any client
> before the kernel gets any
> > NFS requests from that client, so mountd can tell
> the kernel about the
> > new client then.
>=20
> Not exactly necessary, but without it we depend on
> 'rmtab' to record
> which clients have the filesystem mounted across a
> server reboot, and
> it is not possible to maintain an rmtab file
> reliably.
>=20
> >=20
> > But NFSv4 clients don't contact mountd first.=20
> Neither do v2/v3 clients
> > that are failing over from another server.  So you
> need the upcalls to
> > handle those cases.
> >=20
> > That justifies the auth_unix_ip upcall, anyway;
> I'm less sure about the
> > others.
>=20
> The nfsd.fh upcall - which maps a
> file-handle-fragment to a directory -
> can be used to implementing on-demand loading of
> filesystems,
> e.g. CDroms from a CD library.  We don't actually do
> that now, but we
> could.
> It also means that if a filesystem isn't currently
> being used by a
> client, (where 'currently' means in the last 30
> minutes I think), then
> you can unmount it without having to unexport it.=20
> This is (arguably?)
KM>
1.I tried this but got to know that exported   =20
  filesystem may not be umounted cleanly when client
  has mounted that fs atleast once in past.
  Is this expected ? Looks like kernel
  holds reference to exported fs
2.Just a thought ....
  Consider a case where server exports a filesystem
  (and nobody mounts it for long time)=20
  and due to inactivity on it for some time, it
  umounts the filesystem. Now if some new client
  tries to mount it, it may access some data(data on=20
  mount point) which server  may not have exported,=20
  right ?



> a good thing.
>=20
> nfsd.export is needed because once auth.unix.ip and
> nfsd.fh have
> provided their information - it combines the two
> together to get
> export options.
>=20
> auth.domain was a mistake that is gone in recent
> kernels.
>=20
> That leaves nfs4.nametoid and nfs4.idtoname.  I'm
> sure they do
> something useful.... :-)
>=20
> Hope that completes the clarification.
>=20
> NeilBrown
>=20


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around=20
http://mail.yahoo.com=20


-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications i=
n
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D107521&bid=3D248729&dat=3D=
121642
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: 2.4 vs 2.6

[J. Bruce Fields]

On Mon, May 29, 2006 at 03:55:19PM +1000, Neil Brown wrote:
> Not exactly necessary, but without it we depend on 'rmtab' to record
> which clients have the filesystem mounted across a server reboot, and
> it is not possible to maintain an rmtab file reliably.

Oh, right.  Hm.  I don't actually understand exactly what the obstacles
are to maintaining it reliably, though intuitively it's easy to believe
that it's impossible.  Is the problem just clients that die and never
come back, or are there inherent race coditions updating the rmtab on
unmount?

> nfsd.export is needed because once auth.unix.ip and nfsd.fh have
> provided their information - it combines the two together to get
> export options.

I don't see why this *has* to be done on demand, though, unless the
export table is extremely large and only sparsely used.  I might be
missing something.

> That leaves nfs4.nametoid and nfs4.idtoname.  I'm sure they do
> something useful.... :-)

On good days....

--b.


-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: 2.4 vs 2.6

[Greg Banks]

On Mon, May 29, 2006 at 12:02:36PM -0400, J. Bruce Fields wrote:
> On Mon, May 29, 2006 at 03:55:19PM +1000, Neil Brown wrote:
> > Not exactly necessary, but without it we depend on 'rmtab' to record
> > which clients have the filesystem mounted across a server reboot, and
> > it is not possible to maintain an rmtab file reliably.
> 
> Oh, right.  Hm.  I don't actually understand exactly what the obstacles
> are to maintaining it reliably, though intuitively it's easy to believe
> that it's impossible.  Is the problem just clients that die and never
> come back, or are there inherent race coditions updating the rmtab on
> unmount?

Clients can also ignore network errors when they unmount, or do
some kind of forced unmount which doesn't send an RPC to mountd.
Because clients still work regardless of whether the serverside state
is cleaned up, umount is effectively optional.

So rmtab is not only unreliable but tends to accumulate cruft.  I've
seen reports of rmtab growing to over 500 megabytes (admittedly not
on a Linux box, but the principle is the same).

> > nfsd.export is needed because once auth.unix.ip and nfsd.fh have
> > provided their information - it combines the two together to get
> > export options.
> 
> I don't see why this *has* to be done on demand, though, unless the
> export table is extremely large and only sparsely used.  I might be
> missing something.

/mnt/data *.domain1.company.com(ro,sync) *.domain2.company.com(rw,sync)

Also, ISTR that the combination of the nohide export option and
a client wildcard didn't work properly in 2.4 and the kernel upcall
to mountd in 2.6 fixed that.

Greg.
-- 
Greg Banks, R&D Software Engineer, SGI Australian Software Group.
I don't speak for SGI.


-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: 2.4 vs 2.6

[J. Bruce Fields]

On Tue, May 30, 2006 at 11:12:08AM +1000, Greg Banks wrote:
> On Mon, May 29, 2006 at 12:02:36PM -0400, J. Bruce Fields wrote:
> > I don't see why this *has* to be done on demand, though, unless the
> > export table is extremely large and only sparsely used.  I might be
> > missing something.
> 
> /mnt/data *.domain1.company.com(ro,sync) *.domain2.company.com(rw,sync)

I realize that the ip->client-name mapping is too large to preload into
the kernel.

It's the (path, client-name) --> export options that I wonder about.

--b.


-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: 2.4 vs 2.6

[Neil Brown]

On Monday May 29, bfields@fieldses.org wrote:
> On Tue, May 30, 2006 at 11:12:08AM +1000, Greg Banks wrote:
> > On Mon, May 29, 2006 at 12:02:36PM -0400, J. Bruce Fields wrote:
> > > I don't see why this *has* to be done on demand, though, unless the
> > > export table is extremely large and only sparsely used.  I might be
> > > missing something.
> > 
> > /mnt/data *.domain1.company.com(ro,sync) *.domain2.company.com(rw,sync)
> 
> I realize that the ip->client-name mapping is too large to preload into
> the kernel.
> 
> It's the (path, client-name) --> export options that I wonder about.

Having the mapping permanently in the kernel rather than filled in on
demand would mean that:

 - the filesystem has to be mounted the whole time, and we cannot do
   any on-demand mounting (based on fsid) - not that we currently do.
   This is a fairly small point however.
 - the client-names would need to be known in advance.  It seems
   obvious that they would be, but they aren't.
   What do you do if you get a request from an IP address that matches
   several of the tags in /etc/exports ? e.g.
      /export1 @somehosts(rw,root_squash)
      /export2 @otherhosts(ro,no_root_squash)

   If a request arrives from a host which is in both 'somehosts' and
   'otherhosts', then what name do you give to the kernel for that IP
   address?
   We currently say the IP address maps to 
          @somehosts+@otherhosts
   (or something like that) and then tell the kernel any of the
   following as required:
          /export1 @somehosts+@otherhosts  -> rw,root_squash
          /export1 @somehosts  -> rw,root_squash
          /export2 @somehosts+@otherhosts  -> ro,no_root_squash
          /export2 @otherhosts  -> ro,no_root_squash
          
Hopefully you can see that giving a full (path, client-name ) ->
export mapping the kernel in advance is not practical.

NeilBrown


_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: 2.4 vs 2.6

[J. Bruce Fields]

On Tue, Jun 13, 2006 at 01:29:42PM +1000, Neil Brown wrote:
> Having the mapping permanently in the kernel rather than filled in on
> demand would mean that:
> 
>  - the filesystem has to be mounted the whole time, and we cannot do
>    any on-demand mounting (based on fsid) - not that we currently do.
>    This is a fairly small point however.

Fair enough.

>    If a request arrives from a host which is in both 'somehosts' and
>    'otherhosts', then what name do you give to the kernel for that IP
>    address?
>    We currently say the IP address maps to 
>           @somehosts+@otherhosts
>    (or something like that) and then tell the kernel any of the
>    following as required:
>           /export1 @somehosts+@otherhosts  -> rw,root_squash
>           /export1 @somehosts  -> rw,root_squash
>           /export2 @somehosts+@otherhosts  -> ro,no_root_squash
>           /export2 @otherhosts  -> ro,no_root_squash

The kernel could of course just split these plus+separated+name+lists
itself before mapping to export options.  But I guess the point is that
in cases such as the above there's a policy decision that's better made
in userspace.  OK.

> Hopefully you can see that giving a full (path, client-name ) ->
> export mapping the kernel in advance is not practical.

Just to be clear--I'm definitely not on some crusade to change all this.
I'm just curious about the motivation for the design; thanks for the
explanation.

--b.


_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: 2.4 vs 2.6

[Neil Brown]

On Tuesday June 13, bfields@fieldses.org wrote:
> 
> Just to be clear--I'm definitely not on some crusade to change all this.
> I'm just curious about the motivation for the design; thanks for the
> explanation.

Not the caped crusader then :-)

Oh! you wanted the motivation?  I thought you wanted the justification!
Completely different things you know.....

The motivation was that I needed to do upcalls to remove the rmtab
problem, so it seemed 'obvious' to use upcalls for everything and
create a caching structure that could be use generally.  I cannot say
that I considered every cache and asked myself if it could be static
or not.  Had I thought more fully about such things I might not have
included the 'client' in the key for the fh -> path mapping.  But it
seemed like the right idea at the time, and I didn't have anyone
questioning my design decisions.  Looking back, I wish I had!


NeilBrown


_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: 2.4 vs 2.6

[Greg Banks]

On Wed, 2006-06-14 at 06:42, J. Bruce Fields wrote:
> On Tue, Jun 13, 2006 at 01:29:42PM +1000, Neil Brown wrote:
> >    If a request arrives from a host which is in both 'somehosts' and
> >    'otherhosts', then what name do you give to the kernel for that IP
> >    address?
> >    We currently say the IP address maps to 
> >           @somehosts+@otherhosts
> >    (or something like that) and then tell the kernel any of the
> >    following as required:
> >           /export1 @somehosts+@otherhosts  -> rw,root_squash
> >           /export1 @somehosts  -> rw,root_squash
> >           /export2 @somehosts+@otherhosts  -> ro,no_root_squash
> >           /export2 @otherhosts  -> ro,no_root_squash
> 
> The kernel could of course just split these plus+separated+name+lists
> itself before mapping to export options.  But I guess the point is that
> in cases such as the above there's a policy decision that's better made
> in userspace.  OK.

There are a couple more considerations.

First, the list of IP addresses to which a netgroup maps can be
quite large; we've seen problems on customer sites which had
netgroups with over 8K entries.  Getting this amount of data
into the kernel in an exportfs operation is problematical.

Second, the membership of a netgroup can be controlled on a NIS
server and so can vary behind the kernel's back, so that the list
of addresses in the kernel becomes stale.  Of course this is both
most likely to happen and most painful with the same customers who
have the enormous netgroups.

Both of these mean that enumerating netgroups and shoving the
results into the kernel isn't practical.   The only real solution
here is to do a NIS query in userspace on mount.  Thanks to NFSv3's
mythical "statelessness" this really means on first NFS call from
a new host.  Hence you need an upcall.

There are only two criticisms I would make of Linux' upcall design.

First, Linux uses a wacky special-purpose filesystem.  Solaris and
IRIX use a normal RPC to a special RPC program number implemented
in mountd, using the existing RPC client code which is already needed
in the server to initiate lockd callbacks.  This reduces code
complexity in the kernel, and means you can watch the upcall traffic
with wireshark (or whatever ethereal is called this week) or snoop
instead of strace on mountd.  But whatever, it mostly works now.

Second, rpc.mountd is single-threaded, and needs to do a blocking
reverse hostname lookup on every mount and needs to respond to at
least one upcall shortly afterward.  When you have a thousand
compute cluster nodes all trying to mount in the same second, this
gets to be something of a problem.

Greg.
-- 
Greg Banks, R&D Software Engineer, SGI Australian Software Group.
I don't speak for SGI.




_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: 2.4 vs 2.6

[J. Bruce Fields]

On Wed, Jun 14, 2006 at 11:29:31AM +1000, Greg Banks wrote:
> There are a couple more considerations.
> 
> First, the list of IP addresses to which a netgroup maps can be
> quite large

Yeah, it's obvious why we need the ip address->netgroup mapping; it's
the netgroup->export options that I was interested in.

> Second, rpc.mountd is single-threaded, and needs to do a blocking
> reverse hostname lookup on every mount and needs to respond to at
> least one upcall shortly afterward.  When you have a thousand
> compute cluster nodes all trying to mount in the same second, this
> gets to be something of a problem.

This should be trivially fixable, shouldn't it?  (Actually, can you run
multiple concurrent mountd's right now?)

--b.


_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: 2.4 vs 2.6

[Greg Banks]

On Wed, 2006-06-14 at 12:15, J. Bruce Fields wrote:
> On Wed, Jun 14, 2006 at 11:29:31AM +1000, Greg Banks wrote:

> This should be trivially fixable, shouldn't it?  (Actually, can you run
> multiple concurrent mountd's right now?)

I believe the kernel cache could can handle multiple readers
and writers (Neil?)  but there's only one portmap registration,
so all the client RPCs will go to the last mountd started.

Greg.
-- 
Greg Banks, R&D Software Engineer, SGI Australian Software Group.
I don't speak for SGI.




_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: 2.4 vs 2.6

[Neil Brown]

On Wednesday June 14, gnb@melbourne.sgi.com wrote:
> On Wed, 2006-06-14 at 12:15, J. Bruce Fields wrote:
> > On Wed, Jun 14, 2006 at 11:29:31AM +1000, Greg Banks wrote:
> 
> > This should be trivially fixable, shouldn't it?  (Actually, can you run
> > multiple concurrent mountd's right now?)
> 
> I believe the kernel cache could can handle multiple readers
> and writers (Neil?)  but there's only one portmap registration,
> so all the client RPCs will go to the last mountd started.

Yes, the kernel caches can handle multiple reader/writers quite
transparently.

As rpc service is fairly stateless, it should be possible to get
mountd to fork N times after registering the service and before
entering the loop.  All of the state of significance lives in files or
in the kernel, and the file access is already done with locking, so it
should "just work" - though some review and testing would not go
astray of course.

Did we have a volunteer :-)

NeilBrown


_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: 2.4 vs 2.6

[Greg Banks]

On Wed, 2006-06-14 at 14:18, Neil Brown wrote:
> On Wednesday June 14, gnb@melbourne.sgi.com wrote:
> > On Wed, 2006-06-14 at 12:15, J. Bruce Fields wrote:
> > > On Wed, Jun 14, 2006 at 11:29:31AM +1000, Greg Banks wrote:
> > 
> > > This should be trivially fixable, shouldn't it?  (Actually, can you run
> > > multiple concurrent mountd's right now?)
> > 
> > I believe the kernel cache could can handle multiple readers
> > and writers (Neil?)  but there's only one portmap registration,
> > so all the client RPCs will go to the last mountd started.
> 
> Yes, the kernel caches can handle multiple reader/writers quite
> transparently.
> 
> As rpc service is fairly stateless, it should be possible to get
> mountd to fork N times after registering the service and before
> entering the loop.

Sounds relatively simple, assuming libc's svc_* code is fork-safe.

>   All of the state of significance lives in files or
> in the kernel, and the file access is already done with locking, so it
> should "just work" - though some review and testing would not go
> astray of course.
> 
> Did we have a volunteer :-)

I have this terrible feeling that you do ;-)

Greg.
-- 
Greg Banks, R&D Software Engineer, SGI Australian Software Group.
I don't speak for SGI.




_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

multiple mountds (was: 2.4 vs 2.6)

[Greg Banks]

[-- Attachment #1: Type: text/plain, Size: 1906 bytes --]

On Wed, 2006-06-14 at 14:36, Greg Banks wrote:
> On Wed, 2006-06-14 at 14:18, Neil Brown wrote:
> > As rpc service is fairly stateless, it should be possible to get
> > mountd to fork N times after registering the service and before
> > entering the loop.
> 
> Sounds relatively simple, assuming libc's svc_* code is fork-safe.
> 
> >   All of the state of significance lives in files or
> > in the kernel, and the file access is already done with locking, so it
> > should "just work" - though some review and testing would not go
> > astray of course.
> > 
> > Did we have a volunteer :-)
> 
> I have this terrible feeling that you do ;-)

How about the attached patch against nfs-utils tot?  It
adds a -t option to set the number of forked workers.
Default is 1 thread, i.e. the old behaviour.

I've verified that showmount -e, the Ogata mount client,
and a real mount from Linux and IRIX boxes work with and
without the new option.

I've verified that you can manually kill any of the workers
without the portmap registration going away, that killing
all the workers causes the manager process to wake up and
unregister, and killing the manager process causes the
workers to be killed and portmap unregistered.

I've verified that all the workers have file descriptors
for the udp socket and the tcp rendezvous socket, that
connections are balanced across all the workers if service
times are sufficiently long, and that performance is 
improved by that parallelism, at least for small numbers
of threads.  For example, with 60 parallel MOUNT calls
and a testing patch to make DNS lookups take 100 milliseconds
time to perform all mounts (averaged over 5 runs) is:

num		elapsed
threads		time (sec)
-------		----------
1		13.125
2 		 6.859
3		 4.836
4	 	 3.841
5		 3.303
6		 3.100
7		 3.078
8		 3.018

Greg.
-- 
Greg Banks, R&D Software Engineer, SGI Australian Software Group.
I don't speak for SGI.


[-- Attachment #2: mountd-add-fork-option.patch --]
[-- Type: text/x-patch, Size: 6657 bytes --]

diff --git a/support/nfs/svc_socket.c b/support/nfs/svc_socket.c
index a3cb7ce..888c915 100644
--- a/support/nfs/svc_socket.c
+++ b/support/nfs/svc_socket.c
@@ -22,6 +22,7 @@ #include <unistd.h>
 #include <netdb.h>
 #include <rpc/rpc.h>
 #include <sys/socket.h>
+#include <sys/fcntl.h>
 #include <errno.h>
 
 #ifdef _LIBC
@@ -112,6 +113,26 @@ svc_socket (u_long number, int type, int
 	}
     }
 
+  if (sock >= 0 && protocol == IPPROTO_TCP)
+    {
+	/* Make the TCP rendezvous socket non-block to avoid
+	 * problems with blocking in accept() after a spurious
+	 * wakeup from the kernel */
+	int flags;
+	if ((flags = fcntl(sock, F_GETFL)) < 0)
+	  {
+	      perror (_("svc_socket: can't get socket flags"));
+	      (void) __close (sock);
+	      sock = -1;
+	  }
+	else if (fcntl(sock, F_SETFL, flags|O_NONBLOCK) < 0)
+	  {
+	      perror (_("svc_socket: can't set socket flags"));
+	      (void) __close (sock);
+	      sock = -1;
+	  }
+    }
+
   return sock;
 }
 
diff --git a/utils/mountd/mountd.c b/utils/mountd/mountd.c
index 43606dd..e402bf8 100644
--- a/utils/mountd/mountd.c
+++ b/utils/mountd/mountd.c
@@ -21,6 +21,7 @@ #include <getopt.h>
 #include <errno.h>
 #include <fcntl.h>
 #include <sys/resource.h>
+#include <sys/wait.h>
 #include "xmalloc.h"
 #include "misc.h"
 #include "mountd.h"
@@ -43,6 +44,13 @@ int new_cache = 0;
  * send mount or unmount requests -- the callout is not needed for 2.6 kernel */
 char *ha_callout_prog = NULL;
 
+/* Number of mountd threads to start.   Default is 1 and
+ * that's probably enough unless you need hundreds of
+ * clients to be able to mount at once.  */
+static int num_threads = 1;
+/* Arbitrary limit on number of threads */
+#define MAX_THREADS 64
+
 static struct option longopts[] =
 {
 	{ "foreground", 0, 0, 'F' },
@@ -57,24 +65,106 @@ static struct option longopts[] =
 	{ "no-tcp", 0, 0, 'n' },
 	{ "ha-callout", 1, 0, 'H' },
 	{ "state-directory-path", 1, 0, 's' },
+	{ "num-threads", 1, 0, 't' },
 	{ NULL, 0, 0, 0 }
 };
 
 static int nfs_version = -1;
 
+static void
+unregister_services (void)
+{
+	if (nfs_version & 0x1)
+		pmap_unset (MOUNTPROG, MOUNTVERS);
+	if (nfs_version & (0x1 << 1))
+		pmap_unset (MOUNTPROG, MOUNTVERS_POSIX);
+	if (nfs_version & (0x1 << 2))
+		pmap_unset (MOUNTPROG, MOUNTVERS_NFSV3);
+}
+
+/* Wait for all worker child processes to exit and reap them */
+static void
+wait_for_workers (void)
+{
+	int status;
+	pid_t pid;
+
+	for (;;) {
+
+		pid = waitpid(0, &status, 0);
+
+		if (pid < 0) {
+			if (errno == ECHILD)
+				return; /* no more children */
+			xlog(L_FATAL, "mountd: can't wait: %s\n",
+					strerror(errno));
+		}
+
+		/* Note: because we SIG_IGN'd SIGCHLD earlier, this
+		 * does not happen on 2.6 kernels, and waitpid() blocks
+		 * until all the children are dead then returns with
+		 * -ECHILD.  But, we don't need to do anything on the
+		 * death of individual workers, so we don't care. */
+		xlog(L_NOTICE, "mountd: reaped child %d, status %d\n",
+				(int)pid, status);
+	}
+}
+
+/* Fork num_threads worker children and wait for them */
+static void
+fork_workers(void)
+{
+	int i;
+	pid_t pid;
+
+	xlog(L_NOTICE, "mountd: starting %d threads\n", num_threads);
+
+	for (i = 0 ; i < num_threads ; i++) {
+		pid = fork();
+		if (pid < 0) {
+			xlog(L_FATAL, "mountd: cannot fork: %s\n",
+					strerror(errno));
+		}
+		if (pid == 0) {
+			/* worker child */
+
+			/* Re-enable the default action on SIGTERM et al
+			 * so that workers die naturally when sent them.
+			 * Only the parent unregisters with pmap and
+			 * hence needs to do special SIGTERM handling. */
+			struct sigaction sa;
+			sa.sa_handler = SIG_DFL;
+			sa.sa_flags = 0;
+			sigemptyset(&sa.sa_mask);
+			sigaction(SIGHUP, &sa, NULL);
+			sigaction(SIGINT, &sa, NULL);
+			sigaction(SIGTERM, &sa, NULL);
+
+			/* fall into my_svc_run in caller */
+			return;
+		}
+	}
+
+	/* in parent */
+	wait_for_workers();
+	unregister_services();
+	xlog(L_NOTICE, "mountd: no more workers, exiting\n");
+	exit(0);
+}
+
 /*
  * Signal handler.
  */
 static void 
 killer (int sig)
 {
-  if (nfs_version & 0x1)
-    pmap_unset (MOUNTPROG, MOUNTVERS);
-  if (nfs_version & (0x1 << 1))
-    pmap_unset (MOUNTPROG, MOUNTVERS_POSIX);
-  if (nfs_version & (0x1 << 2))
-    pmap_unset (MOUNTPROG, MOUNTVERS_NFSV3);
-  xlog (L_FATAL, "Caught signal %d, un-registering and exiting.", sig);
+	unregister_services();
+	if (num_threads > 1) {
+		/* play Kronos and eat our children */
+		kill(0, SIGTERM);
+		wait_for_workers();
+	}
+	xlog (L_FATAL, "Caught signal %d, un-registering and exiting.", sig);
 }
 
 static void
@@ -468,7 +558,7 @@ main(int argc, char **argv)
 
 	/* Parse the command line options and arguments. */
 	opterr = 0;
-	while ((c = getopt_long(argc, argv, "o:n:Fd:f:p:P:hH:N:V:vs:", longopts, NULL)) != EOF)
+	while ((c = getopt_long(argc, argv, "o:n:Fd:f:p:P:hH:N:V:vs:t:", longopts, NULL)) != EOF)
 		switch (c) {
 		case 'o':
 			descriptors = atoi(optarg);
@@ -515,6 +605,9 @@ main(int argc, char **argv)
 				exit(1);
 			}
 			break;
+		case 't':
+			num_threads = atoi (optarg);
+			break;
 		case 'V':
 			nfs_version |= 1 << (atoi (optarg) - 1);
 			break;
@@ -615,6 +708,17 @@ main(int argc, char **argv)
 		setsid();
 	}
 
+	/* silently bounds check num_threads */
+	if (foreground)
+		num_threads = 1;
+	else if (num_threads < 1)
+		num_threads = 1;
+	else if (num_threads > MAX_THREADS)
+		num_threads = MAX_THREADS;
+
+	if (num_threads > 1)
+		fork_workers();
+
 	my_svc_run();
 
 	xlog(L_ERROR, "Ack! Gack! svc_run returned!\n");
@@ -629,6 +733,7 @@ usage(const char *prog, int n)
 "	[-o num|--descriptors num] [-f exports-file|--exports-file=file]\n"
 "	[-p|--port port] [-V version|--nfs-version version]\n"
 "	[-N version|--no-nfs-version version] [-n|--no-tcp]\n"
-"	[-H ha-callout-prog] [-s|--state-directory-path path]\n", prog);
+"	[-H ha-callout-prog] [-s|--state-directory-path path]\n"
+"	[-t num|--num-threads=num]\n", prog);
 	exit(n);
 }
diff --git a/utils/mountd/mountd.man b/utils/mountd/mountd.man
index bac4421..70166c1 100644
--- a/utils/mountd/mountd.man
+++ b/utils/mountd/mountd.man
@@ -125,6 +125,13 @@ If this option is not specified the defa
 .BR /var/lib/nfs
 is used.
 .TP
+.BR "\-t N" " or " "\-\-num\-threads=N"
+This option specifies the number of worker threads that rpc.mountd
+spawns.  The default is 1 thread, which is probably enough.  More
+threads are usually only needed for NFS servers which need to handle
+mount storms of hundreds of NFS mounts in a few seconds, or when
+your DNS server is slow or unreliable.
+.TP
 .B \-V " or " \-\-nfs-version
 This option can be used to request that
 .B rpc.mountd

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]



[-- Attachment #4: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: 2.4 vs 2.6

[William A.(Andy) Adamson]

> There are only two criticisms I would make of Linux' upcall design.
> 
> First, Linux uses a wacky special-purpose filesystem.  Solaris and
> IRIX use a normal RPC to a special RPC program number implemented
> in mountd, using the existing RPC client code which is already needed
> in the server to initiate lockd callbacks.  This reduces code
> complexity in the kernel, and means you can watch the upcall traffic
> with wireshark (or whatever ethereal is called this week) or snoop
> instead of strace on mountd.  But whatever, it mostly works now.
> 

funny you should mention the RPC upcall. that was the origional design i 
coded, was working just fine, and was nixed!

-->Andy


> -- 
> Greg Banks, R&D Software Engineer, SGI Australian Software Group.
> I don't speak for SGI.
> 
> 
> 
> 
> _______________________________________________
> NFS maillist  -  NFS@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs




_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: 2.4 vs 2.6

[Greg Banks]

On Thu, 2006-06-15 at 05:40, William A.(Andy) Adamson wrote:
> funny you should mention the RPC upcall. that was the origional design i 
> coded, was working just fine, and was nixed!

Whyever?

Greg.
-- 
Greg Banks, R&D Software Engineer, SGI Australian Software Group.
I don't speak for SGI.




_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: multiple mountds (was: 2.4 vs 2.6)

[Neil Brown]

On Wednesday June 14, gnb@melbourne.sgi.com wrote:
> 
> How about the attached patch against nfs-utils tot?  It
> adds a -t option to set the number of forked workers.
> Default is 1 thread, i.e. the old behaviour.
> 

Looks perfect, thanks.
I've added it to the git at 
    http://linux-nfs.org/cgi-bin/gitweb.cgi?p=nfs-utils;a=summary
    git://linux-nfs.org/nfs-utils

Documentation and everything.  No Changelog though... I should do that
at some stage.

Thanks,

NeilBrown


_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: 2.4 vs 2.6

[David Ford]

Partial comments below

Anssi Saari wrote:

>>  -- modules don't autoload for some reason (though I'm sure that could
>>     be solved),
>>    
>>
>
>I've had this too, with autofs4 and 3c59x. After patching lirc into the
>kernel, the only real issue is with the console. I found a patch for radeonfb,
>but didn't get anywhere with it.
>
>The rest of my problems is userland stuff:
>
>- Murasaki (a hotplug agent) doesn't react when USB things are plugged in
>  
>

You need to update your hotplug installation.  Turn on debugging in your 
hotplug scripts and copy the appropriate object ID numbers into the 
usb.usermap file.

>- swapon -a takes two minutes to complete for some reason
>  
>

Try recreating your swapon partition/file?  Turning on a gig of swap 
here happens pretty quick.

>- rpc.lockd doesn't start, it says lockdsvc: Function not implemented. I don't
>  
>

Update/rebuild your rpc/nfs tools.

>  know if I really need this anyway, nfs seems to work fine
>- zsh doesn't complete make targets like menuconfig
>- I'd also like to point out that cdrecord isn't sufficient for my 
>  CD writing needs, I need cdrdao too and it doesn't seem to support
>  direct access to ATAPI drives. 
>  
>

I haven't used zsh or cdrdao so I can't comment on them.   I don't use 
the above modules, but all the other modules on my system (numerous) do 
autoload just fine.  NFS is a big PITA for me for other reasons but the 
services do start.

My systems are of the Gentoo flavor.

David

Re: 2.4 vs 2.6

[Anssi Saari]

>   -- modules don't autoload for some reason (though I'm sure that could
>      be solved),

I've had this too, with autofs4 and 3c59x. After patching lirc into the
kernel, the only real issue is with the console. I found a patch for radeonfb,
but didn't get anywhere with it.

The rest of my problems is userland stuff:

- Murasaki (a hotplug agent) doesn't react when USB things are plugged in
- swapon -a takes two minutes to complete for some reason
- rpc.lockd doesn't start, it says lockdsvc: Function not implemented. I don't
  know if I really need this anyway, nfs seems to work fine
- zsh doesn't complete make targets like menuconfig
- I'd also like to point out that cdrecord isn't sufficient for my 
  CD writing needs, I need cdrdao too and it doesn't seem to support
  direct access to ATAPI drives. 

Re: 2.4 vs 2.6

[Voicu Liviu]

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

Harry McGregor wrote:

| On Sun, 2003-12-14 at 10:32, Voicu Liviu wrote:
|
|> Because i use lvm2 and I could not find the way to get back to
|> lvm1 Any clue?
|
|
| How about using the patches for 2.4 to give you LVM2 support?
|
| http://people.sistina.com/~thornber/

This url?
http://people.sistina.com/~thornber/patches/2.4-stable/2.4.22/2.4.22-dm-1/
I'll just get the 2.4.23 vanilla and patch it? I'll try
Thanks

|
| We have it running on one system right now, in fact it is part of
| the reason that we manually patched our 2.4.21 to fix the local
| root exploit that was fixed in 2.4.23, we just had too many
| external patches (FreeSwan, DeviceMapper, XFS, etc) on that system,
| to do patch and recompile in a reasonable amount of time.
|
|
| Harry
|
|> Liviu
|
|
|
| - To unsubscribe from this list: send the line "unsubscribe
| linux-kernel" in the body of a message to majordomo@vger.kernel.org
|  More majordomo info at  http://vger.kernel.org/majordomo-info.html
|  Please read the FAQ at  http://www.tux.org/lkml/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/3WgCkj4I0Et8EMgRApIvAKDO8umYrrSqDodby3OWmxwY9x5ejgCg7wZ+
u5SiceDoteNq61XIVK7vD54=
=5qUw
-----END PGP SIGNATURE-----

Re: 2.4 vs 2.6

[Harry McGregor]

On Sun, 2003-12-14 at 10:32, Voicu Liviu wrote:

> Because i use lvm2 and I could not find the way to get back to lvm1
> Any clue?

How about using the patches for 2.4 to give you LVM2 support?

http://people.sistina.com/~thornber/

We have it running on one system right now, in fact it is part of the
reason that we manually patched our 2.4.21 to fix the local root exploit
that was fixed in 2.4.23, we just had too many external patches
(FreeSwan, DeviceMapper, XFS, etc) on that system, to do patch and
recompile in a reasonable amount of time.


			Harry

> Liviu

Re: 2.4 vs 2.6

[tabris]

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

On Saturday 13 December 2003 9:01 pm, coderman wrote:
> Jan Rychter wrote:
> >So, as for me, 2.6 is a definite no-no. I see no advantage whatsoever
> > in running it, it caused me nothing but pain, and there is no
> > improvement that I could see that would justify the upgrade.
> >
> >So please be careful when making statements like that. 2.6 is *NOT*
> >stable enough nor ready enough for people to use it, unless those
> > people have a narrow range of hardware on which the 2.6 kernel has
> > actually been tested (translation: they have the same hardware as the
> > main developers do).
>
> For every person who has problems with 2.6, there are probably 2 others
> who have none, and enjoy the benefits of the new features.  2.6 works
> great for me, and one a number of hardware configurations including:
	Somehow, working for 2/3, or even 75% of cases is less than encouraging 
to me.

	Especially if I must not only set up boxes that I may not touch 
physically for days, weeks, etc. Or I suggest which kernel for other 
people to use, due to security fixes (which, iirc, not all 2.4 fixes have 
been forward ported yet), features, etc.

	2.6 is... getting there. and I DO much appreciate the work of the 
developers. But with devfs deprecated, udev still coming into its own 
(Nice work GregKG btw); with the myriad of (user visible) input layer 
changes; the change in focus on initrds (it used to be a nice thing that 
only serious people use. Now, although still optional, it is now becoming 
much more important). Or mebbe consider that the last time I tried to 
install the new modutils (I'm blaming my distro vendor for this), it 
broke my 2.4 modutils, requiring me to boot with init=/bin/sh and fix it 
up.

Sure. little things, but altogether, they add up to a lot more work to 
learn.

<snip>
>
> 2.6 may not be usable for you, but this has no bearing on the utility
> of the branch for others.  I have noticed benefits (mainly prempt,
> IPSEC, and the IDE device handling) which make it very worthwhile.
>
- --
tabris
- -
When asked by an anthropologist what the Indians called America before
the white men came, an Indian said simply "Ours."
		-- Vine Deloria, Jr.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/3May1U5ZaPMbKQcRApmfAJ9IQexnFORYTaOEpTiyPQnHt3qCMgCeJimh
8hR+oaEqXhBXbVB9tRg9g5M=
=/Cnp
-----END PGP SIGNATURE-----

Re: 2.4 vs 2.6

[Daniel Gryniewicz]

On Sun, 2003-12-14 at 06:23, Måns Rullgård wrote:
> Roberto Sanchez <rcsanchez97@yahoo.es> writes:
> 
> >> I haven't even gotten to VMware and user-mode Linux, which I also
> >> need, and I'm not even dreaming about getting my scanner to
> >> work. Not to mention that on my laptop there would be an entirely
> >> different set of issues, and software suspend in 2.6 is, well,
> >> still lacking.
> > VMWare won't work
> 
> I've run vmware on a 2.6 kernel.  I found a little patch somewhere
> that made it work.

Gentoo automatically applies this patch. :)
-- 
Daniel Gryniewicz <dang@fprintf.net>

Re: 2.4 vs 2.6

[Voicu Liviu]

Roberto Sanchez wrote:

> Voicu Liviu wrote:
>
>> My specs:
>> Cpu:Athlon XP 2500+ BARTON {10x190}
>> Mobo:EPOX 8RDA3 + NFORCE 2
>> Ram:Corsair TWINX 512 3200LL{dual channel/11-3-2-2.0}
>> Fan:Cooler Master +7
>> Video:Hercules 3D Prophet 9600 PRO Radeon 128MB
>>
>> My Hercules 3D Prophet 9600 PRO Radeon simply freezes my comp. with
>> ati-drivers from ati.com so I need to press reset!(so I only can run
>> console)
>> My sound (nvidia on board) works very shitty and I have no control on
>> it (level sound I mean).
>> I was running 2.4.23 vanilla + lvm1 so I moved to 2.6 vanilla+lvm2 and
>> now I can not move back
>>
>> These are my biggest problems with 2.6.
>
>
>
> Have you treid the in kernel DRI drivers?  They work with my Radeon
> 9000 on an nForce2.
>
> Also, why can't you go back to 2.4.23?

Because i use lvm2 and I could not find the way to get back to lvm1
Any clue?

>
> -Roberto

Liviu

Re: 2.4 vs 2.6

[Roberto Sanchez]

[-- Attachment #1: Type: text/plain, Size: 765 bytes --]

Voicu Liviu wrote:
> My specs:
> Cpu:Athlon XP 2500+ BARTON {10x190}
> Mobo:EPOX 8RDA3 + NFORCE 2
> Ram:Corsair TWINX 512 3200LL{dual channel/11-3-2-2.0}
> Fan:Cooler Master +7
> Video:Hercules 3D Prophet 9600 PRO Radeon 128MB
> 
> My Hercules 3D Prophet 9600 PRO Radeon simply freezes my comp. with
> ati-drivers from ati.com so I need to press reset!(so I only can run
> console)
> My sound (nvidia on board) works very shitty and I have no control on
> it (level sound I mean).
> I was running 2.4.23 vanilla + lvm1 so I moved to 2.6 vanilla+lvm2 and
> now I can not move back
> 
> These are my biggest problems with 2.6.


Have you treid the in kernel DRI drivers?  They work with my Radeon
9000 on an nForce2.

Also, why can't you go back to 2.4.23?

-Roberto

[-- Attachment #2: Type: application/pgp-signature, Size: 256 bytes --]

Re: 2.4 vs 2.6

[Frederik Deweerdt]

>   -- bttv does not compile, so no video input for me,
I'm watching TV on 2.6.0-test11 with bttv properly loaded...

bttv: driver version 0.9.12 loaded

Fred

Re: 2.4 vs 2.6

[Måns Rullgård]

Roberto Sanchez <rcsanchez97@yahoo.es> writes:

>> I haven't even gotten to VMware and user-mode Linux, which I also
>> need, and I'm not even dreaming about getting my scanner to
>> work. Not to mention that on my laptop there would be an entirely
>> different set of issues, and software suspend in 2.6 is, well,
>> still lacking.
> VMWare won't work

I've run vmware on a 2.6 kernel.  I found a little patch somewhere
that made it work.

-- 
Måns Rullgård
mru@kth.se

Re: 2.4 vs 2.6

[Voicu Liviu]

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

Jan Rychter wrote:

|>>>>> "Marcelo" == Marcelo Tosatti
|>>>>> <marcelo.tosatti@cyclades.com> writes:
|
| [...] Marcelo> 2.6 is already stable enough for people to use it.
|
| Yes, that's an old post I'm responding to, but I've just given 2.6
| a try on my desktop machine, and the above statement seems even
| more annoying. I hit the following problems:
|
| -- I had to wrestle ATI drivers into compiling, they finally did,
| but the kernel prints scary-looking warnings with call stacks,
| about "sleeping function called from invalid context at
| mm/slab.c:1856, -- modules don't autoload for some reason (though
| I'm sure that could be solved), -- bttv does not compile, so no
| video input for me, -- drivers for my telephony card (from Digium)
| are not 2.6-ready, so no telephony support for me, -- I have just
| frozen the machine hard by copying files over NFS and doing a
| simulation write to an ATAPI CD-RW at the same time.
|
| I haven't even gotten to VMware and user-mode Linux, which I also
| need, and I'm not even dreaming about getting my scanner to work.
| Not to mention that on my laptop there would be an entirely
| different set of issues, and software suspend in 2.6 is, well,
| still lacking.
|
| So, as for me, 2.6 is a definite no-no. I see no advantage
| whatsoever in running it, it caused me nothing but pain, and there
| is no improvement that I could see that would justify the upgrade.
|
| So please be careful when making statements like that. 2.6 is *NOT*
|  stable enough nor ready enough for people to use it, unless those
| people have a narrow range of hardware on which the 2.6 kernel has
| actually been tested (translation: they have the same hardware as
| the main developers do).
|
| --J.


My specs:
Cpu:Athlon XP 2500+ BARTON {10x190}
Mobo:EPOX 8RDA3 + NFORCE 2
Ram:Corsair TWINX 512 3200LL{dual channel/11-3-2-2.0}
Fan:Cooler Master +7
Video:Hercules 3D Prophet 9600 PRO Radeon 128MB

My Hercules 3D Prophet 9600 PRO Radeon simply freezes my comp. with
ati-drivers from ati.com so I need to press reset!(so I only can run
console)
My sound (nvidia on board) works very shitty and I have no control on
it (level sound I mean).
I was running 2.4.23 vanilla + lvm1 so I moved to 2.6 vanilla+lvm2 and
now I can not move back

These are my biggest problems with 2.6.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/3Aurkj4I0Et8EMgRArxCAKDbp0uE5mIhA5/5C+v/71tscWneHQCg0h3R
RF2NIf4bbQ3XEMjV6eEePJI=
=7jBp
-----END PGP SIGNATURE-----

Re: 2.4 vs 2.6

[coderman]

Jan Rychter wrote:

>So, as for me, 2.6 is a definite no-no. I see no advantage whatsoever in
>running it, it caused me nothing but pain, and there is no improvement
>that I could see that would justify the upgrade.
>
>So please be careful when making statements like that. 2.6 is *NOT*
>stable enough nor ready enough for people to use it, unless those people
>have a narrow range of hardware on which the 2.6 kernel has actually
>been tested (translation: they have the same hardware as the main
>developers do).
>  
>
For every person who has problems with 2.6, there are probably 2 others
who have none, and enjoy the benefits of the new features.  2.6 works
great for me, and one a number of hardware configurations including:

- PII-266
- SMP dual PIII-550
- M10000 mini-itx
- 1.1 Ghz Athlon

all with a variety of video chipsets, USB devices, IDE / ATAPI disks
and CD/DVD, sound cards, etc.

I doubt many of these are consistent with the main developers.

2.6 may not be usable for you, but this has no bearing on the utility
of the branch for others.  I have noticed benefits (mainly prempt,
IPSEC, and the IDE device handling) which make it very worthwhile.

Re: 2.4 vs 2.6

[Daniel Gryniewicz]

On Sat, 2003-12-13 at 20:08, Jan Rychter wrote:
<snip>
> So please be careful when making statements like that. 2.6 is *NOT*
> stable enough nor ready enough for people to use it, unless those people
> have a narrow range of hardware on which the 2.6 kernel has actually
> been tested (translation: they have the same hardware as the main
> developers do).

I have a brand-spanken-new laptop (less than a month old), and all my
hardware works great.  In fact, ATI drivers (only in pre-release X) only
work on 2.6, and ACPI never worked on 2.4.  So, it works better for me
than on 2.4.  Please be careful when saying that 2.4 is better than 2.6,
it's only that way for a narrow set of hardware.
-- 
Daniel Gryniewicz <dang@fprintf.net>

Re: 2.4 vs 2.6

[Jan Rychter]

[-- Attachment #1: Type: text/plain, Size: 1681 bytes --]

>>>>> "Marcelo" == Marcelo Tosatti <marcelo.tosatti@cyclades.com> writes:
[...]
 Marcelo> 2.6 is already stable enough for people to use it.

Yes, that's an old post I'm responding to, but I've just given 2.6 a try
on my desktop machine, and the above statement seems even more
annoying. I hit the following problems:

  -- I had to wrestle ATI drivers into compiling, they finally did, but
     the kernel prints scary-looking warnings with call stacks, about
     "sleeping function called from invalid context at mm/slab.c:1856,
  -- modules don't autoload for some reason (though I'm sure that could
     be solved),
  -- bttv does not compile, so no video input for me,
  -- drivers for my telephony card (from Digium) are not 2.6-ready, so
     no telephony support for me,
  -- I have just frozen the machine hard by copying files over NFS and
     doing a simulation write to an ATAPI CD-RW at the same time.

I haven't even gotten to VMware and user-mode Linux, which I also need,
and I'm not even dreaming about getting my scanner to work. Not to
mention that on my laptop there would be an entirely different set of
issues, and software suspend in 2.6 is, well, still lacking.

So, as for me, 2.6 is a definite no-no. I see no advantage whatsoever in
running it, it caused me nothing but pain, and there is no improvement
that I could see that would justify the upgrade.

So please be careful when making statements like that. 2.6 is *NOT*
stable enough nor ready enough for people to use it, unless those people
have a narrow range of hardware on which the 2.6 kernel has actually
been tested (translation: they have the same hardware as the main
developers do).

--J.

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: 2.4 vs 2.6

[Roberto Sanchez]

[-- Attachment #1: Type: text/plain, Size: 2869 bytes --]

Jan Rychter wrote:
>>>>>>"Marcelo" == Marcelo Tosatti <marcelo.tosatti@cyclades.com> writes:
> 
> [...]
>  Marcelo> 2.6 is already stable enough for people to use it.
> 
> Yes, that's an old post I'm responding to, but I've just given 2.6 a try
> on my desktop machine, and the above statement seems even more
> annoying. I hit the following problems:
> 
>   -- I had to wrestle ATI drivers into compiling, they finally did, but
>      the kernel prints scary-looking warnings with call stacks, about
>      "sleeping function called from invalid context at mm/slab.c:1856,
I have an nForce2 w/ Radeon 9000.  No problems w/ DRI drivers (included
in kernel) or thi ATI supplied drivers, which ATI says successfully
compiled against 2.6.0-test6.

>   -- modules don't autoload for some reason (though I'm sure that could
>      be solved),
Make sure you have all the different module options turned on.  In 2.6
there are different options for loading, unloading and force unloading
modules.

>   -- bttv does not compile, so no video input for me,
I don't know anything about video input.  Did you try Google?

>   -- drivers for my telephony card (from Digium) are not 2.6-ready, so
>      no telephony support for me,
I don't know anything about telephony.  Did you try Google?

>   -- I have just frozen the machine hard by copying files over NFS and
>      doing a simulation write to an ATAPI CD-RW at the same time.
What CPU/chipset do you have?  There are timing issues with nForce2
and AMD CPUs.  A quick search of the LKML archives will yield lots
of discussion and patcheson this issue.

> 
> I haven't even gotten to VMware and user-mode Linux, which I also need,
> and I'm not even dreaming about getting my scanner to work. Not to
> mention that on my laptop there would be an entirely different set of
> issues, and software suspend in 2.6 is, well, still lacking.
VMWare won't work (according to the VMWare tech support people), but
they will (probably) support 2.6 kernels in their next point release.
I assume you are talking about their workstation product.  SWSusp
works fine on my laptop.

> 
> So, as for me, 2.6 is a definite no-no. I see no advantage whatsoever in
> running it, it caused me nothing but pain, and there is no improvement
> that I could see that would justify the upgrade.
But there is plenty of improvement for plenty of people.

> 
> So please be careful when making statements like that. 2.6 is *NOT*
> stable enough nor ready enough for people to use it, unless those people
> have a narrow range of hardware on which the 2.6 kernel has actually
> been tested (translation: they have the same hardware as the main
> developers do).
I doubt I have the same hardware as the main developers, but I did
read the documentation.  Did you?  Even if it is stable enough for
most people, it is still a beta kernel.

> 
> --J.

-Roberto.

[-- Attachment #2: Type: application/pgp-signature, Size: 256 bytes --]