On Sun, 22 Feb 2004, Scott Sipe wrote: > I have a FAT drive mounted (it was created and formatted under FreeBSD) > and shared via samba. newfs_msdos is very broken in -current. This may be relevant. Incomplete fixes (just enough for mounting under FreeBSD): %%% Index: newfs_msdos.c =================================================================== RCS file: /home/ncvs/src/sbin/newfs_msdos/newfs_msdos.c,v retrieving revision 1.20 diff -u -0 -r1.20 newfs_msdos.c --- newfs_msdos.c 17 Feb 2004 02:02:18 -0000 1.20 +++ newfs_msdos.c 17 Feb 2004 07:23:01 -0000 _at__at_ -762 +861 _at__at_ - bpb->bsec = lp->d_secperunit; + bpb->bsec = ms / secsize; %%% This fixes the file system size for the case where the device is a partition within a BSD-labeled device (and is not the whole labeled device). > When I try to copy large files to the drive from > an XP computer, samba often (not always) dies (I lose the connection) > and a large number of unkillable smbd processes abound in state "nbufkv" > if that matters (kill -9, killall -9 -- no effect)--the only solution is > to reboot the computer (which by itself doesn't always work--sometimes I > have to pull the plug). I haven't noticed anything weird in the samba > logs, or elsewhere, and am not really sure what I should look for, or > what additional information I can provide. Hanging in state "nbufkv" means that your buffer map is fragmented, and there is a bug handling it. To avoid this fragmentation, don't use file systems with a block size larger than BKVASIZE (16K), or if you must use such a file system then try increasing BKVASIZE to 32K or 64K. Block sizes larger than 16K tend to be inefficient even if they work. To monitor this fragmentation, use the vfs.bufdefragcnt and buffreekvacnt sysctls. BruceReceived on Sun Feb 22 2004 - 03:34:58 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:44 UTC