public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Andrey R. Urazov" <coola@ngs.ru>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: a bug in autofs
Date: Mon, 2 Dec 2002 13:57:25 +0600	[thread overview]
Message-ID: <20021202075725.GC1459@ktulu> (raw)
In-Reply-To: <1038799532.15370.301.camel@ixodes.goop.org>

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

On Sun, Dec 01, 2002 at 07:25:32PM -0800, Jeremy Fitzhardinge wrote:
> What happens if you try to manually mount the cdrom when there's nothing
> in the drive?
[root@ktulu coola]# en mount -o ro -t iso9660 /dev/cdrom /mnt
mount: No medium found

with this attempt a new line reading `cdrom: open failed' is appended to
the dmesg output

> > 2) under /misc/summer there resides an ntfs volume with thousands of
> > files. And when I run 
> > 
> >         find /misc/summer
> > 
> >    the system becames unusable after some amount of files is scanned.
> >    Usually it just hangs. But one time "find" terminated with the
> >    segmentation fault and then after 5 seconds or so the system hung.
> 
> Can you reproduce this with some other filesystem type (something which
> is less flaky than NTFS)?
Tried with fat32 and found no problems, everything is okay in this case.
> 
> How many files are on the NTFS filesystem?
To test for the bug I used the following command:

    find /misc/summer | tee /dev/tty | wc

in most cases I didn't see the output of wc, but two times I managed to
(in this cases `find' managed to terminate before the system hung).

24849 files, 1712874 total characters (in filenames)
25087 files, 1737450 characters

> > The problem does not existed if the volumes are mounted through
> > "mount".  Only automounting causes problems.
Sorry for misinforming you. When this was written I tried manual
mounting only once and all was okay during this trial. But when
I repeated the test, the system crashed as in the case of automounting.
And I didn't manage to perform a succesful find over ntfs volume once
more. So the problem here is probably in the ntfs driver, not autofs.
> 
> Does this comment also apply to the cdrom case?
This applies to cdrom case. Just tested it. I.e. the system doesn't
crash when I invoke xmms with a playlist referring to nonexistent cd.

> What mount options are you using to mount these filesystems?  Are they
> the same when you do it manually and using autofs?
Tried different combinations. Does not matter.

> What does the "dentry_cache" line say in /proc/slabinfo while you're
> running the find on the NTFS filesystem?
It varies so I'm including several snapshots:

[coola@ktulu coola]$ cat /proc/slabinfo|grep dentry
dentry_cache        2069   4380    128  146  146    1
[coola@ktulu coola]$ cat /proc/slabinfo|grep dentry
dentry_cache        5311   5340    128  178  178    1
[coola@ktulu coola]$ cat /proc/slabinfo|grep dentry
dentry_cache        2901   4200    128  140  140    1
[coola@ktulu coola]$ cat /proc/slabinfo|grep dentry
dentry_cache        5383   5400    128  180  180    1
[coola@ktulu coola]$ cat /proc/slabinfo|grep dentry
dentry_cache        1358   4080    128  136  136    1
[coola@ktulu coola]$ cat /proc/slabinfo|grep dentry
dentry_cache        3110   4080    128  136  136    1
[coola@ktulu coola]$ cat /proc/slabinfo|grep dentry
dentry_cache        3731   4920    128  164  164    1
[coola@ktulu coola]$ cat /proc/slabinfo|grep dentry
dentry_cache        4068   4920    128  164  164    1
[coola@ktulu coola]$ cat /proc/slabinfo|grep dentry
dentry_cache        4132   4920    128  164  164    1
[coola@ktulu coola]$ cat /proc/slabinfo|grep dentry
dentry_cache        4192   4920    128  164  164    1
[coola@ktulu coola]$ cat /proc/slabinfo|grep dentry
dentry_cache        4258   4920    128  164  164    1


 
> Thanks,
> 	J
That's me who should thank you.



Best regards,
  Andrey Urazov
-- 
Lying is an indispensable part of making life tolerable.
		-- Bergan Evans
--
lundi 02 décembre, 2002, 10:06:15 +0600 - Andrey R. Urazov (mailto:coola@ngs.ru)


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

  reply	other threads:[~2002-12-02  7:48 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-01  7:16 a bug in autofs Andrey R. Urazov
2002-12-01 18:29 ` Bryan O'Sullivan
2002-12-02  4:03   ` Andrey R. Urazov
2002-12-02  3:25 ` Jeremy Fitzhardinge
2002-12-02  7:57   ` Andrey R. Urazov [this message]
2002-12-02  8:39     ` Jeremy Fitzhardinge
2002-12-02 15:17       ` Andrey R. Urazov
     [not found]         ` <1038847726.2560.51.camel@ixodes.goop.org>
2002-12-02 17:50           ` Andrey R. Urazov
2002-12-02 18:35             ` Jeremy Fitzhardinge
2002-12-03  5:07               ` Andrey R. Urazov

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=20021202075725.GC1459@ktulu \
    --to=coola@ngs.ru \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox