XFS for 2.4

XFS for 2.4

[Nathan Scott]

Hi Marcelo,

Please do a

	bk pull http://xfs.org:8090/linux-2.4+coreXFS

This will merge the core 2.4 kernel changes required for supporting
the XFS filesystem, as listed below.  If this all looks acceptable,
then please also pull the filesystem-specific code (fs/xfs/*)

	bk pull http://xfs.org:8090/linux-2.4+justXFS

cheers.

-- 
Nathan


linux-2.4+coreXFS updates the following files:

 Documentation/Changes              |   16 ++
 Documentation/Configure.help       |   84 +++++++++++++
 Documentation/filesystems/00-INDEX |    2 
 Documentation/filesystems/xfs.txt  |  226 +++++++++++++++++++++++++++++++++++--
 MAINTAINERS                        |    8 +
 drivers/block/ll_rw_blk.c          |    3 
 fs/Config.in                       |    7 +
 fs/Makefile                        |    4 
 fs/buffer.c                        |   59 ++++++++-
 fs/inode.c                         |   46 +++----
 fs/namei.c                         |   13 +-
 fs/open.c                          |   13 ++
 include/linux/dqblk_xfs.h          |    9 -
 include/linux/fs.h                 |   50 +++++++-
 include/linux/posix_acl_xattr.h    |   67 ++++++++++
 include/linux/sched.h              |    1 
 kernel/ksyms.c                     |   12 +
 mm/filemap.c                       |   63 +++++++++-
 18 files changed, 618 insertions(+), 65 deletions(-)

through these ChangeSets:

<nathans@bruce.melbourne.sgi.com> (03/11/24 1.1183.1.1)
   VFS support for filesystems which implement POSIX ACLs.
   
   This involves an inode flag which directs the VFS to skip application
   of the umask so that the filesystem ACL code can do this according to
   the POSIX rules, and a new header file defining the contents of the 2
   system ACL extended attributes.  This is a backport from 2.6.

<nathans@bruce.melbourne.sgi.com> (03/11/25 1.1194)
   Fix utimes(2) and immutable/append-only files.

<nathans@bruce.melbourne.sgi.com> (03/11/25 1.1195)
   Remove some unused macros and related comment from the XFS quota header.

<nathans@bruce.melbourne.sgi.com> (03/11/25 1.1196)
   Add a process flag to identify a process performing a transaction.
   Used by XFS and backported from 2.6.

<nathans@bruce.melbourne.sgi.com> (03/11/25 1.1197)
   Support for delayed allocation.  Used by XFS and backported from 2.6.

<nathans@bruce.melbourne.sgi.com> (03/11/25 1.1198)
   Provide a simple try-lock based dirty page flushing routine.

<nathans@bruce.melbourne.sgi.com> (03/11/25 1.1199)
   Provide an iget variant without unlocking the inode and without the
   read_inode call (iget_locked).  Used by XFS and backported from 2.6.

<nathans@bruce.melbourne.sgi.com> (03/11/26 1.1200)
   Export several kernel symbols used by the XFS filesystem.

<nathans@bruce.melbourne.sgi.com> (03/11/26 1.1201)
   Add XFS documentation and incorporate XFS into the kernel build.

<nathans@bruce.melbourne.sgi.com> (03/12/01 1.1202.1.1)
   [XFS] Document the XFS noikeep option, make ikeep the default.

Re: XFS for 2.4

[Jens Axboe]

On Mon, Dec 01 2003, Nathan Scott wrote:
> Hi Marcelo,
> 
> Please do a
> 
> 	bk pull http://xfs.org:8090/linux-2.4+coreXFS
> 
> This will merge the core 2.4 kernel changes required for supporting
> the XFS filesystem, as listed below.  If this all looks acceptable,
> then please also pull the filesystem-specific code (fs/xfs/*)
> 
> 	bk pull http://xfs.org:8090/linux-2.4+justXFS

Where can these be found as a unified diff? It's quite bothersome to
have to pull a changeset just to review it (cloning a kernel tree
first), not to mention space intensive.

-- 
Jens Axboe

Re: XFS for 2.4

[Stefan Smietanowski]

Jens Axboe wrote:

> On Mon, Dec 01 2003, Nathan Scott wrote:
> 
>>Hi Marcelo,
>>
>>Please do a
>>
>>	bk pull http://xfs.org:8090/linux-2.4+coreXFS
>>
>>This will merge the core 2.4 kernel changes required for supporting
>>the XFS filesystem, as listed below.  If this all looks acceptable,
>>then please also pull the filesystem-specific code (fs/xfs/*)
>>
>>	bk pull http://xfs.org:8090/linux-2.4+justXFS
> 
> 
> Where can these be found as a unified diff? It's quite bothersome to
> have to pull a changeset just to review it (cloning a kernel tree
> first), not to mention space intensive.
> 

There was a mail announcing split-patches for 2.4.23 five hours before
this mail. The mail was from Keith Owens but here's the link from it:

ftp://oss.sgi.com/projects/xfs/patches/2.4.23 for the 2.4.23 patches.

// Stefan

Re: XFS for 2.4

[Jens Axboe]

On Mon, Dec 01 2003, Stefan Smietanowski wrote:
> Jens Axboe wrote:
> 
> >On Mon, Dec 01 2003, Nathan Scott wrote:
> >
> >>Hi Marcelo,
> >>
> >>Please do a
> >>
> >>	bk pull http://xfs.org:8090/linux-2.4+coreXFS
> >>
> >>This will merge the core 2.4 kernel changes required for supporting
> >>the XFS filesystem, as listed below.  If this all looks acceptable,
> >>then please also pull the filesystem-specific code (fs/xfs/*)
> >>
> >>	bk pull http://xfs.org:8090/linux-2.4+justXFS
> >
> >
> >Where can these be found as a unified diff? It's quite bothersome to
> >have to pull a changeset just to review it (cloning a kernel tree
> >first), not to mention space intensive.
> >
> 
> There was a mail announcing split-patches for 2.4.23 five hours before
> this mail. The mail was from Keith Owens but here's the link from it:
> 
> ftp://oss.sgi.com/projects/xfs/patches/2.4.23 for the 2.4.23 patches.

Great, thanks.

-- 
Jens Axboe

Re: XFS for 2.4

[Marcelo Tosatti]

On Mon, 1 Dec 2003, Nathan Scott wrote:

> Hi Marcelo,
> 
> Please do a
> 
> 	bk pull http://xfs.org:8090/linux-2.4+coreXFS
> 
> This will merge the core 2.4 kernel changes required for supporting
> the XFS filesystem, as listed below.  If this all looks acceptable,
> then please also pull the filesystem-specific code (fs/xfs/*)
> 
> 	bk pull http://xfs.org:8090/linux-2.4+justXFS

Nathan, 

I think XFS should be a 2.6 only feature.

2.6 is already stable enough for people to use it. 

Re: XFS for 2.4

[Nathan Scott]

On Mon, Dec 01, 2003 at 12:06:14PM -0200, Marcelo Tosatti wrote:
> On Mon, 1 Dec 2003, Nathan Scott wrote:
> 
> > Hi Marcelo,
> > 
> > Please do a
> > 
> > 	bk pull http://xfs.org:8090/linux-2.4+coreXFS
> > 
> > This will merge the core 2.4 kernel changes required for supporting
> > the XFS filesystem, as listed below.  If this all looks acceptable,
> > then please also pull the filesystem-specific code (fs/xfs/*)
> > 
> > 	bk pull http://xfs.org:8090/linux-2.4+justXFS
> 
> Nathan, 
> 
> I think XFS should be a 2.6 only feature.
> 
> 2.6 is already stable enough for people to use it. 
> 

Hi Marcelo,

Please reconsider -- the "core" kernel changes we need have existed
for three+ years outside of the mainline tree, and each is a small
and easily understood change that doesn't affect other filesystems.
There is also a VFS fix in there from Ethan Benson, as we discussed
during 2.4.23-pre, when you asked us to resend XFS for 2.4.24-pre!)
Everything there is a backport from 2.6 in some form, there should
be no surprises.

Not having XFS in 2.4 is extremely disadvantageous for us XFS folks
(especially since every other journaled filesystem has been merged
now).  To our users it means some rescue disks simply don't support
XFS, meaning you can't mount filesystems when you _really_ need to,
etc, etc.  Its also always extra work for distributors to merge XFS
themselves, and hence a few just don't (and occasionally tell us
that they are waiting for you to merge it) - which means some users
don't even get the option of using XFS, despite our best efforts.

>From discussions with distributors, a stable 2.6 distribution will
be many months after 2.6.0 is officially released, so these issues
are not going to go away anytime soon.

So, please merge XFS this time round - its actively developed, has
a large installed user base, and has been maintained outside of 2.4
for a long time.  We have waited patiently as each release goes by
for you to give us the nod, and have been knocked back on a number
of occasions while various other merges are being done.

cheers.

-- 
Nathan

Re: XFS for 2.4

[Larry McVoy]

On Tue, Dec 02, 2003 at 09:10:58AM +1100, Nathan Scott wrote:
> > Nathan, 
> > 
> > I think XFS should be a 2.6 only feature.
> > 
> > 2.6 is already stable enough for people to use it. 
> > 
> 
> Hi Marcelo,
> 
> Please reconsider 

I have no idea if XFS should or should not go in, I'm not commenting on that.

However, having a bunch of XFS users say "put it in" when the maintainer
said no, DaveM said no, and no other file system people seem to be
stepping up to the bat with a review and a nod seems wrong.  

Have you spoken with the people who maintain the generic parts of the
VFS layer that you want to change?  If those people were in the list of
people saying "XFS should go in" then I think you'd get a lot farther.

It's great that there are XFS users but the users should not make the add
it or not add it decision, the people who maintain those interfaces which
are generic should make that decision.  Don't you agree?
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

Re: XFS for 2.4

[Nathan Scott]

Hello Larry,

On Mon, Dec 01, 2003 at 02:20:25PM -0800, Larry McVoy wrote:
> 
> I have no idea if XFS should or should not go in, I'm not commenting on that.
> 
> However, having a bunch of XFS users say "put it in" when the maintainer
> said no, DaveM said no, and no other file system people seem to be
> stepping up to the bat with a review and a nod seems wrong.  

I must have missed that mail from Dave - or perhaps its still
in flight to me.  If you're refering to his "super-maintainence
mode" comment, I don't believe there was any specific comments
relating to XFS there (and XFS on 2.4 is in maintenance mode,
has been for a long time).

I also have mail from Marcelo saying he would look at merging XFS
in 2.4.24-pre (back when we last sent it, in 2.4.23-pre) ... so,
obviously I'm a little confused by this turn of events.

> Have you spoken with the people who maintain the generic parts of the
> VFS layer that you want to change?  If those people were in the list of
> people saying "XFS should go in" then I think you'd get a lot farther.

That level of discussion with other kernel coders, and extensive
review _has_ happened, in many cases _years_ ago now - this stuff
has all been merged in 2.5 for ages.  I wouldn't expect discussion
from other filesystem people at this stage - it is all old news to
them.

> ... the people who maintain those interfaces which
> are generic should make that decision.  Don't you agree?

Of course, and they have agreed that these are the way the changes
should be made - if you look at 2.6 you will see these changes all
merged there, a long time ago.  As I said, there is nothing new or
surprising here, and the changes are small and such that the other
filesystems are unaffected.

cheers.

-- 
Nathan

Re: XFS for 2.4

[Marcelo Tosatti]

On Tue, 2 Dec 2003, Nathan Scott wrote:

> Hello Larry,
> 
> On Mon, Dec 01, 2003 at 02:20:25PM -0800, Larry McVoy wrote:
> > 
> > I have no idea if XFS should or should not go in, I'm not commenting on that.
> > 
> > However, having a bunch of XFS users say "put it in" when the maintainer
> > said no, DaveM said no, and no other file system people seem to be
> > stepping up to the bat with a review and a nod seems wrong.  
> 
> I must have missed that mail from Dave - or perhaps its still
> in flight to me.  If you're refering to his "super-maintainence
> mode" comment, I don't believe there was any specific comments
> relating to XFS there (and XFS on 2.4 is in maintenance mode,
> has been for a long time).
> 
> I also have mail from Marcelo saying he would look at merging XFS
> in 2.4.24-pre (back when we last sent it, in 2.4.23-pre) ... so,
> obviously I'm a little confused by this turn of events.

Nathan, 

Yes, I indeed told you "resent me for 2.4.24-pre". I have changed my mind. 

Sorry for the trouble that caused you.

> That level of discussion with other kernel coders, and extensive
> review _has_ happened, in many cases _years_ ago now - this stuff
> has all been merged in 2.5 for ages.  I wouldn't expect discussion
> from other filesystem people at this stage - it is all old news to
> them.
> 
> > ... the people who maintain those interfaces which
> > are generic should make that decision.  Don't you agree?
> 
> Of course, and they have agreed that these are the way the changes
> should be made - if you look at 2.6 you will see these changes all
> merged there, a long time ago.  As I said, there is nothing new or
> surprising here, and the changes are small and such that the other
> filesystems are unaffected.

A development tree is much different from a stable tree. You cant just
simply backport generic VFS changes just because everybody agreed with
them on the development tree.

My whole point is "2.6 is almost out of the door and its so much better".  
Its much faster, much cleaner. 

Re: XFS for 2.4

[Austin Gonyou]

On Tue, 2003-12-02 at 05:22, Marcelo Tosatti wrote:
> [...]
> My whole point is "2.6 is almost out of the door and its so much
> better".  
> Its much faster, much cleaner. 

I agree with this, even in spite of my earlier arguments. I do like 2.6,
but I think there are some valid points listed recently for 2.4
inclusion. I might just be an end-user, but I do appreciate XFS for what
it is, and have been using it for a while now. It just seems like
natural inclusion at this point almost "just makes sense."


-- 
Austin Gonyou <austin@coremetrics.com>
Coremetrics, Inc.

Re: XFS for 2.4

[Stephan von Krawczynski]

On Tue, 2 Dec 2003 09:22:48 -0200 (BRST)
Marcelo Tosatti <marcelo.tosatti@cyclades.com> wrote:

> [...]
> A development tree is much different from a stable tree. You cant just
> simply backport generic VFS changes just because everybody agreed with
> them on the development tree.
> 
> My whole point is "2.6 is almost out of the door and its so much better".  
> Its much faster, much cleaner. 

Even if I am a bit off-topic here, please reconsider your last sentence. Don't
make people think that 2.6 is in a widely useable state right now. Just take a
look at the history of 2.4. Don't forget 2.4 can be used in boxes beyond 4 GB
only right _now_ (2.4.23), all previous versions fall completely apart on i386
platform. 2.4 is right now nice, useable and pretty stable - and 2.6 has not
even begun to see the real-and-ugly world yet. There will for sure be a lot of
interesting test cases during the next months for 2.6, but there are quite an
amount of people that need a real stable environment - and that's why they will
have to use 2.4 for at least one year from now on.

This is no vote for or against XFS-inclusion, I don't know the thing at all. I
only want to state: developer environment is pretty different from the real
world, so don't dump 2.4 too early please.

Regards,
Stephan

Re: XFS for 2.4

[Marcelo Tosatti]

On Tue, 2 Dec 2003, Stephan von Krawczynski wrote:

> On Tue, 2 Dec 2003 09:22:48 -0200 (BRST)
> Marcelo Tosatti <marcelo.tosatti@cyclades.com> wrote:
> 
> > [...]
> > A development tree is much different from a stable tree. You cant just
> > simply backport generic VFS changes just because everybody agreed with
> > them on the development tree.
> > 
> > My whole point is "2.6 is almost out of the door and its so much better".  
> > Its much faster, much cleaner. 
> 
> Even if I am a bit off-topic here, please reconsider your last sentence. Don't
> make people think that 2.6 is in a widely useable state right now. Just take a
> look at the history of 2.4. Don't forget 2.4 can be used in boxes beyond 4 GB
> only right _now_ (2.4.23), all previous versions fall completely apart on i386
> platform. 2.4 is right now nice, useable and pretty stable - and 2.6 has not
> even begun to see the real-and-ugly world yet. There will for sure be a lot of
> interesting test cases during the next months for 2.6, but there are quite an
> amount of people that need a real stable environment - and that's why they will
> have to use 2.4 for at least one year from now on.
> 
> This is no vote for or against XFS-inclusion, I don't know the thing at all. I
> only want to state: developer environment is pretty different from the real
> world, so don't dump 2.4 too early please.

I'm not dumping 2.4. It will enter "maintenance-only" mode in 2.4.25. It
will be update as long as there are problems in it, but no more features
will creep in.

As for XFS, Christoph will review the patches and tell me what he thinks. 

Also other people mailed me saying they reviewed the code.

That makes me more comfortable with merging the XFS modifications.

Re: XFS for 2.4

[Lawrence Walton]

<snip>
> Even if I am a bit off-topic here, please reconsider your last sentence. Don't
> make people think that 2.6 is in a widely useable state right now. Just take a
> look at the history of 2.4. Don't forget 2.4 can be used in boxes beyond 4 GB
> only right _now_ (2.4.23), all previous versions fall completely apart on i386
> platform. 2.4 is right now nice, useable and pretty stable - and 2.6 has not
> even begun to see the real-and-ugly world yet. There will for sure be a lot of
> interesting test cases during the next months for 2.6, but there are quite an
> amount of people that need a real stable environment - and that's why they will
> have to use 2.4 for at least one year from now on.
> 
Ye gods I'm going to regret butting into this conversation but...

I have moved a couple servers successfully to 2.6.0-pre9, felt (over)
confident that 2.6.x would work on my busiest server. It was a mistake,
lightly loaded it worked great. As user logged in that morning the
server became unstable, processes started waiting forever and hanging,
imap mostly, later exim and openldap. I never reported it for lack of
good debugging info, I plan to take another wack at it in a month or so.


2.4.x is my only option, I would imagine I'm not in the minority here.
I do use XFS, not on this particular server but I do use it and would
like to see it included into 2.4.x for no other reason than 2.6.x is not
stable in all situations.

-- 
*--* Mail: lawrence@otak.com
*--* Voice: 425.739.4247
*--* Fax: 425.827.9577
*--* HTTP://the-penguin.otak.com/~lawrence
--------------------------------------
- - - - - - O t a k  i n c . - - - - - 

Re: XFS for 2.4

[bill davidsen]

In article <Pine.LNX.4.44.0312020919410.13692-100000@logos.cnet>,
Marcelo Tosatti  <marcelo.tosatti@cyclades.com> wrote:

| A development tree is much different from a stable tree. You cant just
| simply backport generic VFS changes just because everybody agreed with
| them on the development tree.
| 
| My whole point is "2.6 is almost out of the door and its so much better".  
| Its much faster, much cleaner. 

Yes, a development tree is much different than a stable tree, and even
though the number has gone to 2.6, it's very much a development tree, in
that it's still being used by the same people, and probably not getting
a lot of new testing. Stability is unlikely to be production quality
until fixes go in for problems in mass testing, which won't happen until
it shows up in a vendor release, which won't happen until the vendors
test and clean up what they find... In other words, I don't expect it to
be "really stable" for six months at least, maybe a year.

As for "much faster," let's say that I don't see that on any apples to
apples benchmark. If you measure new threading against 2.4 threading
there is a significant gain, but for anything else the gains just don't
seem to warrant a "much" and there are some regressions shown in other
people's data.

I think 2.6 has new features, it is more scalable, but other than
threads I don't see any huge performance gains.
-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: XFS for 2.4

[Willy Tarreau]

On Wed, Dec 03, 2003 at 07:01:39PM +0000, bill davidsen wrote:
 
> Yes, a development tree is much different than a stable tree, and even
> though the number has gone to 2.6, it's very much a development tree, in
> that it's still being used by the same people, and probably not getting
> a lot of new testing. Stability is unlikely to be production quality
> until fixes go in for problems in mass testing, which won't happen until
> it shows up in a vendor release, which won't happen until the vendors
> test and clean up what they find... In other words, I don't expect it to
> be "really stable" for six months at least, maybe a year.

There even are people using 2.2 on production and/or desktop computers. I
know some of them. Many people jumped from 2.2 to 2.4 because of USB, but
since it was backported into 2.2.18, many people prefered to stick to 2.2.

> As for "much faster," let's say that I don't see that on any apples to
> apples benchmark. If you measure new threading against 2.4 threading
> there is a significant gain, but for anything else the gains just don't
> seem to warrant a "much" and there are some regressions shown in other
> people's data.

I second this. I've already tested several 2.5 and 2.6-test, and I'm
really deceived by the scheduler. It looks a lot more as a hack to
satisfy xmms users than something usable. I'm doing 'ls -ltr' all the
day in directories filled with 2000 files, and it takes ages to complete.
I'm even at the point to which I add a "|tail" to make things go faster.

For instance, time typically reports 0.03u, 0.03s, 2.8 real. It seems as
each line sent to xterm consumes one full clock tick doing nothing. I
never reported it yet because I don't have time to investigate, and it
seems more important that people don't hear skips in xmms while compiling
their kernel with "make -j 256" on a 16 MB machine. Second test : launch
10 times : xterm -e "find /" & and look how some windows freeze for up
to 10 seconds... I don't think this is a problem right now. We've seen
lots of work in the scheduler area, many people proposing theirs, and
this will stabilize once 2.6 is out and people start to describe what
they really do with it and what they feel.

Don't take me wrong, I don't want to whine nor offend anyone here. I
think that Ingo and other people like Con have done a very great job
at optimizing this scheduler. I just wish we could choose one depending
on what we want to do with it.

Just my 2 cents,
Willy

Re: XFS for 2.4

[bill davidsen]

In article <20031203204518.GA11325@alpha.home.local> you write:
| On Wed, Dec 03, 2003 at 07:01:39PM +0000, bill davidsen wrote:
|  
| > Yes, a development tree is much different than a stable tree, and even
| > though the number has gone to 2.6, it's very much a development tree, in
| > that it's still being used by the same people, and probably not getting
| > a lot of new testing. Stability is unlikely to be production quality
| > until fixes go in for problems in mass testing, which won't happen until
| > it shows up in a vendor release, which won't happen until the vendors
| > test and clean up what they find... In other words, I don't expect it to
| > be "really stable" for six months at least, maybe a year.
| 
| There even are people using 2.2 on production and/or desktop computers. I
| know some of them. Many people jumped from 2.2 to 2.4 because of USB, but
| since it was backported into 2.2.18, many people prefered to stick to 2.2.

I still have a 2.0.30 machine, not network connected, does what I want.
| 
| > As for "much faster," let's say that I don't see that on any apples to
| > apples benchmark. If you measure new threading against 2.4 threading
| > there is a significant gain, but for anything else the gains just don't
| > seem to warrant a "much" and there are some regressions shown in other
| > people's data.
| 
| I second this. I've already tested several 2.5 and 2.6-test, and I'm
| really deceived by the scheduler. It looks a lot more as a hack to
| satisfy xmms users than something usable. I'm doing 'ls -ltr' all the
| day in directories filled with 2000 files, and it takes ages to complete.
| I'm even at the point to which I add a "|tail" to make things go faster.

Just tried that, test11 seems better behaved. I've been running Nick's
patches, for general use they work better for me, I can stand a skip a
few times a day.
| 
| For instance, time typically reports 0.03u, 0.03s, 2.8 real. It seems as
| each line sent to xterm consumes one full clock tick doing nothing. I
| never reported it yet because I don't have time to investigate, and it
| seems more important that people don't hear skips in xmms while compiling
| their kernel with "make -j 256" on a 16 MB machine. Second test : launch
| 10 times : xterm -e "find /" & and look how some windows freeze for up
| to 10 seconds... I don't think this is a problem right now. We've seen
| lots of work in the scheduler area, many people proposing theirs, and
| this will stabilize once 2.6 is out and people start to describe what
| they really do with it and what they feel.
| 
| Don't take me wrong, I don't want to whine nor offend anyone here. I
| think that Ingo and other people like Con have done a very great job
| at optimizing this scheduler. I just wish we could choose one depending
| on what we want to do with it.

It has been proposed, but people more influentional than I, that
scheduling be a module with some base doorknob scheduler as default if
not better scheduler is chosen.
-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: XFS for 2.4

[Joel Becker]

On Wed, Dec 03, 2003 at 04:17:50PM -0500, bill davidsen wrote:
> In article <20031203204518.GA11325@alpha.home.local> you write:
> | I second this. I've already tested several 2.5 and 2.6-test, and I'm
> | really deceived by the scheduler. It looks a lot more as a hack to
> | satisfy xmms users than something usable. I'm doing 'ls -ltr' all the
> | day in directories filled with 2000 files, and it takes ages to complete.
> | I'm even at the point to which I add a "|tail" to make things go faster.
> 
> Just tried that, test11 seems better behaved. I've been running Nick's
> patches, for general use they work better for me, I can stand a skip a
> few times a day.

	Just another datapoint.  On my 300MHz PII laptop, ls and tab
completion often hang, taking up 100% CPU on -test11.  2.4.19-pre3-ac2,
my 2.4 kernel, doesn't even blip the CPU.
	That said, -test11 performs much better than 2.4.2[01], which
used to pause the system entirely for 30 seconds or more.
	If there are any knobs I can turn to tweak this, I'm interested.

Joel

-- 

Life's Little Instruction Book #347

	"Never waste the oppourtunity to tell someone you love them."

Joel Becker
Senior Member of Technical Staff
Oracle Corporation
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

Re: XFS for 2.4

[bill davidsen]

In article <20031203214819.GD11065@ca-server1.us.oracle.com>,
Joel Becker  <Joel.Becker@oracle.com> wrote:

| 	Just another datapoint.  On my 300MHz PII laptop, ls and tab
| completion often hang, taking up 100% CPU on -test11.  2.4.19-pre3-ac2,
| my 2.4 kernel, doesn't even blip the CPU.

That's funny! I'm running 2.4.19-pre2-ac2 plus three patches which
solved something I'd have to rethink to describe. But most of my laptops
suspend fine with APM and 2.4, and suspend fine with 2.6 and ACPI but
never return to life... I realize APM is depreciated with 2.6, so I'm
resigned to 2.4 on those machines.

| 	That said, -test11 performs much better than 2.4.2[01], which
| used to pause the system entirely for 30 seconds or more.
| 	If there are any knobs I can turn to tweak this, I'm interested.

The last time I tried Nick's patches was on test15, there are only so
many hours in my day, and my best test machine is slow enough to
discourage building a lot of kernels. You might see if his version 15
patches will work on test11, or if test10-mm1 works better for you.
Since you're looking for knobs... You might also look at the swappiness
(/proc/sys/vm/swappiness) to see if that changes the stuff which bugs
you. 
-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: XFS for 2.4

[Ed Sweetman]

bill davidsen wrote:
> In article <20031203204518.GA11325@alpha.home.local> you write:
> | On Wed, Dec 03, 2003 at 07:01:39PM +0000, bill davidsen wrote:
> |  
> | > Yes, a development tree is much different than a stable tree, and even
> | > though the number has gone to 2.6, it's very much a development tree, in
> | > that it's still being used by the same people, and probably not getting
> | > a lot of new testing. Stability is unlikely to be production quality
> | > until fixes go in for problems in mass testing, which won't happen until
> | > it shows up in a vendor release, which won't happen until the vendors
> | > test and clean up what they find... In other words, I don't expect it to
> | > be "really stable" for six months at least, maybe a year.
> | 
> | There even are people using 2.2 on production and/or desktop computers. I
> | know some of them. Many people jumped from 2.2 to 2.4 because of USB, but
> | since it was backported into 2.2.18, many people prefered to stick to 2.2.
> 
> I still have a 2.0.30 machine, not network connected, does what I want.
> | 
> | > As for "much faster," let's say that I don't see that on any apples to
> | > apples benchmark. If you measure new threading against 2.4 threading
> | > there is a significant gain, but for anything else the gains just don't
> | > seem to warrant a "much" and there are some regressions shown in other
> | > people's data.
> | 
> | I second this. I've already tested several 2.5 and 2.6-test, and I'm
> | really deceived by the scheduler. It looks a lot more as a hack to
> | satisfy xmms users than something usable. I'm doing 'ls -ltr' all the
> | day in directories filled with 2000 files, and it takes ages to complete.
> | I'm even at the point to which I add a "|tail" to make things go faster.
> 
> Just tried that, test11 seems better behaved. I've been running Nick's
> patches, for general use they work better for me, I can stand a skip a
> few times a day.
> | 
> | For instance, time typically reports 0.03u, 0.03s, 2.8 real. It seems as
> | each line sent to xterm consumes one full clock tick doing nothing. I
> | never reported it yet because I don't have time to investigate, and it
> | seems more important that people don't hear skips in xmms while compiling
> | their kernel with "make -j 256" on a 16 MB machine. Second test : launch
> | 10 times : xterm -e "find /" & and look how some windows freeze for up
> | to 10 seconds... I don't think this is a problem right now. We've seen
> | lots of work in the scheduler area, many people proposing theirs, and
> | this will stabilize once 2.6 is out and people start to describe what
> | they really do with it and what they feel.

The windows can freeze for many reasons. You could be running X in a 
lower priority, painting X terms is heavy on X using that command and it 
can steal cpu from the terminal who's process is working in retrieving 
data from the fs. No dma on the hdds, Etc.  I ran this command using 
test11 with akpm's test10-mm1 patch applied and 10 were going just fine. 
  All going at the same time along with mplayer playing a divx movie. No 
skips in video or audio and all the terminals were updating as rapidly 
as they could with no pauses of noticable length.
The schedular is nothing short of incredibly better than 2.4.x and 
prior.  Despite the xmms croud's loud cries of trying to get the kernel 
to fix their player's performance which seems to always suffer more than 
any other player i've tried.


> | Don't take me wrong, I don't want to whine nor offend anyone here. I
> | think that Ingo and other people like Con have done a very great job
> | at optimizing this scheduler. I just wish we could choose one depending
> | on what we want to do with it.
> 
> It has been proposed, but people more influentional than I, that
> scheduling be a module with some base doorknob scheduler as default if
> not better scheduler is chosen.

having to manually adjust the schedular is seen by many as a fault in 
the design of the schedular.  The perfect schedular would be able to 
adjust itself automatically on it's own.  If that's perfect, then even 
if it's likely impossible to achieve it, it makes sense to strive to get 
as close to it as possible rather than create a set of separate 
schedulars which the root user (which really shouldn't be doing anything 
on the system all the time anyway) has to select whenever their workload 
changes from one goal to another.

Re: XFS for 2.4

[Willy Tarreau]

On Wed, Dec 03, 2003 at 05:08:55PM -0500, Ed Sweetman wrote:
 
> The windows can freeze for many reasons. You could be running X in a 
> lower priority, painting X terms is heavy on X using that command and it 
> can steal cpu from the terminal who's process is working in retrieving 
> data from the fs. No dma on the hdds, Etc.

sorry I gave no info. disk is SCSI and is *not* sollicited at all because
everything fits in cache. If I was speaking about the scheduler, it's
because it's really a CU scheduling behaviour and not an I/O scheduling
behaviour. I never changed my X priority, and in 2.4, all windows are
fluid because timeslices are evenly distributed.

>  I ran this command using 
> test11 with akpm's test10-mm1 patch applied and 10 were going just fine. 
>  All going at the same time along with mplayer playing a divx movie. No 
> skips in video or audio and all the terminals were updating as rapidly 
> as they could with no pauses of noticable length.

bingo ! you're in the exact case where people try to detect skips in their
players. I suspect that your player and your xterms don't go too fast and
are detected as interactive task by the scheduler. So they don't go very
fast, but they are all fluid. Now if you can feed saturate a CPU by feeding
6000 lines/s to an xterm during 1 minute and can repeat this on 10 xterms,
they won't become interactive at all, and now you'll see that some of them
scroll smoothly while others are stopped. If you put your pointer into them
and strike a key, they often start again.

> The schedular is nothing short of incredibly better than 2.4.x and 
> prior.

I also think it's better for many workloads. I only say that we can easily
identify *some* workloads for which it simply fails to be fair, and although
these workload are not more representative than xmms while compiling a kernel,
they might match other applications' behaviour. For instance, I don't know
if a system which runs all the day at 100% CPU compressing logs asynchronously
won't suffer from this.

> Despite the xmms croud's loud cries of trying to get the kernel 
> to fix their player's performance which seems to always suffer more than 
> any other player i've tried.

I totally agree. I've used mpg123 from my old P166+ years ago, to my dual
xp1800 and on my notebooks, I've also tried madplay, and I've yet to hear
what a skip sounds like.

> having to manually adjust the schedular is seen by many as a fault in 
> the design of the schedular.  The perfect schedular would be able to 
> adjust itself automatically on it's own.

I don't agree here. No system knows better than the admin what he's doing.
If this was the case, the 'nice' command would never have been invented.

> if it's likely impossible to achieve it, it makes sense to strive to get 
> as close to it as possible rather than create a set of separate 
> schedulars which the root user (which really shouldn't be doing anything 
> on the system all the time anyway) has to select whenever their workload 
> changes from one goal to another.

The root you're talking about is also the same person who installs a server
for a dedicated task and sometimes the same person who discovered a profund
scheduling problem on the same system two racks away. As long as your systems
don't share their experiences, it's up to the humans to tell them.

Willy

Re: XFS for 2.4

[Clemens Schwaighofer]

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

Willy Tarreau wrote:
| On Wed, Dec 03, 2003 at 07:01:39PM +0000, bill davidsen wrote:

| For instance, time typically reports 0.03u, 0.03s, 2.8 real. It seems as
| each line sent to xterm consumes one full clock tick doing nothing. I
| never reported it yet because I don't have time to investigate, and it
| seems more important that people don't hear skips in xmms while compiling
| their kernel with "make -j 256" on a 16 MB machine. Second test : launch
| 10 times : xterm -e "find /" & and look how some windows freeze for up
| to 10 seconds... I don't think this is a problem right now. We've seen
| lots of work in the scheduler area, many people proposing theirs, and
| this will stabilize once 2.6 is out and people start to describe what
| they really do with it and what they feel.

Well, I had to try that here. I've got a Celeron 650Mhz with 320MB ram
and a crappy 14GB HD and yes the finds in the xterms are stopping for
some time ... BUT X is 100% responsive. there is no sluggishness, I can
use mozilla, etc without a problem. so seriously, who makes 10 finds at
the same time and finds are read from FS (I have XFS) so it might be a
problem with that. So I don't think the scheduler is bad, I think it is
great. When I switched to 2.5 the first time on that box it was like
"WOW", so little swapping and KDE is so smooth ... thats so wow ...

Still there are some minor problems (japanese keyboard eg) but that will
smooth out when Programs get adapted.

But for your problem, it might get better for these kind of things in
later versions :)

- --
Clemens Schwaighofer - IT Engineer & System Administration
==========================================================
Tequila Japan, 6-17-2 Ginza Chuo-ku, Tokyo 104-8167, JAPAN
Tel: +81-(0)3-3545-7703            Fax: +81-(0)3-3545-7343
http://www.tequila.jp
==========================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/zoEPjBz/yQjBxz8RAjsEAKCO3Nvs/5r/6HgRh9Z83T2SlQmfIgCfQHl5
jbHM0IQVD/buJjD/I2Shv9k=
=YOth
-----END PGP SIGNATURE-----

Re: XFS for 2.4

[Willy Tarreau]

On Thu, Dec 04, 2003 at 09:34:23AM +0900, Clemens Schwaighofer wrote:
 
> Well, I had to try that here. I've got a Celeron 650Mhz with 320MB ram
> and a crappy 14GB HD and yes the finds in the xterms are stopping for
> some time ... BUT X is 100% responsive.  there is no sluggishness, I can
> use mozilla, etc without a problem. so seriously, who makes 10 finds at
> the same time and finds are read from FS (I have XFS) so it might be a
> problem with that.

This exact workload is probably not needed by anybody. But my concern is
that if it fails here, then possibily other realistic workloads will fail
too. But since it's hard to identify, that's why I'm waiting for distros
to ship first releases, and for a few people to tell us about particular
cases where they are annoyed. Ingo, Con, Nick and others obviously cannot
make the greatest scheduler in the world without valuable feedback. And
I have the feeling that all they got was "bad...bad...bad.. STOP!! don't
touch anything, XMMS is now great".

Production workloads are typically different. Perhaps my 10 xterms produce
the same type of load as 10 persons grepping gigs of logs from memory ?
And perhaps my "ls -ltr" produce the same workload as... someone searching
a recent file with "ls -ltr".

> So I don't think the scheduler is bad, I think it is
> great. When I switched to 2.5 the first time on that box it was like
> "WOW", so little swapping and KDE is so smooth ... thats so wow ...

I too think it's great and smoother than 2.4. It obviously makes a difference
if you use X (and I don't use these KDE, etc...). But the smoothness was
also brought to 2.4 by patches such as rmap, preempt, variable-hz. All of
them have been merged into 2.6, so we cannot deny that they helped too.

> But for your problem, it might get better for these kind of things in
> later versions :)

-test10 was NOK. I'll try test11, and when I've time I'll try Nick's
scheduler too.

Cheers,
Willy

Re: XFS for 2.4

[Clemens Schwaighofer]

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

Willy Tarreau wrote:
| On Thu, Dec 04, 2003 at 09:34:23AM +0900, Clemens Schwaighofer wrote:

| Production workloads are typically different. Perhaps my 10 xterms produce
| the same type of load as 10 persons grepping gigs of logs from memory ?
| And perhaps my "ls -ltr" produce the same workload as... someone searching
| a recent file with "ls -ltr"

well I don't know, I don't use this box full time, but quite a lot, I do
a lot of compiling on it. Run Mozilla, etc on it, copy big files, etc,
but I never had any serious "lock" problems, where everthing freezes for
a second like I have from time to time in 2.4

|>So I don't think the scheduler is bad, I think it is
|>great. When I switched to 2.5 the first time on that box it was like
|>"WOW", so little swapping and KDE is so smooth ... thats so wow ...
|
|
| I too think it's great and smoother than 2.4. It obviously makes a
difference
| if you use X (and I don't use these KDE, etc...). But the smoothness was
| also brought to 2.4 by patches such as rmap, preempt, variable-hz. All of
| them have been merged into 2.6, so we cannot deny that they helped too.

well on my working bux I run 2.4.22-ck3 and this has a lot of preempt
workstation speedup stuff inside, but it still freezes from time to time
if there is a peak in workload.

|>But for your problem, it might get better for these kind of things in
|>later versions :)
|
| -test10 was NOK. I'll try test11, and when I've time I'll try Nick's
| scheduler too.

well test11 is very smooth. I haven't tried Nick scheduler but I might
give it a shot, just to see how the "xterm craziness" goes ... :)

- --
Clemens Schwaighofer - IT Engineer & System Administration
==========================================================
Tequila Japan, 6-17-2 Ginza Chuo-ku, Tokyo 104-8167, JAPAN
Tel: +81-(0)3-3545-7703            Fax: +81-(0)3-3545-7343
http://www.tequila.jp
==========================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/zwjGjBz/yQjBxz8RAmJyAJ4jA3q9yqaYxIjI3PT1ueHHwjUeuACeOWdS
Lp4cfDBErPBrd0df27xRygY=
=ffb4
-----END PGP SIGNATURE-----

Re: XFS for 2.4

[Marcelo Tosatti]

On Tue, 2 Dec 2003, Nathan Scott wrote:

> On Mon, Dec 01, 2003 at 12:06:14PM -0200, Marcelo Tosatti wrote:
> > On Mon, 1 Dec 2003, Nathan Scott wrote:
> > 
> > > Hi Marcelo,
> > > 
> > > Please do a
> > > 
> > > 	bk pull http://xfs.org:8090/linux-2.4+coreXFS
> > > 
> > > This will merge the core 2.4 kernel changes required for supporting
> > > the XFS filesystem, as listed below.  If this all looks acceptable,
> > > then please also pull the filesystem-specific code (fs/xfs/*)
> > > 
> > > 	bk pull http://xfs.org:8090/linux-2.4+justXFS
> > 
> > Nathan, 
> > 
> > I think XFS should be a 2.6 only feature.
> > 
> > 2.6 is already stable enough for people to use it. 
> > 
> 
> Hi Marcelo,
> 
> Please reconsider -- the "core" kernel changes we need have existed
> for three+ years outside of the mainline tree, and each is a small
> and easily understood change that doesn't affect other filesystems.
> There is also a VFS fix in there from Ethan Benson, as we discussed
> during 2.4.23-pre, when you asked us to resend XFS for 2.4.24-pre!)
> Everything there is a backport from 2.6 in some form, there should
> be no surprises.

Nathan,

I remember I have said to you "resend me XFS for 2.4.24-pre". A changed my 
mind since then...

> Not having XFS in 2.4 is extremely disadvantageous for us XFS folks
> (especially since every other journaled filesystem has been merged
> now).  

JFS did not touch generic code as I remember.

> To our users it means some rescue disks simply don't support
> XFS, meaning you can't mount filesystems when you _really_ need to,
> etc, etc.  Its also always extra work for distributors to merge XFS
> themselves, and hence a few just don't (and occasionally tell us
> that they are waiting for you to merge it) - which means some users
> don't even get the option of using XFS, despite our best efforts.

Come one, it is not so hard to maintain a patch in a distros kernel.  

Distros maintain hundreds of patches (even I did maintain hundreds of
patches while maintaining Conectiva's RPM). One more patch is not that
hard.

> From discussions with distributors, a stable 2.6 distribution will
> be many months after 2.6.0 is officially released, so these issues
> are not going to go away anytime soon.

Fine, so people who want XFS go compile 2.6.0 by hand. I'm using test11 on
several boxes and its working very well.

And 2.6 is much nicer than 2.4 anyway.

> So, please merge XFS this time round - its actively developed, has
> a large installed user base, and has been maintained outside of 2.4
> for a long time.  We have waited patiently as each release goes by
> for you to give us the nod, and have been knocked back on a number
> of occasions while various other merges are being done.

Also I'm not completly sure if the generic changes are fine and I dont
like the XFS code in general.

Re: XFS for 2.4

[Marcelo Tosatti]

On Tue, 2 Dec 2003, Marcelo Tosatti wrote:

> 
> 
> On Tue, 2 Dec 2003, Nathan Scott wrote:
> 
> > On Mon, Dec 01, 2003 at 12:06:14PM -0200, Marcelo Tosatti wrote:
> > > On Mon, 1 Dec 2003, Nathan Scott wrote:
> > > 
> > > > Hi Marcelo,
> > > > 
> > > > Please do a
> > > > 
> > > > 	bk pull http://xfs.org:8090/linux-2.4+coreXFS
> > > > 
> > > > This will merge the core 2.4 kernel changes required for supporting
> > > > the XFS filesystem, as listed below.  If this all looks acceptable,
> > > > then please also pull the filesystem-specific code (fs/xfs/*)
> > > > 
> > > > 	bk pull http://xfs.org:8090/linux-2.4+justXFS
> > > 
> > > Nathan, 
> > > 
> > > I think XFS should be a 2.6 only feature.
> > > 
> > > 2.6 is already stable enough for people to use it. 
> > > 
> > 
> > Hi Marcelo,
> > 
> > Please reconsider -- the "core" kernel changes we need have existed
> > for three+ years outside of the mainline tree, and each is a small
> > and easily understood change that doesn't affect other filesystems.
> > There is also a VFS fix in there from Ethan Benson, as we discussed
> > during 2.4.23-pre, when you asked us to resend XFS for 2.4.24-pre!)
> > Everything there is a backport from 2.6 in some form, there should
> > be no surprises.
> 
> Nathan,
> 
> I remember I have said to you "resend me XFS for 2.4.24-pre". A changed my 
> mind since then...
> 
> > Not having XFS in 2.4 is extremely disadvantageous for us XFS folks
> > (especially since every other journaled filesystem has been merged
> > now).  
> 
> JFS did not touch generic code as I remember.
> 
> > To our users it means some rescue disks simply don't support
> > XFS, meaning you can't mount filesystems when you _really_ need to,
> > etc, etc.  Its also always extra work for distributors to merge XFS
> > themselves, and hence a few just don't (and occasionally tell us
> > that they are waiting for you to merge it) - which means some users
> > don't even get the option of using XFS, despite our best efforts.
> 
> Come one, it is not so hard to maintain a patch in a distros kernel.  

s/one/on/

Ugh

Re: XFS for 2.4

[Russell Cattelan]

On Tue, 2003-12-02 at 05:18, Marcelo Tosatti wrote:
[snip] 
> Also I'm not completly sure if the generic changes are fine and I dont
> like the XFS code in general.
Ahh so the real truth comes out.


Is there a reason for your sudden dislike of the XFS code?
or is this just an arbitrary general dislike for unknown or
unstated reasons?


-- 
Russell Cattelan <cattelan@thebarn.com>

Re: XFS for 2.4

[Marcelo Tosatti]

On Tue, 2 Dec 2003, Russell Cattelan wrote:

> On Tue, 2003-12-02 at 05:18, Marcelo Tosatti wrote:
> [snip] 
> > Also I'm not completly sure if the generic changes are fine and I dont
> > like the XFS code in general.
> Ahh so the real truth comes out.
> 
> 
> Is there a reason for your sudden dislike of the XFS code?

I always disliked the XFS code. 

> or is this just an arbitrary general dislike for unknown or unstated
> reasons?

I dont like the style of the code. Thats a personal issue, though, and 
shouldnt matter.

The bigger point is that XFS touches generic code and I'm not sure if that 
can break something.

Why it matters so much for you to have XFS in 2.4 ? 

Re: XFS for 2.4

[Darrell Michaud]

As a user it would be very beneficial for me to have XFS support in the
official 2.4 kernel tree. XFS been stable and "2.4 integration-ready"
for a long time, and 2.4 is going to be used in certain environments for
a long time, if only because it's easier to upgrade a 2.4 kernel to a
newer 2.4 kernel than to upgrade to a 2.6 kernel. It seems like an easy
case to make.

I use other filesystems and some funky drivers as well.. and I'm always
very happy to see useful backports show up in the 2.4 tree. Thank you!



On Tue, 2003-12-02 at 10:50, Marcelo Tosatti wrote:
> On Tue, 2 Dec 2003, Russell Cattelan wrote:
> 
> > On Tue, 2003-12-02 at 05:18, Marcelo Tosatti wrote:
> > [snip] 
> > > Also I'm not completly sure if the generic changes are fine and I dont
> > > like the XFS code in general.
> > Ahh so the real truth comes out.
> > 
> > 
> > Is there a reason for your sudden dislike of the XFS code?
> 
> I always disliked the XFS code. 
> 
> > or is this just an arbitrary general dislike for unknown or unstated
> > reasons?
> 
> I dont like the style of the code. Thats a personal issue, though, and 
> shouldnt matter.
> 
> The bigger point is that XFS touches generic code and I'm not sure if that 
> can break something.
> 
> Why it matters so much for you to have XFS in 2.4 ? 
> 
-- 
Darrell Michaud <dmichaud@wsi.com>

Re: XFS for 2.4

[Austin Gonyou]

I second this as well. I'm sure there are others. XFS is a good option
to have for official FS inclusion and I'm *very* happy it's in 2.6. If
it were in 2.4, that *may* make adoption of 2.6 for some, slow in coming
along. While that may be true, I see that most will eventually want to
take advantage of all 2.6 has to offer, but if XFS were in the official
tree, then that may be one less piece of guess work needed when
upgrading from 2.4 to 2.6 with regards to FS maintenance. (i.e. same
version of XFS in both trees == possible same reliability, etc)

On Tue, 2003-12-02 at 10:10, Darrell Michaud wrote:
> As a user it would be very beneficial for me to have XFS support in
> the
> official 2.4 kernel tree. XFS been stable and "2.4 integration-ready"
> for a long time, and 2.4 is going to be used in certain environments
> for
> a long time, if only because it's easier to upgrade a 2.4 kernel to a
> newer 2.4 kernel than to upgrade to a 2.6 kernel. It seems like an
> easy
> case to make.
> 
> I use other filesystems and some funky drivers as well.. and I'm
> always
> very happy to see useful backports show up in the 2.4 tree. Thank you!
> 
> 
> 
> On Tue, 2003-12-02 at 10:50, Marcelo Tosatti wrote:
> > On Tue, 2 Dec 2003, Russell Cattelan wrote:
> > 
> > > On Tue, 2003-12-02 at 05:18, Marcelo Tosatti wrote:
> > > [snip] 
> > > > Also I'm not completly sure if the generic changes are fine and
> I dont
> > > > like the XFS code in general.
> > > Ahh so the real truth comes out.
> > > 
> > > 
> > > Is there a reason for your sudden dislike of the XFS code?
> > 
> > I always disliked the XFS code. 
> > 
> > > or is this just an arbitrary general dislike for unknown or
> unstated
> > > reasons?
> > 
> > I dont like the style of the code. Thats a personal issue, though,
> and 
> > shouldnt matter.
> > 
> > The bigger point is that XFS touches generic code and I'm not sure
> if that 
> > can break something.
> > 
> > Why it matters so much for you to have XFS in 2.4 ? 
> > 
> -- 
> Darrell Michaud <dmichaud@wsi.com>
-- 
Austin Gonyou <austin@coremetrics.com>
Coremetrics, Inc.

Re: XFS for 2.4

[Jeff Garzik]

On Tue, Dec 02, 2003 at 11:10:43AM -0500, Darrell Michaud wrote:
> As a user it would be very beneficial for me to have XFS support in the
> official 2.4 kernel tree. XFS been stable and "2.4 integration-ready"
> for a long time, and 2.4 is going to be used in certain environments for
> a long time, if only because it's easier to upgrade a 2.4 kernel to a
> newer 2.4 kernel than to upgrade to a 2.6 kernel. It seems like an easy
> case to make.
> 
> I use other filesystems and some funky drivers as well.. and I'm always
> very happy to see useful backports show up in the 2.4 tree. Thank you!

This can also be done in patch form, as it is done now :)

There are several pieces of backported software that are
integration-ready, but that doesn't imply they should go into an
increasingly-frozen 2.4.x tree...

	Jeff

Re: XFS for 2.4

[venom]

On Tue, 2 Dec 2003, Jeff Garzik wrote:

>
> This can also be done in patch form, as it is done now :)
>

of course.
2.4 systems that are already using XFS as a patch probably would have a benefit
to see it integrated into 2.4 kernel, but they would is it anyway as a patch.

I do not think the merge would be usefull thinking to a from2.4/to2.6 upgrade.
In fact, if a system is not using XFS already, it is difficoult
that a filesystem is changed if it is an upgrade and not a reinstallation.

So, at the end, to have XFS just as a patch for 2.4 is not so bad.

Luigi

Re: XFS for 2.4

[Stefan Smietanowski]

Jeff Garzik wrote:

> On Tue, Dec 02, 2003 at 11:10:43AM -0500, Darrell Michaud wrote:
> 
>>As a user it would be very beneficial for me to have XFS support in the
>>official 2.4 kernel tree. XFS been stable and "2.4 integration-ready"
>>for a long time, and 2.4 is going to be used in certain environments for
>>a long time, if only because it's easier to upgrade a 2.4 kernel to a
>>newer 2.4 kernel than to upgrade to a 2.6 kernel. It seems like an easy
>>case to make.
>>
>>I use other filesystems and some funky drivers as well.. and I'm always
>>very happy to see useful backports show up in the 2.4 tree. Thank you!
> 
> 
> This can also be done in patch form, as it is done now :)
> 
> There are several pieces of backported software that are
> integration-ready, but that doesn't imply they should go into an
> increasingly-frozen 2.4.x tree...

Good point, however the XFS code has been ready for way longer
than some other things that were integrated have existed at all.

There was a question to merge XFS before 2.4 but the answer was no
then. That was eons ago and reiserfs and JFS has made it in since then
but not XFS. That strikes me as odd. Everybody have been patient and
changing the code according to how it might get accepted and it still
hasn't been merged. Many people have run XFS for a long time and while
they can use the same way they do now (xfs-patches or precompiled RPM)
I don't see a motivation not to include it, especially seeing that
other filesystems got in. True XFS touches some generic code but
if that really is an issue, why don't people sit down and look at the
changes (again) and see what can be changed. If that's the reason.

// Stefan

Re: XFS for 2.4

[Russell Cattelan]

On Tue, 2003-12-02 at 09:50, Marcelo Tosatti wrote:
> On Tue, 2 Dec 2003, Russell Cattelan wrote:
> 
> > On Tue, 2003-12-02 at 05:18, Marcelo Tosatti wrote:
> > [snip] 
> > > Also I'm not completly sure if the generic changes are fine and I dont
> > > like the XFS code in general.
> > Ahh so the real truth comes out.
> > 
> > 
> > Is there a reason for your sudden dislike of the XFS code?
> 
> I always disliked the XFS code. 
> 
> > or is this just an arbitrary general dislike for unknown or unstated
> > reasons?
> 
> I dont like the style of the code. Thats a personal issue, though, and 
> shouldnt matter.
True... so are you basing your decision to not include it on some thing
technical or just your personal feeling? which in your words "shouldn't
matter" 
> 
> The bigger point is that XFS touches generic code and I'm not sure if that 
> can break something.
We have taken great pain to make sure the generic code changes do not
logically change any code paths.
Everything is either new code paths only used by XFS or very careful
conditionals on flags only set by XFS.
Some of the changes that were made to generic code was done because it
was the right way to it. It would certainly would be possible pull many
of the needed changes back into fs/xfs but then there would be
duplicated  code that could potentially be wrong if somebody changes the
generic routines. (core locking differences in different kernels have
bitten us in the past, RedHat kernel are good at this)

If you really have issues with any of the core changes please make some
suggestions it's possible things could be done differently.


> 
> Why it matters so much for you to have XFS in 2.4 ? 
Well if you follow that logic then why did any of the other filesystems
go in? in fact why would any new subsystems go in?
Everybody maintaining a large pile of patches should be sufficient to
call something linux?

Take anybody list of reasons for inclusion into core.
Acceptance
Larger audience, possible exposure in other projects that won't look
at XFS due the extra work of merging their patches with ours
Ease the support work needed to integrate with all the different distro
More feed back for interfaces

Re: XFS for 2.4

[Jeremy Jackson]

I think the dislike is justified.  XFS is kind of like an alien parasite 
attached to Linux.  IRIX's IO system is different, it's taken a lot of 
changes.  I still think it is the best filesystem with a lot of unused 
potential though.  I hope it will eventually be well integrated - 
2.6/2.8.  It's only the generic code changes we need to worry about 
though, right?

Regards,

Jeremy Jackson

Russell Cattelan wrote:
> On Tue, 2003-12-02 at 05:18, Marcelo Tosatti wrote:
> [snip] 
> 
>>Also I'm not completly sure if the generic changes are fine and I dont
>>like the XFS code in general.
> 
> Ahh so the real truth comes out.
> 
> 
> Is there a reason for your sudden dislike of the XFS code?
> or is this just an arbitrary general dislike for unknown or
> unstated reasons?
> 
> 

Re: XFS for 2.4

[Clemens Schwaighofer]

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

Marcelo Tosatti wrote:

| Nathan,
|
| I think XFS should be a 2.6 only feature.
|
| 2.6 is already stable enough for people to use it.

It is not. It is still in development, and even if a 2.6.0 is
released I just think back to 2.4.0, just because it is called stable
doesn't make it stable.
I am sure it will need at least half a year for the major distros
(RedHat, Novell/SuSe, Mandrake) to pick it up. Perhaps some others more
earlier (Gentoo who knows), some never (Debian), but still, in the mean
time it is always a bit tricky with kernel updats here. Either I patch
it with the SGI and might have troubles with other patches, or I take
the -ac (which didn't work last time because of some driver problems
with the HP/Compaq Raid) or I take the -ck which is a Desktop patchset
and not a server patchset ...
Well in just my opinion XFS should go into 2.4 (and not only because ALL
other FS are in there already). 2.4 will be the main kernel for quite
some more time and always come up with the argument "but 2.6 is so
ready" doesn't help ...

- --
Clemens Schwaighofer - IT Engineer & System Administration
==========================================================
Tequila Japan, 6-17-2 Ginza Chuo-ku, Tokyo 104-8167, JAPAN
Tel: +81-(0)3-3545-7703            Fax: +81-(0)3-3545-7343
http://www.tequila.jp
==========================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/y+IKjBz/yQjBxz8RAlmAAJ44ixaLQ0UWX+y3pfM3AGJplJ/VdwCfSHP8
ghIZWUtwQhg+ZHU/iN4obzI=
=KfM2
-----END PGP SIGNATURE-----

Re: XFS for 2.4

[Marcos D. Marado Torres]

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

On Tue, 2 Dec 2003, Clemens Schwaighofer wrote:

[...]
> time it is always a bit tricky with kernel updats here. Either I patch
> it with the SGI and might have troubles with other patches, or I take
> the -ac (which didn't work last time because of some driver problems
> with the HP/Compaq Raid) or I take the -ck which is a Desktop patchset
> and not a server patchset ...
[...]

As a replacement to the -ac patches, you can allways use the -pac patches
(currently 2.4.23-pac1).

Greetings,
Mind Booster Noori

- --
==================================================
Marcos Daniel Marado Torres AKA Mind Booster Noori
/"\               http://student.dei.uc.pt/~marado
\ /                       marado@student.dei.uc.pt
 X   ASCII Ribbon Campaign
/ \  against HTML e-mail and Micro$oft attachments
==================================================

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Made with pgp4pine 1.76

iD8DBQE/y+pbmNlq8m+oD34RAg2hAJ48v2ZqMNxsHIcepJPttZo1Qk+kJgCfWh6c
jccDjXLdPDBUncc014Ce104=
=0+lU
-----END PGP SIGNATURE-----

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

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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: XFS for 2.4

[Dan Yocum]

Marcelo,

We (Fermilab) second this request.  We won't be touching 2.6 until it's 
really stable (read as, Red Hat comes out with an official distro that has 
it built in), and we already have *a lot* of XFS filesystems here (~>300TB) 
running on 2.4 kernels.  It would be very, very nice to have it in the 2.4 
tree without having to pull it from SGI.

Thanks,
Dan


Nathan Scott wrote:
> Hi Marcelo,
> 
> Please do a
> 
> 	bk pull http://xfs.org:8090/linux-2.4+coreXFS
> 
> This will merge the core 2.4 kernel changes required for supporting
> the XFS filesystem, as listed below.  If this all looks acceptable,
> then please also pull the filesystem-specific code (fs/xfs/*)
> 
> 	bk pull http://xfs.org:8090/linux-2.4+justXFS
> 
> cheers.
> 

-- 
Dan Yocum
Sloan Digital Sky Survey, Fermilab  630.840.6509
yocum@fnal.gov, http://www.sdss.org
SDSS.  Mapping the Universe.  You are here.

Re: XFS for 2.4

[Bryan Whitehead]

I'd like to "third" this request. Have a large amount of data here on 
XFS with v2.4 kernel.

Would be nice to be able to use pre-release 2.4 for testing without 
having to manually hack in XFS paches from SGI for the odd reject...

Dan Yocum wrote:
> Marcelo,
> 
> We (Fermilab) second this request.  We won't be touching 2.6 until it's 
> really stable (read as, Red Hat comes out with an official distro that 
> has it built in), and we already have *a lot* of XFS filesystems here 
> (~>300TB) running on 2.4 kernels.  It would be very, very nice to have 
> it in the 2.4 tree without having to pull it from SGI.
> 
> Thanks,
> Dan
> 
> 
> Nathan Scott wrote:
> 
>> Hi Marcelo,
>>
>> Please do a
>>
>>     bk pull http://xfs.org:8090/linux-2.4+coreXFS
>>
>> This will merge the core 2.4 kernel changes required for supporting
>> the XFS filesystem, as listed below.  If this all looks acceptable,
>> then please also pull the filesystem-specific code (fs/xfs/*)
>>
>>     bk pull http://xfs.org:8090/linux-2.4+justXFS
>>
>> cheers.
>>
> 


-- 
Bryan Whitehead
SysAdmin - JPL - Interferometry and Large Optical Systems
Phone: 818 354 2903
driver@jpl.nasa.gov

Re: XFS for 2.4

[Jeffrey E. Hundstad]

I'd like to add my vote also.  I've been using XFS for years.  The XFS 
patches work well.  But having them in the standard kernel would be very 
nice.

-- 
jeffrey hundstad

Bryan Whitehead wrote:

> I'd like to "third" this request. Have a large amount of data here on 
> XFS with v2.4 kernel.
>
> Would be nice to be able to use pre-release 2.4 for testing without 
> having to manually hack in XFS paches from SGI for the odd reject...
>
> Dan Yocum wrote:
>
>> Marcelo,
>>
>> We (Fermilab) second this request.  We won't be touching 2.6 until 
>> it's really stable (read as, Red Hat comes out with an official 
>> distro that has it built in), and we already have *a lot* of XFS 
>> filesystems here (~>300TB) running on 2.4 kernels.  It would be very, 
>> very nice to have it in the 2.4 tree without having to pull it from SGI.
>>
>> Thanks,
>> Dan
>>
>>
>> Nathan Scott wrote:
>>
>>> Hi Marcelo,
>>>
>>> Please do a
>>>
>>>     bk pull http://xfs.org:8090/linux-2.4+coreXFS
>>>
>>> This will merge the core 2.4 kernel changes required for supporting
>>> the XFS filesystem, as listed below.  If this all looks acceptable,
>>> then please also pull the filesystem-specific code (fs/xfs/*)
>>>
>>>     bk pull http://xfs.org:8090/linux-2.4+justXFS
>>>
>>> cheers.
>>>
>>
>
>

Re: XFS for 2.4

[Gerardo Exequiel Pozzi]

On Mon, 01 Dec 2003 13:50:08 -0800, Bryan Whitehead wrote:
>I'd like to "third" this request. Have a large amount of data here on 
>XFS with v2.4 kernel.
>
>Would be nice to be able to use pre-release 2.4 for testing without 
>having to manually hack in XFS paches from SGI for the odd reject...
>

Yes, exactly. 

Ok the XFS changes some vfs code, but works OK, and is in the -ac and -ck trees.

And another point is make the possiblility to add some patchs such as security
without hunks failed, and another funny hacks.

And the majority of distros include it.

Another vote.

chau,
 djgera


>Dan Yocum wrote:
>> Marcelo,
>> 
>> We (Fermilab) second this request.  We won't be touching 2.6 until it's 
>> really stable (read as, Red Hat comes out with an official distro that 
>> has it built in), and we already have *a lot* of XFS filesystems here 
>> (~>300TB) running on 2.4 kernels.  It would be very, very nice to have 
>> it in the 2.4 tree without having to pull it from SGI.
>> 
>> Thanks,
>> Dan
>> 
>> 
>> Nathan Scott wrote:
>> 
>>> Hi Marcelo,
>>>
>>> Please do a
>>>
>>>     bk pull http://xfs.org:8090/linux-2.4+coreXFS
>>>
>>> This will merge the core 2.4 kernel changes required for supporting
>>> the XFS filesystem, as listed below.  If this all looks acceptable,
>>> then please also pull the filesystem-specific code (fs/xfs/*)
>>>
>>>     bk pull http://xfs.org:8090/linux-2.4+justXFS
>>>
>>> cheers.
>>>
>> 
>
>
>-- 
>Bryan Whitehead
>SysAdmin - JPL - Interferometry and Large Optical Systems
>Phone: 818 354 2903
>driver@jpl.nasa.gov

-- 
Gerardo Exequiel Pozzi ( djgera )
http://www.vmlinuz.com.ar http://www.djgera.com.ar
KeyID: 0x1B8C330D
Key fingerprint = 0CAA D5D4 CD85 4434 A219  76ED 39AB 221B 1B8C 330D

Re: XFS for 2.4

[Joshua Schmidlkofer]

On Mon, 2003-12-01 at 13:50, Bryan Whitehead wrote:
> I'd like to "third" this request. Have a large amount of data here on 
> XFS with v2.4 kernel.
> 
> Would be nice to be able to use pre-release 2.4 for testing without 
> having to manually hack in XFS paches from SGI for the odd reject...
> 
> Dan Yocum wrote:
> > Marcelo,
> > 
> > We (Fermilab) second this request.  We won't be touching 2.6 until it's 
> > really stable (read as, Red Hat comes out with an official distro that 
> > has it built in), and we already have *a lot* of XFS filesystems here 
> > (~>300TB) running on 2.4 kernels.  It would be very, very nice to have 
> > it in the 2.4 tree without having to pull it from SGI.
> > 
> > Thanks,
> > Dan

I would like to 'me too' - like some brain dead aoler.

I have 40+ machines which use XFS, and I have used it since the 1.0 was
released.  There are various servers, running a variety of services,
etc.  I think that the SGI team has done a fantastic job of supporting
2.4, and I have been using with no problems since 2.4.12.

I don't want to dis anyone either, but XFS is the filesystem that I use
because it is stable, and reliable, and IMHO mature.  I appreciate ext3,
Reiser, and especially JFS! However, XFS was ready first, and it was a
great disappointment not to see it in 2.4.  2.4 was truly a kernel of
pain in the beginning, and I repect the decision not to include it up
till now.  Not that it matters, but I will respect the decision of the
2.4 maintainers on this.  I do ask for 2.4, as a person who uses XFS on
all my personal, friends, mom's, and clients' systems.  Some of my
clients will not use it because it is not in the vanilla tree.  Please
reconsider on behalf of a wide body of users.

thanks,
  Joshua Schmidlkofer

Re: XFS for 2.4

[Maciej Soltysiak]

> We (Fermilab) second this request.  We won't be touching 2.6 until it's
I, an ordinary user, also second it. I have been using XFS, but some day I
just
got tired of patching the kernel and backed up the data and switched to
other filesystem.

I really liked XFS.

Regards,
Maciej

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

[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

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

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