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 --]
next prev parent 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.