New Debian packages

New Debian packages

[Steinar H. Gunderson]

Ian,

I uploaded a couple of new autofs versions to the Debian archive today; you
might be interested in some of the patches (mostly minor stuff, like backing
down on "set -e" in the init scripts, but there's an odd bugfix in places).
Should I send them one by one, or do you just get 4.1.3+4.1.4beta2-7 out of
the archive and pick out the patches yourself?

BTW, we're freezing really soon, so if you want something into the Debian
version in time for sarge, now is probably the time. :-)

/* Steinar */
-- 
Homepage: http://www.sesse.net/

Re: New Debian packages

[Ian Kent]

On Sun, 3 Apr 2005, Steinar H. Gunderson wrote:

> Ian,
> 
> I uploaded a couple of new autofs versions to the Debian archive today; you
> might be interested in some of the patches (mostly minor stuff, like backing
> down on "set -e" in the init scripts, but there's an odd bugfix in places).
> Should I send them one by one, or do you just get 4.1.3+4.1.4beta2-7 out of
> the archive and pick out the patches yourself?

I've also been working on this.

I've taken my lead from Debian bug report discussions.
I'll check your patches before I put out a new version.

> 
> BTW, we're freezing really soon, so if you want something into the Debian
> version in time for sarge, now is probably the time. :-)

I'm tempted to release 4.1.4. Most of the current issues are with the 
Debian portion of the init script which we have been working on.

Do you think we can get this bit right and go straight to release?

Ian

Re: New Debian packages

[Steinar H. Gunderson]

On Mon, Apr 04, 2005 at 10:51:36AM +0800, Ian Kent wrote:
> I'm tempted to release 4.1.4. Most of the current issues are with the 
> Debian portion of the init script which we have been working on.
> 
> Do you think we can get this bit right and go straight to release?

The only gripe I can find seems to be the replication, but that is probably
too much to fix for 4.1.4. So a release seems OK, yes.

/* Steinar */
-- 
Homepage: http://www.sesse.net/

Re: New Debian packages

[Ian Kent]

On Mon, 4 Apr 2005, Steinar H. Gunderson wrote:

> On Mon, Apr 04, 2005 at 10:51:36AM +0800, Ian Kent wrote:
> > I'm tempted to release 4.1.4. Most of the current issues are with the 
> > Debian portion of the init script which we have been working on.
> > 
> > Do you think we can get this bit right and go straight to release?
> 
> The only gripe I can find seems to be the replication, but that is probably
> too much to fix for 4.1.4. So a release seems OK, yes.

Do you mean the replicated server code. Yes it was broken and still needs 
more work. However I've tickled it again and it should be at least 
functional.

Ian

Re: New Debian packages

[Ian Kent]

On Sun, 3 Apr 2005, Steinar H. Gunderson wrote:

> Ian,
>
> I uploaded a couple of new autofs versions to the Debian archive today; you
> might be interested in some of the patches (mostly minor stuff, like backing
> down on "set -e" in the init scripts, but there's an odd bugfix in places).
> Should I send them one by one, or do you just get 4.1.3+4.1.4beta2-7 out of
> the archive and pick out the patches yourself?

I've checked the patches and here's what I've got:

052 - applied
053 - equivalent change already in place
054 - backout my changes and apply
055 - will apply
056 & 57 - will apply but think scripts are now Boune shell complaint
058 - equivalent change already in place
059 - applied

So this looks good to me.

>
> BTW, we're freezing really soon, so if you want something into the Debian
> version in time for sarge, now is probably the time. :-)

Do we have enough time for another beta and some testing time or prehaps it's
release time given the above.

I need to test localy after I make these changes anyway so it's going to
be a couple of more days.

Ian

Re: New Debian packages

[Steinar H. Gunderson]

On Tue, Apr 05, 2005 at 08:05:31PM +0800, Ian Kent wrote:
> 053 - equivalent change already in place

Note that there already was an "equivalent" change in beta2, but it was
wrong. Have you fixed it properly this time? :-)

> Do we have enough time for another beta and some testing time or prehaps it's
> release time given the above.

The version number doesn't really matter to me, so call it whatever you'd
like; 4.1.4 would probably be fine.

/* Steinar */
-- 
Homepage: http://www.sesse.net/

Re: New Debian packages

[Ian Kent]

On Tue, 5 Apr 2005, Steinar H. Gunderson wrote:

> On Tue, Apr 05, 2005 at 08:05:31PM +0800, Ian Kent wrote:
> > 053 - equivalent change already in place
> 
> Note that there already was an "equivalent" change in beta2, but it was
> wrong. Have you fixed it properly this time? :-)

Think so.
That's the nsswitch.conf tab problem.

Ian

sgi IRIX-6.5 autofs

[Greg Bradner]

