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)