Re: Bug when unmounting share (shrink_dcache_for_umount)

First of, for completeness' sake: between my first mail and this
one, the client system received a kernel update to version
2.6.33.3-72.fc13.x86_64.


> Do you ever see messages like this in dmesg?
> 
>                 cERROR(1, "Autodisabling the use of server inode numbers on "
>                            "%s. This server doesn't seem to support them "
>                            "properly. Hardlinks will not be recognized on this "
>                            "mount. Consider mounting with the \"noserverino\" "
>                            "option to silence this message.",
>                            cifs_sb_master_tcon(cifs_sb)->treeName);

Nope, this message appeared nowhere in my dmesg during my test
runs, and it's also nowhere else in my /var/log.


> If so, does the problem go away if you mount your shares with '-o
> noserverino' ?

Mounting with 'noserverino' in the fstab entry helps indeed.

For a complete test protocol:

01. mount without "noserverino" in fstab
02. mplayer /mnt/ehs1/somevideo
03. ctrl+q to end mplayer
04. umount
05. bug
06. mount with "noserverino" in fstab
07. mplayer /mnt/ehs1/somevideo
08. ctrl+q to end mplayer
09. umount
10. no bug

Also:

1. boot with auto-mount, without noserverino
2. the mplayer test
3. shutdown
4. fails to reach power down strage with trace on screen

But:

1. boot with auto-mount, with noserverino
2. the mplayer test
3. shutdown
4. powers down fine


Just to repeat, the bug never happens even without noserver-
ino if the share had never been used (i.e. the mplayer test).

Another observation: If the bug has ever been triggered
during a system run, shutdown will fail, either with the
"Unmounting CIFS filesystems" stage getting stuck or
mount throwing an error 22 (invalid argument). E.g. if I
do:

1. mount without noserverino
2. mplayer thing
3. unmount
4. bug
5. remount with noserverino
6. mplayer
7. umount or leave mounted, no difference
8. shutdown
9. stuck or error 22


Bottom line: noserverino helps here. But reading the manpage
on it, I get the feeling that I'm not expected to need that
mount option if I'm using a sufficiently recent Samba server,
so this is a bit of an odd case I assume?

Here's some more info on the share in question: The shared
folder on the server system, /ehs1, is the mount point of a
distinct partition on the server's primary hard drive, next
to the partition mounted as /.

It contains several folders which are the mount point for
bind mounts (i.e. -o bind) from folders on other volumes
mounted into the server system at other places. /ehs1/backup
for example is a bind mount from /mnt/raid/backup, where
/mnt/raid is the mount point for an MD raid1. There are
several such bind mounts in the shared folder.

The video file I'm accessing with mplayer for the test is
located directly in /ehs1, however, not in any of the bind-
mounted folders.

Could any of the above cause the use of server inodes to
fail?


-- 
Best regards,
Eike Hein