I have a situation on IRIX where I am stat'ing a filesystem that is not 
exported to the IRIX system.  The syslog says 'permission denied'.  
That's expected.  Since the directory I'm in has 600 links to the file 
system that is not exported, autofs keeps trying to mount and keeps 
getting 'permission denied'.

On linux I get 'permission denied', but it doesn't try to mount again 
for 30 minutes.

Has anyone heard of such a problem with IRIX's autofs and is there a fix?
Why does linux only try every 30 minutes?
TIA.

IRIX system:
 > uname -aR
IRIX64 r8 6.5 6.5.14f 10100655 IP27
 > versions -b | grep -i nfs
I  nfs                  10/28/2002  Network File System, 6.5.14f

LINUX system:
 > uname -ar
Linux lis9.rhythm.com 2.4.26 #9 SMP Fri May 7 18:22:13 PDT 2004 i686 unknown
 > /usr/sbin/automount4 -v
Linux automount version 4.1.0

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Rhythm & Hues
5404 Jandy Place
Los Angeles, CA 90066
Voice: 310 448-7763
Fax:   310 448-7600
gregb@rhythm.com

Re: sgi IRIX-6.5 autofs

[Ian Kent]

On Wed, 6 Apr 2005, Greg Bradner wrote:

> I have a situation on IRIX where I am stat'ing a filesystem that is not 
> exported to the IRIX system.  The syslog says 'permission denied'.  
> That's expected.  Since the directory I'm in has 600 links to the file 
> system that is not exported, autofs keeps trying to mount and keeps 
> getting 'permission denied'.
> 
> On linux I get 'permission denied', but it doesn't try to mount again 
> for 30 minutes.
> 
> Has anyone heard of such a problem with IRIX's autofs and is there a fix?
> Why does linux only try every 30 minutes?

I'm not sure why Linux is trying every thirty minutes.
There's not explicit retry login in autofs.

AFAIK it should only try to mount the target of the symlink when an access 
is attempted.

Ian

Re: sgi IRIX-6.5 autofs

[Greg Bradner]

Ian Kent wrote:

>On Wed, 6 Apr 2005, Greg Bradner wrote:
>
>  
>
>>I have a situation on IRIX where I am stat'ing a filesystem that is not 
>>exported to the IRIX system.  The syslog says 'permission denied'.  
>>That's expected.  Since the directory I'm in has 600 links to the file 
>>system that is not exported, autofs keeps trying to mount and keeps 
>>getting 'permission denied'.
>>
>>On linux I get 'permission denied', but it doesn't try to mount again 
>>for 30 minutes.
>>
>>Has anyone heard of such a problem with IRIX's autofs and is there a fix?
>>Why does linux only try every 30 minutes?
>>    
>>
>
>I'm not sure why Linux is trying every thirty minutes.
>There's not explicit retry login in autofs.
>
>AFAIK it should only try to mount the target of the symlink when an access 
>is attempted.
>
>Ian
>  
>
Let me explain: I have one NAS1 server that has a large number of links 
to another NAS2.  When I run a specific program, an in house tool, it 
stats the links; which in turn tries to mount NAS2.  With the large 
number of links, the program will stat one, get 'permission denied', and 
moves to the next.  On IRIX, autofs tries to mount with each stat.  On 
linux, it stats the link, but doesn't try to mount each time, rather 
every 30 minutes.
My main curiosity is whether or not Linux autofs caches the status in 
some way and won't retry for 30 minutes?

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Rhythm & Hues
5404 Jandy Place
Los Angeles, CA 90066
Voice: 310 448-7763
Fax:   310 448-7600
gregb@rhythm.com

Re: sgi IRIX-6.5 autofs

[Ian Kent]

On Tue, 12 Apr 2005, Greg Bradner wrote:

> 
> 
> Ian Kent wrote:
> 
> >On Wed, 6 Apr 2005, Greg Bradner wrote:
> >
> >  
> >
> >>I have a situation on IRIX where I am stat'ing a filesystem that is not 
> >>exported to the IRIX system.  The syslog says 'permission denied'.  
> >>That's expected.  Since the directory I'm in has 600 links to the file 
> >>system that is not exported, autofs keeps trying to mount and keeps 
> >>getting 'permission denied'.
> >>
> >>On linux I get 'permission denied', but it doesn't try to mount again 
> >>for 30 minutes.
> >>
> >>Has anyone heard of such a problem with IRIX's autofs and is there a fix?
> >>Why does linux only try every 30 minutes?
> >>    
> >>
> >
> >I'm not sure why Linux is trying every thirty minutes.
> >There's not explicit retry login in autofs.
> >
> >AFAIK it should only try to mount the target of the symlink when an access 
> >is attempted.
> >
> >Ian
> >  
> >
> Let me explain: I have one NAS1 server that has a large number of links 
> to another NAS2.  When I run a specific program, an in house tool, it 
> stats the links; which in turn tries to mount NAS2.  With the large 
> number of links, the program will stat one, get 'permission denied', and 
> moves to the next.  On IRIX, autofs tries to mount with each stat.  On 
> linux, it stats the link, but doesn't try to mount each time, rather 
> every 30 minutes.
> My main curiosity is whether or not Linux autofs caches the status in 
> some way and won't retry for 30 minutes?
> 

