All of lore.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 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.