Bug 146535

Summary:	Mounted SMB share "disappears" after a number of file writes in the share
Product:	[Fedora] Fedora	Reporter:	Vesselin Peev <vesselinpeev>
Component:	kernel	Assignee:	Dave Jones <davej>
Status:	CLOSED ERRATA	QA Contact:	Brian Brock <bbrock>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4	CC:	pfrields, vesselinpeev
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2005-11-14 19:33:41 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Vesselin Peev 2005-01-29 10:02:42 UTC

Description of problem:

A share on a Windows XP Professional computer on a network is mounted
from a fully updated (as of January 29, 2005) Fedora Core 3 i386
installation.

Version-Release number of selected component (if applicable):

samba.i386 3.0.10-1.fc3  

How reproducible:

1. mount -t cifs //computername/shared_directory .
or
mount -t smbfs //computername/shared_directory .

2. Use emacs, or some other editor, to repeatedly modify a text file
located in the shared directory.

Actual results:

This has been repeatedly verified several times, before and after
clean boots of all networked machines.
After a certain number of "writes" of the file, where a "write" is
opening of a file, writing to it, and then closing it (this certain
number has been found to be always < 50, sometimes much less, < 5),
the share "disappears". I say "disappear", because the disconnect is
not clean, i.e. instead of disconnecting and allowing you to
re-connect using the aforementioned mount commands, it bogs down the
last write when it happens, and locks up the application performing
it. Eventually, the app may, or may not, go past the lock up, but
there's no going back to normal operation after the first lock up.


Expected results:

No disconnection or disappearance of the shared directory.


Additional info:

This is a real problem. The machine that has Fedora Core 3 on it dual
(or triple) boots FreeBSD 5.3 and also Windows XP Professional. The
network share in question that is located on a second machine running
Windows XP Professional, *never* disconnects or disappears if it has
been mounted from the Fedora 3/FreeBSD 5.3/Windows XP machine.
That there are absolutely no problems with samba under FreeBSD 5.3 on
the same machine is notable.

Comment 1 Vesselin Peev 2005-01-29 10:10:46 UTC

Clarification: *never* disconnects or disappears if it has
been mounted from the Fedora 3/FreeBSD 5.3/Windows XP machine when
Windows XP or FreeBSD has been booted.

Comment 2 Jay Fenlason 2005-01-31 20:52:42 UTC

Once the mount succeeds, all the userspace programs that are part of 
the samba-* packages ane out of the picture.  This must be a kernel 
problem.  I'm reassigning this to the correct maintainer.

Comment 3 Vesselin Peev 2005-02-01 02:31:24 UTC

Thank you. The kernel is the latest released officially for Fedora 3 
i386 via up2date. It is 2.6.10-1.741_FC3smp.

Comment 4 Vesselin Peev 2005-02-04 13:31:41 UTC

This is to keep you up-to-date on what happens -- the problem 
continues with the latest kernel (2.6.10-1.760_FC3smp) and all the 
other updates. I stand by the accuracy of all my words up to now. I 
would also like to add that sometimes even SMB read accesses lock up 
apps. So, for now, FreeBSD 5.3 is the way to go...

Comment 5 Dave Jones 2005-07-15 18:29:37 UTC

An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem.   Please update to this new kernel, and
report whether or not it fixes your problem.

If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.

Thank you.

Comment 6 Vesselin Peev 2005-07-15 20:14:34 UTC

I just updated to the latest kernel, the one you quote (and other packages, 
although I don't remember to have seen samba recently in the yum update list). 
I specifically booted with the non-SMP kernel and did everything as described 
previously.

Same story -- it happens after a lot less than 50 saves.

Also I should note that the remote disk's filesystem (NTFS) is sometimes 
corrupted by this happening, although the corruption is fixable. It could be a 
very unpleasant surprise to someone.

I say sometimes, because there was no corruption this time (just hanging), but 
1-2 months ago I re-tested the problem on my own initiative and I did get 
corruption.

Fortunately, I have Fedora Core 4 running under QEMU under Fedora Core 3. I'll 
test with it, too, and report back.

Comment 7 Vesselin Peev 2005-07-15 21:58:39 UTC

Under a fully updated Fedora Core 4 (running under QEMU as mentioned above, and
with the QEMU kqemu kernel acceleration module loaded), and latest Fedora Core 4
kernel booted, the lockup occurred on the very first save! Not only that, but
the Fedora Core 4 system totally froze after about a minute (it was running the
default Gnome desktop). Going out of that meant just closing QEMU, of course. No
filesystem corruption has been found on the remote computer afterwards (XP Pro
on it has been also fully updated beforehand, too).
That indeed must be a kernel issue, and so it is present on both Fedora Core 3
and 4.
Regarding the machine, it is rock stable with everything, and a couple of days
ago its BIOS was upgraded to the latest one currently supplied by the
motherboard manufacturer (ASUS). It is a P5GD1-VM system (i915G chipset).
I hope the above info will eventually be of some help.

Comment 8 Vesselin Peev 2005-07-15 22:09:09 UTC

As you advised, I have changed the OS version field to FC4. I'd leave to you if
anything else needs to be done to indicate that the error is present in FC3 as well.

Comment 9 Dave Jones 2005-09-30 06:46:34 UTC

Mass update to all FC4 bugs:

An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream
kernel (2.6.13.2). As there were ~3500 changes upstream between this and the
previous kernel, it's possible your bug has been fixed already.

Please retest with this update, and update this bug if necessary.

Thanks.

Comment 10 Dave Jones 2005-11-10 19:52:30 UTC

2.6.14-1.1637_FC4 has been released as an update for FC4.
Please retest with this update, as a large amount of code has been changed in
this release, which may have fixed your problem.

Thank you.

Comment 11 Vesselin Peev 2005-11-13 23:43:47 UTC

Hello,

Fixed!

Kernel 2.6.14-1.1637_FC4 under Fedora Core 4 has fixed the problem.
Kernel 2.6.12-1.1381_FC3smp under Fedora Core 3 has fixed the problem, too 
(should this be noted somewhere else for Fedora Core 3 /I know it is EOL'd/?).

Thank you!

Best regards,
Vesselin.

Comment 12 Dave Jones 2005-11-14 19:33:41 UTC

actually FC3 is still supported (though I dont think for much longer).