smbfs problems
Hi Some info about failures I see: root:vallo# kldstat Id Refs AddressSize Name 13 0xc010 3be9e0 kernel 21 0xc04bf000 480d4acpi.ko root:vallo# smbutil view //vallo@poweredge smbutil: smb_lib_init: can't find kernel module It means kernel module will not be loaded upon first use of smbfs. This can and can not be considered as bug. root:vallo# cd /boot/kernel root:vallo# kldload smbfs.ko root:vallo# kldstat Id Refs AddressSize Name 18 0xc010 3be9e0 kernel 21 0xc04bf000 480d4acpi.ko 31 0xc17dc000 2smbfs.ko root:vallo# smbutil view //vallo@poweredge Password: ShareType Comment --- IPC$ pipe Remote IPC work disk toolsdisk usersdisk private disk test disk Now the writing part: After creating 5MB file using /dev/urandom, I'm trying to copy it over to users/vallo smb share mounted at /mnt, which fails. The copy is interruptible using Ctrl-C. Examination at NT4 server shows 0 byte file. Umount of /mnt fails with device busy. Umount -f /mnt fails to return prompt, but after interrupting the smbfs is unmounted. There is no kernel messages or something in syslog. The copy operation returns failure ~3 seconds after start. root:vallo# mount /dev/ad0s1a on / (ufs, local, soft-updates) devfs on /dev (devfs, local) /dev/ad0s1d on /usr (ufs, NFS exported, local, soft-updates) procfs on /proc (procfs, local) myhakas:/opt/src-current/src on /usr/src (nfs) myhakas:/opt/src-current/ports on /usr/ports (nfs, read-only) //VALLO@POWEREDGE/USERS on /mnt (smbfs) root:vallo# cd /home/vallo/ root:vallo# dd if=/dev/urandom of=testfile bs=1m count=5 5+0 records in 5+0 records out 5242880 bytes transferred in 0.518492 secs (10111784 bytes/sec) root:vallo# cp testfile /mnt/vallo/ cp: /mnt/vallo/testfile: Operation timed out ^C root:vallo# root:vallo# ls -la /mnt/vallo ^C root:vallo# root:vallo# umount /mnt umount: unmount of /mnt failed: Device busy root:vallo# umount -f /mnt ^C root:vallo# mount /dev/ad0s1a on / (ufs, local, soft-updates) devfs on /dev (devfs, local) /dev/ad0s1d on /usr (ufs, NFS exported, local, soft-updates) procfs on /proc (procfs, local) myhakas:/opt/src-current/src on /usr/src (nfs) myhakas:/opt/src-current/ports on /usr/ports (nfs, read-only) root:vallo# -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: smbfs problems
[snip] After creating 5MB file using /dev/urandom, I'm trying to copy it over to users/vallo smb share mounted at /mnt, which fails. The copy is interruptible using Ctrl-C. Examination at NT4 server shows 0 byte file. Umount of /mnt fails with device busy. Umount -f /mnt fails to return prompt, but after interrupting the smbfs is unmounted. There is no kernel messages or something in syslog. The copy operation returns failure ~3 seconds after start. [snip] Sorry forgot to add one detail. Althought dd'ing the same file to smbfs mount works, it'll sometimes modify the file being copied (size is different). It doesn't happen reliably, sometimes the file is copied fine, sometimes not. At the times the file isn't copied right there's an error message: root:vallo# dd if=testfile of=/mnt/vallo/test1 dd: /mnt/vallo/test1: Bad address 9356+0 records in 9355+0 records out 4789760 bytes transferred in 20.350003 secs (235369 bytes/sec) root:vallo# ls -la /mnt/vallo/ total 4710 drwxr-xr-x 1 root wheel16384 Nov 21 15:10 . drwxr-xr-x 1 root wheel16384 Jan 1 1970 .. -rwxr-xr-x 1 root wheel 4789760 Nov 21 15:10 test1 -rwxr-xr-x 1 root wheel0 Nov 21 14:52 testfile root:vallo# ls -la /home/vallo/testfile -rw-r--r-- 1 root wheel 5242880 Nov 21 14:52 /home/vallo/testfile It seems to me that adding conv=sync flag to dd removes the abovementioned failure case. 10 tries of dd with this flag added did fine. root:vallo# dd if=testfile of=/mnt/vallo/test1 conv=sync 10240+0 records in 10240+0 records out 5242880 bytes transferred in 24.295283 secs (215798 bytes/sec) root:vallo# ls -la /mnt/vallo/ total 5152 drwxr-xr-x 1 root wheel16384 Nov 21 15:13 . drwxr-xr-x 1 root wheel16384 Jan 1 1970 .. -rwxr-xr-x 1 root wheel 5242880 Nov 21 15:13 test1 -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: smbfs problems
[ ... smbfs ... ] Vallo Kallaste wrote: Now the writing part: After creating 5MB file using /dev/urandom, I'm trying to copy it over to users/vallo smb share mounted at /mnt, which fails. The copy is interruptible using Ctrl-C. Examination at NT4 server shows 0 byte file. Umount of /mnt fails with device busy. Umount -f /mnt fails to return prompt, but after interrupting the smbfs is unmounted. There is no kernel messages or something in syslog. The copy operation returns failure ~3 seconds after start. Try using 'dd' instead of 'cp', or the patch I posted last night. The shows 0 byte file is a normal artifact of how file metadata is handled in Windows filesystems: unlike UNIX, a partial file does not have the metadata, including the file size, updated until the file is closed. Therefore FTP restart is pretty meaningless on Windows, unless you have an FTP client that closes and reopens for writing the file it is transferring at intervals, among other things -- one of which is that any interrupted create operation will leave a 0 length file. I don't know why your umount fails with device busy; what you need to do is look at the connections which are open, and why it cares about whether or not they are abandoned, in the unmount case. I rather expect that the connection(s) are jammed up, so you can't close them so you have virtual circuit instances that you can't get rid of. I would expect even a force to take whatever time it takes to dump the open handles, plus 2MSL plus however much time it keeps the connection in the half-close state, waiting for a FIN/ACK from the server. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: smbfs problems
Vallo Kallaste wrote: Sorry forgot to add one detail. Althought dd'ing the same file to smbfs mount works, it'll sometimes modify the file being copied (size is different). It doesn't happen reliably, sometimes the file is copied fine, sometimes not. At the times the file isn't copied right there's an error message: root:vallo# dd if=testfile of=/mnt/vallo/test1 dd: /mnt/vallo/test1: Bad address 9356+0 records in 9355+0 records out 4789760 bytes transferred in 20.350003 secs (235369 bytes/sec) It seems to me that adding conv=sync flag to dd removes the abovementioned failure case. 10 tries of dd with this flag added did fine. The 'conv-sync' flag to 'dd' pads the operation out to a record boundary, if the input of the operation is not a full record in length. This observation is consistent with an incomplete final write, for lack of data. Probably this has to do with the TCP_PUSH option and/or the SMB server's connection flags. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
