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)
This archive was generated by hypermail 2b29 : Sat Dec 07 2002 - 22:00:12 EST