Once again I'm unsure of what should be happening.

autofs on Linux shouldn't mount at all on stat unless the target is 
contained within (not the mount point itself) the filesystem.

In fact it stat should return lies (actually the autofs filesystem node) 
about the target. 

There isn't any retry logic in the code.
AFAIK there would need to be some process scanning the directories for 
this retry to happen.

I haven't used IRIX autofs for a long time.

Ian

Re: sgi IRIX-6.5 autofs

[Max Matveev]

>>>>> "ian" == Ian Kemp (ian@themaw.net) wrote:


 ian> On Tue, 12 Apr 2005, Greg Bradner wrote:

 >> Let me explain: I have one NAS1 server that has a large number of 
 >> links to another NAS2.  When I run a specific program, an in house 
 >> tool, it stats the links; which in turn tries to mount NAS2.  With the 
 >> large number of links, the program will stat one, get 'permission 
 >> denied', and moves to the next.  On IRIX, autofs tries to mount with 
 >> each stat.

That's exactly as designed - stat(2) follows the symlink, if you want
the information about the directory or file which symlinks points to,
it would have to mount first to do NFS' getattr call to get the info
which stat would return. So you should expect a mount attempt for each
stat.

 ian> autofs on Linux shouldn't mount at all on stat unless the target is
 ian> contained within (not the mount point itself) the filesystem.

Why? IMO stat(2), as opposed to lstat(2), must prove the info about
the node of the remote filesystem regardless of whatever it's the
trigger point or a file inside the trigger point.

max

Re: sgi IRIX-6.5 autofs

[raven]

On Mon, 18 Apr 2005, Max Matveev wrote:

>>>>>> "ian" == Ian Kemp (ian@themaw.net) wrote:
>
>
> ian> On Tue, 12 Apr 2005, Greg Bradner wrote:
>
> >> Let me explain: I have one NAS1 server that has a large number of
> >> links to another NAS2.  When I run a specific program, an in house
> >> tool, it stats the links; which in turn tries to mount NAS2.  With the
> >> large number of links, the program will stat one, get 'permission
> >> denied', and moves to the next.  On IRIX, autofs tries to mount with
> >> each stat.
>
> That's exactly as designed - stat(2) follows the symlink, if you want
> the information about the directory or file which symlinks points to,
> it would have to mount first to do NFS' getattr call to get the info
> which stat would return. So you should expect a mount attempt for each
> stat.
>
> ian> autofs on Linux shouldn't mount at all on stat unless the target is
> ian> contained within (not the mount point itself) the filesystem.
>
> Why? IMO stat(2), as opposed to lstat(2), must prove the info about
> the node of the remote filesystem regardless of whatever it's the
> trigger point or a file inside the trigger point.

Equally by design.

Colour ls will mount everything when you list an autofs directory and 
this (the mount storm on large autofs directories) was seen as undesirable 
for lazy mounting in a browsable tree.

But I'm open to suggestions and ideas.

Ian

Re: sgi IRIX-6.5 autofs

[Max Matveev]

>>>>> "ian" == raven  <raven@themaw.net> writes:


 ian> Colour ls will mount everything when you list an autofs
 ian> directory and this (the mount storm on large autofs directories)
 ian> was seen as undesirable for lazy mounting in a browsable tree.

It sounds like an attempt to fix appliction bug in the kernel - color
ls should've used lstat(2) instead of stat(2). But if people are happy
with such behaviour then there is no need to change it.

BTW, Greg's problem with 30 sec timeout could be because server does
not reply - tcpdump/ethereal run on a client should confirm or refute
this hypothesis.

max

Re: sgi IRIX-6.5 autofs

[Ian Kent]

On Tue, 19 Apr 2005, Max Matveev wrote:

> >>>>> "ian" == raven  <raven@themaw.net> writes:
> 
> 
>  ian> Colour ls will mount everything when you list an autofs
>  ian> directory and this (the mount storm on large autofs directories)
>  ian> was seen as undesirable for lazy mounting in a browsable tree.
> 
> It sounds like an attempt to fix appliction bug in the kernel - color
> ls should've used lstat(2) instead of stat(2). But if people are happy
> with such behaviour then there is no need to change it.

Yea.

Oddly, Solaris automounter seems to behave this way as well.

> 
> BTW, Greg's problem with 30 sec timeout could be because server does
> not reply - tcpdump/ethereal run on a client should confirm or refute
> this hypothesis.

Greg?

Ian