Re: Bug when unmounting share (shrink_dcache_for_umount)

On Tue, 04 May 2010 03:23:56 +0200
Eike Hein <[email protected]> wrote:

> 
> 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?
> 

That's correct. We've seen occasional reports of this bug, but it's
been very elusive. If I have a way to reproduce this, I can probably
track it down...

> 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?
> 
> 

This is good info. What may be best actually is if you could open a
CIFS VFS bug at bugzilla.samba.org. I'd like to collect some info about
your server and its config and see if I can come up with a reproducer
here.

In the meantime, using noserverino should be safe (though it will make
it so that you can't detect hardlinks).

Thanks,
-- 
Jeff Layton <[email protected]>