All of lore.kernel.org
 help / color / mirror / Atom feed
From: ramana <ramana@intraperson.com>
To: Ian Kent <raven@themaw.net>, mmarion@qualcomm.com
Cc: autofs@linux.kernel.org
Subject: Re: unacceptable bug in autofs kernel module
Date: Fri, 04 Feb 2005 08:29:50 +0530	[thread overview]
Message-ID: <4202E526.50304@intraperson.com> (raw)
In-Reply-To: <Pine.LNX.4.58.0502040948330.21690@wombat.indigo.net.au>

Ian Kent wrote:

>On Thu, 3 Feb 2005 mmarion@qualcomm.com wrote:
>
>  
>
>>On 28 Dec, ramana wrote:
>>
>>    
>>
>>>Here is the bug in autofs3 module which causing so much pain. It simply 
>>>stopped me from adding much more interesting features to Autodir 
>>>http://www.intraperson.com/autodir/
>>>      
>>>
>>[snip]
>>    
>>
>>>Because of this, user space test program reporting like this:
>>>
>>>fail : /test/t944 : No such file or directory
>>>fail : /test/t4187 : No such file or directory
>>>      
>>>
>>Hmm.. I wonder if this might be related to a weirdness we're seeing. Running
>>autofs-4.1.3 with previous latest patch to kernel (pre-2005 release) and users
>>use LSF to submit batch jobs to hosts.  On linux hosts, user level programs
>>will sometimes exit quickly with a "file does not exist" error, even though you
>>can login to the host and see the file/dir just fine.  As a hacked
>>work-around, we have a pre-exec script that tries to stat all the directories
>>they need to force the mounts to happen before their program touches the
>>files.
>>    
>>
>
>Does the stat actually mount anything?
>It shouldn't?
>
>Ian
>
>
>  
>
I moved latest version Autodir to autofs 4 kernel module and so far all 
stress tests tell me autofs4 protocol is performing well without these 
ENOENT errors. I have to do little bit more tests before concluding 
anything as final.

For more details check http://www.intraperson.com/autodir/.
DVersion: Autodir 0.93.0 and above.

Regards
ramana

-- 
http://www.intraperson.com

  reply	other threads:[~2005-02-04  2:59 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-28  7:51 unacceptable bug in autofs kernel module ramana
2004-12-29  1:02 ` Ian Kent
2004-12-29  3:44   ` ramana
     [not found]   ` <41D21C1E.8040407@intraperson.com>
     [not found]     ` <Pine.LNX.4.58.0412291418160.8463@wombat.indigo.net.au>
     [not found]       ` <41D28271.601@intraperson.com>
2004-12-30  0:38         ` Ian Kent
2004-12-30  0:47         ` Ian Kent
     [not found]           ` <41D370E7.9080409@intraperson.com>
2004-12-30  5:42             ` Ian Kent
2005-02-04  0:38 ` mmarion
2005-02-04  1:49   ` Ian Kent
2005-02-04  2:59     ` ramana [this message]
2005-02-05 13:46       ` ramana
  -- strict thread matches above, loose matches on Subject: below --
2005-02-04 18:58 peter.a.harris
2005-03-07 19:49 ` Mike Marion
2005-02-04 19:11 Lever, Charles
2005-02-04 22:34 peter.a.harris
2005-02-25 21:22 Trinh, Ngan
2005-03-08  0:16 peter.a.harris
2005-03-08 22:53 ` Mike Marion
2005-03-21 20:54 devnull

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4202E526.50304@intraperson.com \
    --to=ramana@intraperson.com \
    --cc=autofs@linux.kernel.org \
    --cc=mmarion@qualcomm.com \
    --cc=raven@themaw.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.