On Mon, Nov 14, 2011 at 5:30 AM, Dan The Man wrote:
>
>
> Thankyou for suggestion Peter , didn't solve it, and no its not the disks ,
> I have been monitoring gstat and its doing what it should, NFS works just
> fine.
...
> Its always sitting in rpcsvc around 2% cpu doing what it should.
>
> Sam
Thankyou for suggestion Peter , didn't solve it, and no its not the disks
, I have been monitoring gstat and its doing what it should, NFS works
just fine.
Here is typical NFS session from tcpdump
07:13:42.192671 IP asterisk.nfsd > desktop.kink: Flags [.], ack 19048093,
win 29124, length 0
Dan,
I may have had the same problem and solved it. I'm not quite sure at all
it is related though.
Try adding these 2 lines to your [global] section of your smb.conf on
the samba server:
strict locking = no
blocking locks = no
I don't know if the above will cause some data integrity pe
Running tcpdump to trace what samba is doing so maybe someone can give
some insight, lan interface is sk0.
02:52:34.347357 IP (tos 0x0, ttl 64, id 56121, offset 0, flags [none],
proto TCP (6), length 1500)
asterisk.microsoft-ds > desktop.58858: Flags [.], cksum 0x5e3f
(correct), seq 10
Well been running a week now and problems again. 3 3 terrabyte drives are
@85% with compression enabled, i have to wonder if that is part of the
problem.
Dan.
--
Dan The Man
CTO/ Senior System Administrator
Websites, Domains and Everything else
http://www.SunSaturn.com
Email: d...@sunsa
On Wed, Nov 9, 2011 at 1:39 PM, Garrett Cooper wrote:
> On Nov 8, 2011, at 11:07 PM, "Daniel O'Connor" wrote:
>
>>
>> On 09/11/2011, at 17:32, Garrett Cooper wrote
dd's of large files (spooled backups going to tape) to /dev/null are as
slow as Samba.
>>>
>>> - Dedupe?
>>
>> Nope.
>>
On Nov 8, 2011, at 11:07 PM, "Daniel O'Connor" wrote:
>
> On 09/11/2011, at 17:32, Garrett Cooper wrote
>>> dd's of large files (spooled backups going to tape) to /dev/null are as
>>> slow as Samba.
>>
>> - Dedupe?
>
> Nope.
>
>> - Compression?
>
> On the mail spool & ports, but not on the t
On 11/09/2011 08:07 AM, Daniel O'Connor wrote:
> On 09/11/2011, at 17:32, Garrett Cooper wrote
>>> dd's of large files (spooled backups going to tape) to /dev/null are as
>>> slow as Samba.
>>- Dedupe?
> Nope.
You are probably right, but just to be sure, let's verify that with:
zpool get dedu
On Wed, Nov 9, 2011 at 1:07 AM, Daniel O'Connor wrote:
>
> On 09/11/2011, at 17:32, Garrett Cooper wrote
>>> dd's of large files (spooled backups going to tape) to /dev/null are as
>>> slow as Samba.
>>
>> - Dedupe?
>
> Nope.
>
>> - Compression?
>
> On the mail spool & ports, but not on the
On 09/11/2011, at 17:32, Garrett Cooper wrote
>> dd's of large files (spooled backups going to tape) to /dev/null are as slow
>> as Samba.
>
>- Dedupe?
Nope.
>- Compression?
On the mail spool & ports, but not on the tape spool.
>- How much RAM?
8GB.
>- What debug options do
On Tue, Nov 8, 2011 at 10:28 PM, Daniel O'Connor wrote:
>
> On 09/11/2011, at 16:56, Daniel O'Connor wrote:
>> On 09/11/2011, at 16:29, Kurt Touet wrote:
>>> Is anyone else seeing problems like this with samba/zfs ? Perhaps
>>> it's not exclusive to samba, either?
>>
>> Yep, I see this too.
>>
On 09/11/2011, at 16:56, Daniel O'Connor wrote:
> On 09/11/2011, at 16:29, Kurt Touet wrote:
>> Is anyone else seeing problems like this with samba/zfs ?Perhaps
>> it's not exclusive to samba, either?
>
> Yep, I see this too.
>
> I can get 80-100Mbyte/sec reads out of a single disk but ZFS i
On 09/11/2011, at 16:29, Kurt Touet wrote:
> Is anyone else seeing problems like this with samba/zfs ?Perhaps
> it's not exclusive to samba, either?
Yep, I see this too.
I can get 80-100Mbyte/sec reads out of a single disk but ZFS is (now) very slow
- it reads & writes and much more slowly
On Tue, Nov 8, 2011 at 8:16 PM, Dan The Man wrote:
>
> On Tue, 8 Nov 2011, Kurt Touet wrote:
>
>> On Tue, Nov 8, 2011 at 3:32 AM, Dan The Man wrote:
>>>
>>>
>>> Sorry I meant it was running fine on beta3 and 8.2 stable, and NOT RC1:
>>> asterisk:~# uname -a
>>> FreeBSD asterisk.sunsaturn.com 9.0-
On Tue, 8 Nov 2011, Kurt Touet wrote:
On Tue, Nov 8, 2011 at 3:32 AM, Dan The Man wrote:
Sorry I meant it was running fine on beta3 and 8.2 stable, and NOT RC1:
asterisk:~# uname -a
FreeBSD asterisk.sunsaturn.com 9.0-RC1 FreeBSD 9.0-RC1 #0: Mon Oct 31
19:46:53 CDT 2011 dr...@asterisk.sunsat
On Tue, Nov 8, 2011 at 3:32 AM, Dan The Man wrote:
>
>
> Sorry I meant it was running fine on beta3 and 8.2 stable, and NOT RC1:
> asterisk:~# uname -a
> FreeBSD asterisk.sunsaturn.com 9.0-RC1 FreeBSD 9.0-RC1 #0: Mon Oct 31
> 19:46:53 CDT 2011 dr...@asterisk.sunsaturn.com:/usr/obj/usr/src/sys/MYKE
Sorry I meant it was running fine on beta3 and 8.2 stable, and NOT RC1:
asterisk:~# uname -a
FreeBSD asterisk.sunsaturn.com 9.0-RC1 FreeBSD 9.0-RC1 #0: Mon Oct 31
19:46:53 CDT 2011
dr...@asterisk.sunsaturn.com:/usr/obj/usr/src/sys/MYKERNEL amd64
asterisk:~#
Dan.
--
Dan The Man
CTO/ Seni
Ok here is some specs: this been running fine on 8.2 stable and i was sure
it was running fine on RC1 as well. I did some testing against samba 34 35
and 36 in the ports collection all with the same slow write problems.
I did further testing mounting drive in question with NFS and it did not
On Thu, Oct 27, 2011 at 6:42 PM, Dan wrote:
>
>
> Updated from 9.0 beta3 to RC1 and using mkvmerge over samba/zfs
> its taking over an hour to just mux in things like DTS english, where it was
> 15 minutes on beta3.
Hi Dan,
- Can you do more deterministic / scientific benchmarks?
- Did you upgrad
19 matches
Mail list logo
