This *may* help.

man mount
             softdep
                     (FFS only.)  Mount the file system using soft dependen-
                     cies.  Instead of metadata being written immediately,
it
                     is written in an ordered fashion to keep the on-disk
                     state of the file system consistent.  This results in
                     significant speedups for file create/delete operations.
                     This option will be ignored when using the -u flag and
a
                     file system is already mounted read/write.  It requires
                     option FFS_SOFTUPDATES to be enabled in the running
ker-
                     nel.

There is a tradeoff between speed and safety.
A rather large tradeoff I suspect ;)

With any disk system, there is the question of what happens when the power
fails.

What is the speed when you copy the 48MB file locally?

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
Gary Clemans-Gibbon
Sent: Tuesday, July 19, 2005 3:45 AM
To: [EMAIL PROTECTED]
Cc: misc@openbsd.org
Subject: Re: Writes to samba server very, very slow


Thanks for your reply Tim. If anything it makes me feel worse. I was
hoping it was something easily fixed.

I just tried transferring a 50 Mb file to the OBSD samba box from win
using SCP. Again very slow writes but much faster reads. The 50 Mb file
took about 7 mins to transfer to the OBSD box and about 30 seconds to
read from the OBSD box.

Perhaps this isn't a samba smb issue at all.

My fstab...

# cat /etc/fstab
/dev/wd0a / ffs rw 1 1
/dev/wd1a /data1 ffs rw 1 2
/dev/wd2a /data2 ffs rw 1 2

same result with either data disk. I've been googling all evening and
found many many forum posts with similar problems but no solutions. Some
posts date back to 2002!

If I have to go back to RH7.3 I'll be bummed. Especially as I spent ages
setting up all my families accounts and softlinks for the data store.
Waste of a day!


Tim Hammerquist wrote:
> Gary Clemans-Gibbon wrote:
>
>>David Gwynne wrote:
>>
>>>Gary Clemans-Gibbon wrote:
>>>
>>>>Everything is working fine except that when I copy files to the
>>>>box from a Windows XP box the transfers are very slow, like
>>>>9 minutes for a  48 Mb file. Copying the same file back to the win
>>>>box is quick - a couple  of seconds as you'd expect.
>>>
>>>I would suggest looking at the socket options parameter in
>>>/etc/samba/ smb.conf. I have the following in my smb.conf and
>>>transfer speeds  seem to perform a lot better now:
>>>
>>>socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
>>
>>I just tried that line but it seems to be the same or if anything it
>>seems even slower.
>
>
> Gary,
>
> I've seen this same phenomenon when copying to from my OSX Powerbook and
> my fileserver (running both FreeBSD 5 and Gentoo Linux), with the OSX
> acting as samba client.
>
> The transfer speeds are not "slightly" slower, they are slower by orders
> of magnitude, with normally 20sec transfers taking 10-20 minutes.
> I watch the progress meter slowly incrementing at the rate of 32-64k/sec
> over a 100bTX link.  Does this sound like your issue?
>
> In my setup, I had limited success merely unmounting and remounting the
> share; that worked maybe 50% of the time.  Also, the rate seemed to be
> normal more often if I had a simultaneous ssh connection between the
> same two machines, even if the ssh connection were idle.  I was not able
> to find any consistently effective solution.
>
> After googling many times over several months, finding nothing more than
> the same advice you got about TCP_NODELAY and the SO_*BUF settings
> (which did not affect performance in my case either), I finally gave up,
> switching to NFS and/or scp.
>
> For what it's worth, I haven't noticed this since I upgraded my
> powerbook to OSX 10.4, so it might have something to do with the client
> OS, network stack, or Samba version.
>
> I apologize for not having anything solid to recommend.  But I wanted to
> let you know that this *has* happened to others; you're not imagining
> it.
>
> Tim Hammerquist
>
>
> .

Reply via email to