Re: samba+zfs
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. > > Samba on other hand what I find interesting is I tried to see what truss > would show on smbd while writing today and found the following: ... > It actually seems to be running some timed event smbd_idle literally holding > up process for many seconds all the time Hmm... samba seems slower (high latency opening files) today than before. Granted, I just reinstalled Windows 7 on my client box so I need to poke around it to determine what the issue is. Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: samba+zfs
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
07:13:42.192673 IP desktop.kink > asterisk.nfsd: Flags [.], seq
19048093:19049553, ack 16176768, win 16178, length 1460
07:13:42.192679 IP asterisk.nfsd > desktop.kink: Flags [.], ack 19049553,
win 29124, length 0
07:13:42.192680 IP desktop.kink > asterisk.nfsd: Flags [.], seq
19049553:19051013, ack 16176768, win 16178, length 1460
07:13:42.192686 IP asterisk.nfsd > desktop.kink: Flags [.], ack 19051013,
win 29124, length 0
07:13:42.192765 IP desktop.kink > asterisk.nfsd: Flags [.], seq
19051013:19052473, ack 16176768, win 16178, length 1460
07:13:42.192771 IP asterisk.nfsd > desktop.kink: Flags [.], ack 19052473,
win 29124, length 0
07:13:42.192772 IP desktop.kink > asterisk.nfsd: Flags [.], seq
19052473:19053933, ack 16176768, win 16178, length 1460
07:13:42.192778 IP asterisk.nfsd > desktop.kink: Flags [.], ack 19053933,
win 29124, length 0
07:13:42.192780 IP desktop.kink > asterisk.nfsd: Flags [.], seq
19053933:19055393, ack 16176768, win 16178, length 1460
07:13:42.192786 IP asterisk.nfsd > desktop.kink: Flags [.], ack 19055393,
win 29124, length 0
07:13:42.192787 IP desktop.kink > asterisk.nfsd: Flags [.], seq
19055393:19056853, ack 16176768, win 16178, length 1460
07:13:42.192793 IP asterisk.nfsd > desktop.kink: Flags [.], ack 19056853,
win 29124, length 0
07:13:42.192795 IP desktop.kink > asterisk.nfsd: Flags [.], seq
19056853:19058313, ack 16176768, win 16178, length 1460
Its always sitting in rpcsvc around 2% cpu doing what it should.
Samba on other hand what I find interesting is I tried to see what truss
would show on smbd while writing today and found the following:
#
geteuid()= 0 (0x0)
write(36,"[2011/11/14 07:26:07.939217, 10]"...,67) = 67 (0x43)
geteuid()= 0 (0x0)
write(36," Running timed event "smbd_idle"...,60) = 60 (0x3c)
gettimeofday({1321277167.939372 },0x0) = 0 (0x0)
geteuid()= 0 (0x0)
write(36,"[2011/11/14 07:26:07.939372, 10]"...,77) = 77 (0x4d)
geteuid()= 0 (0x0)
write(36," smbd_idle_event_handler: idle_"...,57) = 57 (0x39)
gettimeofday({1321277167.939521 },0x0) = 0 (0x0)
geteuid()= 0 (0x0)
write(36,"[2011/11/14 07:26:07.939521, 10]"...,77) = 77 (0x4d)
geteuid()= 0 (0x0)
write(36," smbd_idle_event_handler: idle_"...,62) = 62 (0x3e)
gettimeofday({1321277167.939671 },0x0) = 0 (0x0)
gettimeofday({1321277167.939700 },0x0) = 0 (0x0)
gettimeofday({1321277167.939728 },0x0) = 0 (0x0)
geteuid()= 0 (0x0)
write(36,"[2011/11/14 07:26:07.939728, 10]"...,67) = 67 (0x43)
geteuid()= 0 (0x0)
write(36," Running timed event "smbd_idle"...,60) = 60 (0x3c)
gettimeofday({1321277167.939877 },0x0) = 0 (0x0)
geteuid()= 0 (0x0)
write(36,"[2011/11/14 07:26:07.939877, 10]"...,77) = 77 (0x4d)
geteuid()= 0 (0x0)
write(36," smbd_idle_event_handler: idle_"...,61) = 61 (0x3d)
gettimeofday({1321277167.940031 },0x0) = 0 (0x0)
geteuid()= 0 (0x0)
write(36,"[2011/11/14 07:26:07.940031, 5]"...,70) = 70 (0x46)
geteuid()= 0 (0x0)
write(36," housekeeping\n",15) = 15 (0xf)
gettimeofday({1321277167.940177 },0x0) = 0 (0x0)
geteuid()= 0 (0x0)
write(36,"[2011/11/14 07:26:07.940177, 4]"...,65) = 65 (0x41)
geteuid()= 0 (0x0)
write(36," setting sec ctx (0, 0) - sec_c"...,49) = 49 (0x31)
gettimeofday({1321277167.940327 },0x0) = 0 (0x0)
geteuid()= 0 (0x0)
write(36,"[2011/11/14 07:26:07.940327, 5]"...,94) = 94 (0x5e)
geteuid()= 0 (0x0)
write(36," Security token: (NULL)\n",25)= 25 (0x19)
gettimeofday({1321277167.940475 },0x0) = 0 (0x0)
geteuid()= 0 (0x0)
write(36,"[2011/11/14 07:26:07.940475, 5]"...,78) = 78 (0x4e)
geteuid()= 0 (0x0)
write(36," UNIX token of user 0\n",23) = 23 (0x17)
geteuid()= 0 (0x0)
write(36," Primary group is 0 and contain"...,57) = 57 (0x39)
geteuid()= 0 (0x0)
getegid()
Re: samba+zfs
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 tape spool. >>>> >>>>>- How much RAM? >>>> >>>> 8GB. >>>> >>>>>- What debug options do you have enabled in the kernel? >>>> >>>> It is 8.2-GENERIC so.. no WITNESS (for example) >>>> >>>>>I've been noticing a slowdown in some respects with NFS/SMB, but I >>>>> suspected it was because I have an re(4) based NIC. ZFS has also >>>>> wired >>>>> down a lot of my system memory for the L2ARC… >>>> >>>> >>>> re isn't great but I wouldn't expect it to slow down over time.. >>>> Unless bounce buffers got used more and more or something. >>>> >>>> I have an em0 card in this system - but in any case it is slow >>>> locally (i.e. dd a large file with 64k block size). >>>> >>>> -- >>>> Daniel O'Connor software and network engineer >>>> for Genesis Software - http://www.gsoft.com.au >>>> "The nice thing about standards is that there >>>> are so many of them to choose from." >>>> -- Andrew Tanenbaum >>>> GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C >>>> >>>> >>> >>> Right now (while experience slow writes via samba+zfs) this is general >>> read speed off a 4 x 1.5TB sata2 raidz1: >>> >>> # dd if=test.file of=/dev/null >>> 13753502+1 records in >>> 13753502+1 records out >>> 7041793036 bytes transferred in 100.020897 secs (70403218 bytes/sec) >>> >>> That's not in the same ball park of slow writes, but it is below what >>> I expect for reads. >>> >>> My setup is a little odd: 4x1.5tb raidz sata2 on mobo + 2 x 2tb >>> mirror on sata1 pci controller, zfs v28, stable/9 r227357, amd x4 810 >>> 2.6ghz, 4gb ram, no dedupe, no compression, daily snapshots saved for >>> 7 days >>> >>> The above file read was stored before the 2 x 2tb mirror addition, so >>> it was a solely read off the sata2 mobo ports. Reading off of >>> something more recent (and split amongst both raidz1 and mirror >>> vdevs): >>> >>> # dd if=test2.file of=/dev/null >>> 9154715+1 records in >>> 9154715+1 records out >>> 4687214153 bytes transferred in 82.963181 secs (56497522 bytes/sec) >>> >>> This is, again, seems slower than usual, but not as terrible as the >>> write speeds that I've been seeing via samba. >> > > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" -- Peter Maloney Brockmann Consult Max-Planck-Str. 2 21502 Geesthacht Germany Tel: +49 4152 889 300 Fax: +49 4152 889 333 E-mail: peter.malo...@brockmann-consult.de Internet: http://www.brockmann-consult.de ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: samba+zfs
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 105687574:105689034, ack 63894978, win 256, length 1460SMB-over-TCP packet:(raw data or continuation?) 02:52:34.347361 IP (tos 0x0, ttl 64, id 56122, offset 0, flags [none], proto TCP (6), length 1500) asterisk.microsoft-ds > desktop.58858: Flags [.], cksum 0xbe99 (correct), seq 105689034:105690494, ack 63894978, win 256, length 1460SMB-over-TCP packet:(raw data or continuation?) 02:52:34.347365 IP (tos 0x0, ttl 64, id 56123, offset 0, flags [none], proto TCP (6), length 1500) asterisk.microsoft-ds > desktop.58858: Flags [.], cksum 0x0b31 (correct), seq 105690494:105691954, ack 63894978, win 256, length 1460SMB-over-TCP packet:(raw data or continuation?) 02:52:34.347369 IP (tos 0x0, ttl 64, id 56124, offset 0, flags [none], proto TCP (6), length 1500) asterisk.microsoft-ds > desktop.58858: Flags [.], cksum 0xaee6 (correct), seq 105691954:105693414, ack 63894978, win 256, length 1460SMB-over-TCP packet:(raw data or continuation?) 02:52:34.347372 IP (tos 0x0, ttl 64, id 56125, offset 0, flags [none], proto TCP (6), length 1500) asterisk.microsoft-ds > desktop.58858: Flags [.], cksum 0xcff5 (correct), seq 105693414:105694874, ack 63894978, win 256, length 1460SMB-over-TCP packet:(raw data or continuation?) 02:52:34.347376 IP (tos 0x0, ttl 64, id 56126, offset 0, flags [none], proto TCP (6), length 1500) asterisk.microsoft-ds > desktop.58858: Flags [.], cksum 0xd893 (correct), seq 105694874:105696334, ack 63894978, win 256, length 1460SMB-over-TCP packet:(raw data or continuation?) We get a ton of these, my mapped samba drive on Z: becomes nearly unresponsive after i start transferring things through it, yet I can jump on Y: drive which is NFS mount to same interface on machine and everything is fine and responsive Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: d...@sunsaturn.com On Sat, 12 Nov 2011, Dan The Man wrote: 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...@sunsaturn.com On Wed, 9 Nov 2011, Kurt Touet wrote: 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 tape spool. - How much RAM? 8GB. - What debug options do you have enabled in the kernel? It is 8.2-GENERIC so.. no WITNESS (for example) I've been noticing a slowdown in some respects with NFS/SMB, but I suspected it was because I have an re(4) based NIC. ZFS has also wired down a lot of my system memory for the L2ARC… re isn't great but I wouldn't expect it to slow down over time.. Unless bounce buffers got used more and more or something. I have an em0 card in this system - but in any case it is slow locally (i.e. dd a large file with 64k block size). -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C Right now (while experience slow writes via samba+zfs) this is general read speed off a 4 x 1.5TB sata2 raidz1: # dd if=test.file of=/dev/null 13753502+1 records in 13753502+1 records out 7041793036 bytes transferred in 100.020897 secs (70403218 bytes/sec) That's not in the same ball park of slow writes, but it is below what I expect for reads. My setup is a little odd: 4x1.5tb raidz sata2 on mobo + 2 x 2tb mirror on sata1 pci controller, zfs v28, stable/9 r227357, amd x4 810 2.6ghz, 4gb ram, no dedupe, no compression, daily snapshots saved for 7 days The above file read was stored before the 2 x 2tb mirror addition, so it was a solely read off the sata2 mobo ports. Reading off of something more recent (and split amongst both raidz1 and mirror vdevs): # dd if=test2.file of=/dev/null 9154715+1 records in 9154715+1 records out 4687214153 bytes transferred in 82.963181 secs (56497522 bytes/sec) This is, again, seems slower than usual, but not as terrible as the write speeds that I've been seeing via samba. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/li
Re: samba+zfs
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...@sunsaturn.com On Wed, 9 Nov 2011, Kurt Touet wrote: 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 tape spool. - How much RAM? 8GB. - What debug options do you have enabled in the kernel? It is 8.2-GENERIC so.. no WITNESS (for example) I've been noticing a slowdown in some respects with NFS/SMB, but I suspected it was because I have an re(4) based NIC. ZFS has also wired down a lot of my system memory for the L2ARC… re isn't great but I wouldn't expect it to slow down over time.. Unless bounce buffers got used more and more or something. I have an em0 card in this system - but in any case it is slow locally (i.e. dd a large file with 64k block size). -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C Right now (while experience slow writes via samba+zfs) this is general read speed off a 4 x 1.5TB sata2 raidz1: # dd if=test.file of=/dev/null 13753502+1 records in 13753502+1 records out 7041793036 bytes transferred in 100.020897 secs (70403218 bytes/sec) That's not in the same ball park of slow writes, but it is below what I expect for reads. My setup is a little odd: 4x1.5tb raidz sata2 on mobo + 2 x 2tb mirror on sata1 pci controller, zfs v28, stable/9 r227357, amd x4 810 2.6ghz, 4gb ram, no dedupe, no compression, daily snapshots saved for 7 days The above file read was stored before the 2 x 2tb mirror addition, so it was a solely read off the sata2 mobo ports. Reading off of something more recent (and split amongst both raidz1 and mirror vdevs): # dd if=test2.file of=/dev/null 9154715+1 records in 9154715+1 records out 4687214153 bytes transferred in 82.963181 secs (56497522 bytes/sec) This is, again, seems slower than usual, but not as terrible as the write speeds that I've been seeing via samba. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: samba+zfs
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. >> >>> - Compression? >> >> On the mail spool & ports, but not on the tape spool. >> >>> - How much RAM? >> >> 8GB. >>> - What debug options do you have enabled in the kernel? >> >> It is 8.2-GENERIC so.. no WITNESS (for example) > > Ok. 8.2 release or stable? > >>> I've been noticing a slowdown in some respects with NFS/SMB, but I >>> suspected it was because I have an re(4) based NIC. ZFS has also wired >>> down a lot of my system memory for the L2ARC… >> >> >> re isn't great but I wouldn't expect it to slow down over time.. Unless >> bounce buffers got used more and more or something. >> >> I have an em0 card in this system - but in any case it is slow locally (i.e. >> dd a large file with 64k block size). > > Good point. Simple base cases help isolate the root cause. That > being said, my disk speed(s) are a lot better than my network + samba > speeds (zfs:store is mfid0 backed with write cache enabled; zfs:sac is > a single ada(4) backed disk with write cache enabled -- err... it > shouldn't be like that), but I suspect that's misconfiguration on my > part: > > $ sysctl hw.model hw.physmem > hw.model: Intel(R) Xeon(R) CPU W3520 @ 2.67GHz > hw.physmem: 12863094784 > $ sudo mfiutil show volumes > mfi0 Volumes: > Id Size Level Stripe State Cache Name > mfid0 ( 1860G) RAID-6 64k OPTIMAL Enabled > $ zpool status > pool: sac > state: ONLINE > scan: none requested > config: > > NAME STATE READ WRITE CKSUM > sac ONLINE 0 0 0 > ada0p3 ONLINE 0 0 0 > > errors: No known data errors > > pool: store > state: ONLINE > scan: scrub repaired 0 in 10h9m with 0 errors on Mon Nov 7 18:58:01 2011 > config: > > NAME STATE READ WRITE CKSUM > store ONLINE 0 0 0 > mfid0p1 ONLINE 0 0 0 > > errors: No known data errors > $ zfs list -o name,mountpoint,atime,sync,compression,dedup > NAME MOUNTPOINT ATIME SYNC > COMPRESS DEDUP > sac legacy on standard > off off > sac/root / on standard > off off > sac/scratch /scratch on standard > off off > sac/scratch/freenas /scratch/freenas off standard > on off > sac/scratch/freenas/FreeBSD /scratch/freenas/FreeBSD off standard > on off > sac/usr /usr on standard > off off > sac/var /var on standard > off off > store /store on standard > off off > store/freebsd /store/freebsd on standard > on on > store/home /usr/home on standard > off off > $ dd if=/dev/zero of=foo bs=1m count=1024 > 1024+0 records out > 1073741824 bytes transferred in 13.426620 secs (79971119 bytes/sec) > $ cd /store > $ dd if=/dev/zero of=foo bs=1m count=1024 > 1024+0 records in > 1024+0 records out > 1073741824 bytes transferred in 7.565117 secs (141933276 bytes/sec) > $ cat /usr/local/etc/smb.conf > [global] > workgroup = WORKGROUP > server string = BAYONETTA > security = user > load printers = no > max log size = 50 > preferred master = yes > local master = yes > socket options = SO_RCVBUF=16384 SO_SNDBUF=16384 > nt acl support = yes > inherit acls = yes > map acl inherit = yes > aio read size = 16384 > aio write size = 16384 > > [scratch] > path = /scratch > writeable = yes > > [store] > path = /store > writeable = yes > $ > > I'll have to: > 1. Recheck what Windows 7 says when transferring out to my box > with a large file. > 2. Use nc to quickly measure network performance. > 3. Try transferring over NFS with both my Macbook and setup > FreeBSD or Linux on the other workstation for testing out NFS > transfers (64kB rsize/wsize of course). Wash, rinse, repeat with > samba. > The last I remember the transfer speeds were pitiful with samba36 > (somewhere around 45MBps to my 'store' zpool). I've been conservative > with the socket settings, but it might be time to bump that up along > with the mbuf cluster count (for some odd reason I haven't changed it > from the system default), reboot, and retest. > Thanks, > -Garrett > I have fo
Re: samba+zfs
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 tape spool. > >> - How much RAM? > > 8GB. >> - What debug options do you have enabled in the kernel? > > It is 8.2-GENERIC so.. no WITNESS (for example) Ok. 8.2 release or stable? >> I've been noticing a slowdown in some respects with NFS/SMB, but I >> suspected it was because I have an re(4) based NIC. ZFS has also wired >> down a lot of my system memory for the L2ARC… > > > re isn't great but I wouldn't expect it to slow down over time.. Unless > bounce buffers got used more and more or something. > > I have an em0 card in this system - but in any case it is slow locally (i.e. > dd a large file with 64k block size). Good point. Simple base cases help isolate the root cause. That being said, my disk speed(s) are a lot better than my network + samba speeds (zfs:store is mfid0 backed with write cache enabled; zfs:sac is a single ada(4) backed disk with write cache enabled -- err... it shouldn't be like that), but I suspect that's misconfiguration on my part: $ sysctl hw.model hw.physmem hw.model: Intel(R) Xeon(R) CPU W3520 @ 2.67GHz hw.physmem: 12863094784 $ sudo mfiutil show volumes mfi0 Volumes: Id SizeLevel Stripe State Cache Name mfid0 ( 1860G) RAID-6 64k OPTIMAL Enabled $ zpool status pool: sac state: ONLINE scan: none requested config: NAMESTATE READ WRITE CKSUM sac ONLINE 0 0 0 ada0p3ONLINE 0 0 0 errors: No known data errors pool: store state: ONLINE scan: scrub repaired 0 in 10h9m with 0 errors on Mon Nov 7 18:58:01 2011 config: NAMESTATE READ WRITE CKSUM store ONLINE 0 0 0 mfid0p1 ONLINE 0 0 0 errors: No known data errors $ zfs list -o name,mountpoint,atime,sync,compression,dedup NAME MOUNTPOINTATIME SYNC COMPRESS DEDUP sac legacy on standard offoff sac/root /on standard offoff sac/scratch /scratch on standard offoff sac/scratch/freenas /scratch/freenasoff standard onoff sac/scratch/freenas/FreeBSD /scratch/freenas/FreeBSDoff standard onoff sac/usr /usr on standard offoff sac/var /var on standard offoff store/store on standard offoff store/freebsd/store/freebsd on standard on on store/home /usr/homeon standard offoff $ dd if=/dev/zero of=foo bs=1m count=1024 1024+0 records out 1073741824 bytes transferred in 13.426620 secs (79971119 bytes/sec) $ cd /store $ dd if=/dev/zero of=foo bs=1m count=1024 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 7.565117 secs (141933276 bytes/sec) $ cat /usr/local/etc/smb.conf [global] workgroup = WORKGROUP server string = BAYONETTA security = user load printers = no max log size = 50 preferred master = yes local master = yes socket options = SO_RCVBUF=16384 SO_SNDBUF=16384 nt acl support = yes inherit acls = yes map acl inherit = yes aio read size = 16384 aio write size = 16384 [scratch] path = /scratch writeable = yes [store] path = /store writeable = yes $ I'll have to: 1. Recheck what Windows 7 says when transferring out to my box with a large file. 2. Use nc to quickly measure network performance. 3. Try transferring over NFS with both my Macbook and setup FreeBSD or Linux on the other workstation for testing out NFS transfers (64kB rsize/wsize of course). Wash, rinse, repeat with samba. The last I remember the transfer speeds were pitiful with samba36 (somewhere around 45MBps to my 'store' zpool). I've been conservative with the socket settings, but it might be time to bump that up along with the mbuf cluster count (for some odd reason I haven't changed it from the system default), reboot, and retest. Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: samba+zfs
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 dedupratio If it is not 1.00x, then even though your dedup may be disabled, your data is deduped. >>- Compression? > On the mail spool & ports, but not on the tape spool. > >>- How much RAM? > 8GB. Why are your memory settings set so low if you have 8 GB of memory? Do you need 6.2 GB left over for other apps? On 11/08/2011 10:26 AM, Dan The Man wrote: > vm.kmem_size="1844M" > vfs.zfs.arc_min="1024M" > vfs.zfs.arc_max="1536M" On my machine with 48 GB of memory, I set: vm.kmem_size="44g" vm.kmem_size_max="44g" vfs.zfs.arc_min="80m" vfs.zfs.arc_max="42g" And now it is very fast. My dataset is only about 10 TiB, and the total space is around 32 TiB. In practice, it uses about 36g of ARC and 151g of L2ARC, rather than the full 42g. Before, writes were quite slow when doing read at the same time (such as simply using cp). You shouldn't set those the way I did, using all for ZFS, because you are also using UFS, which needs some memory too. Also, my machine has no services other than ssh, nfs, and samba. I guess leave some for whatever services you run (or does the kernel give up its memory it used when userspace apps want more, like in Linux?). Also, instead of vfs.zfs.zil_disable="1" you should try setting "sync=disabled" # zfs set sync=disabled somepool/someasyncdataset And to find out if it is a bad disk or some IO bottleneck, use gstat to check the load % while it is doing the slow writing. eg. # gstat -I 5s -f "gpt/root|label/.ank|gpt/log|gpt/cache" >>- What debug options do you have enabled in the kernel? > It is 8.2-GENERIC so.. no WITNESS (for example) > >>I've been noticing a slowdown in some respects with NFS/SMB, but I >> suspected it was because I have an re(4) based NIC. ZFS has also wired >> down a lot of my system memory for the L2ARC… > > re isn't great but I wouldn't expect it to slow down over time.. Unless > bounce buffers got used more and more or something. > > I have an em0 card in this system - but in any case it is slow locally (i.e. > dd a large file with 64k block size). > > -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > > > > > > > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" -- Peter Maloney Brockmann Consult Max-Planck-Str. 2 21502 Geesthacht Germany Tel: +49 4152 889 300 Fax: +49 4152 889 333 E-mail: peter.malo...@brockmann-consult.de Internet: http://www.brockmann-consult.de ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: samba+zfs
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 tape spool. > >> - How much RAM? > > 8GB. > >> - What debug options do you have enabled in the kernel? > > It is 8.2-GENERIC so.. no WITNESS (for example) > >> I've been noticing a slowdown in some respects with NFS/SMB, but I >> suspected it was because I have an re(4) based NIC. ZFS has also wired >> down a lot of my system memory for the L2ARC… > > > re isn't great but I wouldn't expect it to slow down over time.. Unless > bounce buffers got used more and more or something. > > I have an em0 card in this system - but in any case it is slow locally (i.e. > dd a large file with 64k block size). > > -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > > Right now (while experience slow writes via samba+zfs) this is general read speed off a 4 x 1.5TB sata2 raidz1: # dd if=test.file of=/dev/null 13753502+1 records in 13753502+1 records out 7041793036 bytes transferred in 100.020897 secs (70403218 bytes/sec) That's not in the same ball park of slow writes, but it is below what I expect for reads. My setup is a little odd: 4x1.5tb raidz sata2 on mobo + 2 x 2tb mirror on sata1 pci controller, zfs v28, stable/9 r227357, amd x4 810 2.6ghz, 4gb ram, no dedupe, no compression, daily snapshots saved for 7 days The above file read was stored before the 2 x 2tb mirror addition, so it was a solely read off the sata2 mobo ports. Reading off of something more recent (and split amongst both raidz1 and mirror vdevs): # dd if=test2.file of=/dev/null 9154715+1 records in 9154715+1 records out 4687214153 bytes transferred in 82.963181 secs (56497522 bytes/sec) This is, again, seems slower than usual, but not as terrible as the write speeds that I've been seeing via samba. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: samba+zfs
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 you have enabled in the kernel? It is 8.2-GENERIC so.. no WITNESS (for example) >I've been noticing a slowdown in some respects with NFS/SMB, but I > suspected it was because I have an re(4) based NIC. ZFS has also wired > down a lot of my system memory for the L2ARC… re isn't great but I wouldn't expect it to slow down over time.. Unless bounce buffers got used more and more or something. I have an em0 card in this system - but in any case it is slow locally (i.e. dd a large file with 64k block size). -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: samba+zfs
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. >> >> 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 (10-30MB/sec). >> >> When the array was fresh it was nice and fast - it is now 68% full and >> hasn't been much more full than that (I don't know but am pretty sure it >> never reach past 75%). >> >> The frustrating thing is trying to find some way of measuring what's >> actually going on.. I haven't had much luck : > > > Note that this is not restricted to Samba and while the server is not > completely idle it's not doing very much. > > dd's of large files (spooled backups going to tape) to /dev/null are as slow > as Samba. - Dedupe? - Compression? - How much RAM? - What debug options do you have enabled in the kernel? I've been noticing a slowdown in some respects with NFS/SMB, but I suspected it was because I have an re(4) based NIC. ZFS has also wired down a lot of my system memory for the L2ARC... Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: samba+zfs
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 is (now) very > slow - it reads & writes and much more slowly (10-30MB/sec). > > When the array was fresh it was nice and fast - it is now 68% full and hasn't > been much more full than that (I don't know but am pretty sure it never reach > past 75%). > > The frustrating thing is trying to find some way of measuring what's actually > going on.. I haven't had much luck : Note that this is not restricted to Samba and while the server is not completely idle it's not doing very much. dd's of large files (spooled backups going to tape) to /dev/null are as slow as Samba. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: samba+zfs
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 (10-30MB/sec). When the array was fresh it was nice and fast - it is now 68% full and hasn't been much more full than that (I don't know but am pretty sure it never reach past 75%). The frustrating thing is trying to find some way of measuring what's actually going on.. I haven't had much luck :( -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: samba+zfs
lock on file >>>> torrent_downloads_finished/Point.Break.1991.720p (1).mkv >>>> [2011/11/08 03:24:00.068010, 10] >>>> locking/locking.c:162(strict_lock_default) >>>> strict_lock_default: flavour = WINDOWS_LOCK brl start=83431665 >>>> len=65536 >>>> unlocked for fnum 49966 file >>>> torrent_downloads_finished/Point.Break.1991.720p (1).mkv >>>> [2011/11/08 03:24:00.068021, 10] lib/recvfile.c:65(default_sys_recvfile) >>>> default_sys_recvfile: from = 33, to = 39, offset=83431665, count = >>>> 65536 >>>> [2011/11/08 03:24:00.068995, 10] smbd/fileio.c:143(real_write_file) >>>> real_write_file (torrent_downloads_finished/Point.Break.1991.720p >>>> (1).mkv): pos = 83431665, size = 65536, returned 65536 >>>> [2011/11/08 03:24:00.069013, 3] smbd/reply.c:4639(reply_write_and_X) >>>> writeX fnum=49966 num=65536 wrote=65536 >>>> [2011/11/08 03:24:00.069038, 10] >>>> lib/util_sock.c:516(read_smb_length_return_keepalive) >>>> got smb length of 65600 >>>> [2011/11/08 03:24:00.069052, 10] >>>> smbd/reply.c:4459(is_valid_writeX_buffer) >>>> is_valid_writeX_buffer: true len = 65600, doff = 64, numtowrite = 65536 >>>> [2011/11/08 03:24:00.069062, 6] smbd/process.c:1659(process_smb) >>>> got message type 0x0 of len 0x3f >>>> [2011/11/08 03:24:00.069072, 3] smbd/process.c:1661(process_smb) >>>> Transaction 15398 of length 67 (65536 toread) >>>> [2011/11/08 03:24:00.069081, 5] lib/util.c:332(show_msg) >>>> [2011/11/08 03:24:00.069087, 5] lib/util.c:342(show_msg) >>>> size=63 >>>> smb_com=0x2f >>>> smb_rcls=0 >>>> smb_reh=0 >>>> smb_err=0 >>>> smb_flg=24 >>>> smb_flg2=51207 >>>> smb_tid=1 >>>> smb_pid=65279 >>>> smb_uid=0 >>>> smb_mid=36032 >>>> smt_wct=14 >>>> smb_vwv[ 0]= 255 (0xFF) >>>> smb_vwv[ 1]=57054 (0xDEDE) >>>> smb_vwv[ 2]=49966 (0xC32E) >>>> smb_vwv[ 3]= 4337 (0x10F1) >>>> smb_vwv[ 4]= 1274 (0x4FA) >>>> smb_vwv[ 5]=65535 (0x) >>>> smb_vwv[ 6]=65535 (0xFFFF) >>>> smb_vwv[ 7]= 0 (0x0) >>>> smb_vwv[ 8]= 0 (0x0) >>>> smb_vwv[ 9]= 1 (0x1) >>>> smb_vwv[10]= 0 (0x0) >>>> smb_vwv[11]= 64 (0x40) >>>> smb_vwv[12]= 0 (0x0) >>>> smb_vwv[13]= 0 (0x0) >>>> smb_bcc=0 >>>> [2011/11/08 03:24:00.069163, 10] ../lib/util/util.c:415(dump_data) >>>> [2011/11/08 03:24:00.069170, 3] smbd/process.c:1466(switch_message) >>>> switch message SMBwriteX (pid 64308) conn 0x805008450 >>>> [2011/11/08 03:24:00.069179, 4] smbd/uid.c:345(change_to_user) >>>> Skipping user change - already user >>>> [2011/11/08 03:24:00.069188, 10] >>>> locking/locking.c:120(strict_lock_default) >>>> is_locked: optimisation - exclusive oplock on file >>>> torrent_downloads_finished/Point.Break.1991.720p (1).mkv >>>> [2011/11/08 03:24:00.069197, 10] >>>> locking/locking.c:162(strict_lock_default) >>>> strict_lock_default: flavour = WINDOWS_LOCK brl start=83497201 >>>> len=65536 >>>> unlocked for fnum 49966 file >>>> torrent_downloads_finished/Point.Break.1991.720p (1).mkv >>>> [2011/11/08 03:24:00.069221, 10] lib/recvfile.c:65(default_sys_recvfile) >>>> default_sys_recvfile: from = 33, to = 39, offset=83497201, count = >>>> 65536 >>>> [2011/11/08 03:24:00.069987, 10] smbd/fileio.c:143(real_write_file) >>>> real_write_file (torrent_downloads_finished/Point.Break.1991.720p >>>> (1).mkv): pos = 83497201, size = 65536, returned 65536 >>>> [2011/11/08 03:24:00.070004, 3] smbd/reply.c:4639(reply_write_and_X) >>>> writeX fnum=49966 num=65536 wrote=65536 >>>> [2011/11/08 03:24:00.070030, 10] >>>> lib/util_sock.c:516(read_smb_length_return_keepalive) >>>> got smb length of 65600 >>>> [2011/11/08 03:24:00.070044, 10] >>>> smbd/reply.c:4459(is_valid_writeX_buffer) >>>> is_valid_writeX_buffer: true len = 65600, doff = 64, numtowrite = 65536 >>>> [2011/11/08 03:24:00.070053, 6] smbd/process.c:1659(process_smb) >>>> got message type 0x0 of len 0x3f >>>> [2011/11/08 03:24:00.070063, 3] smbd/process.c:1661(process_smb) >>>> Transaction 15399 of length 67 (65536 toread) >>>> [2011/11/08 03:24:00.070072, 5] lib/util.c:332(show_msg) >>>> [2011/11/08 03:24:00.070077, 5] lib/util.c:342(show_msg) >>>> size=63 >>>> smb_com=0x2f >>>> smb_rcls=0 >>>> smb_reh=0 >>>> smb_err=0 >>>> smb_flg=24 >>>> smb_flg2=51207 >>>> smb_tid=1 >>>> smb_pid=65279 >>>> smb_uid=0 >>>> smb_mid=36102 >>>> smt_wct=14 >>>> smb_vwv[ 0]= 255 (0xFF) >>>> smb_vwv[ 1]=57054 (0xDEDE) >>>> smb_vwv[ 2]=49966 (0xC32E) >>>> smb_vwv[ 3]= 4337 (0x10F1) >>>> smb_vwv[ 4]= 1275 (0x4FB) >>>> smb_vwv[ 5]=65535 (0x) >>>> smb_vwv[ 6]=65535 (0x) >>>> smb_vwv[ 7]= 0 (0x0) >>>> smb_vwv[ 8]= 0 (0x0) >>>> smb_vwv[ 9]= 1 (0x1) >>>> smb_vwv[10]= 0 (0x0) >>>> smb_vwv[11]= 64 (0x40) >>>> smb_vwv[12]= 0 (0x0) >>>> smb_vwv[13]= 0 (0x0) >>>> smb_bcc=0 >>>> >>>> >>>> Hopefully maybe someone can shine some light on this >>>> >>>> >>>> Dan. >>>> >>>> >>>> -- >>>> Dan The Man >>>> CTO/ Senior System Administrator >>>> Websites, Domains and Everything else >>>> http://www.SunSaturn.com >>>> Email: d...@sunsaturn.com >>>> >>>> On Fri, 28 Oct 2011, Garrett Cooper wrote: >>>> >>>>> 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 upgrade Samba? >>>>> - What is your system's operating hardware profile? >>>>> Thanks! >>>>> -Garrett >>>>> >> >> I had noticed a similar problem with doing large writes from my >> windows workstation to my freebsd ZFS array. Previously I had been >> able to write at around 30MB/s (limited by a slow SATA controller), >> and those speeds had dropped to 3-5MB/s with long pauses between >> writes to the array (monitoring with zpool iostat). However, I just >> updated to stable/9 r227357 and the issue seems to have gone away; I'm >> back up to 30MB/s writes. >> >> Hope you find the same sort of thing, >> -kurt >> > > Yep your right, on RC2 my samba ZFS write speeds are back. > Thanks for heads up Kurt. > > > Dan. > > > -- > Dan The Man > CTO/ Senior System Administrator > Websites, Domains and Everything else > http://www.SunSaturn.com > Email: d...@sunsaturn.com > I may have spoken too soon. With the speeds back up to normal, I moved a bunch of content that I'd been storing temporarily on my workstation to the server. After a few hours and moving 40gb+ of content (not all at once), I noticed the same write problems cropping up again. I rebooted the server and speeds came back to normal. The oddity that I notice is that the array seems to be delaying writes to a single disc in my raidz1 vdev, and then writing out very slowly to it (1-2MB/s). The drive that it is doing it with has absolutely zero read/write/seek errors in SMART, and works just fine after the box is rebooted (so it shouldn't be a drive issue). The only thing interesting about this drive is that it replaced a failed drive a few weeks ago. Is anyone else seeing problems like this with samba/zfs ?Perhaps it's not exclusive to samba, either? -kurt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: samba+zfs
smb_flg2=51207 smb_tid=1 smb_pid=65279 smb_uid=0 smb_mid=36102 smt_wct=14 smb_vwv[ 0]= 255 (0xFF) smb_vwv[ 1]=57054 (0xDEDE) smb_vwv[ 2]=49966 (0xC32E) smb_vwv[ 3]= 4337 (0x10F1) smb_vwv[ 4]= 1275 (0x4FB) smb_vwv[ 5]=65535 (0x) smb_vwv[ 6]=65535 (0x) smb_vwv[ 7]= 0 (0x0) smb_vwv[ 8]= 0 (0x0) smb_vwv[ 9]= 1 (0x1) smb_vwv[10]= 0 (0x0) smb_vwv[11]= 64 (0x40) smb_vwv[12]= 0 (0x0) smb_vwv[13]= 0 (0x0) smb_bcc=0 Hopefully maybe someone can shine some light on this Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: d...@sunsaturn.com On Fri, 28 Oct 2011, Garrett Cooper wrote: 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 upgrade Samba? - What is your system's operating hardware profile? Thanks! -Garrett I had noticed a similar problem with doing large writes from my windows workstation to my freebsd ZFS array. Previously I had been able to write at around 30MB/s (limited by a slow SATA controller), and those speeds had dropped to 3-5MB/s with long pauses between writes to the array (monitoring with zpool iostat). However, I just updated to stable/9 r227357 and the issue seems to have gone away; I'm back up to 30MB/s writes. Hope you find the same sort of thing, -kurt Yep your right, on RC2 my samba ZFS write speeds are back. Thanks for heads up Kurt. Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: d...@sunsaturn.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: samba+zfs
A) >> smb_vwv[ 5]=65535 (0x) >> smb_vwv[ 6]=65535 (0x) >> smb_vwv[ 7]= 0 (0x0) >> smb_vwv[ 8]= 0 (0x0) >> smb_vwv[ 9]= 1 (0x1) >> smb_vwv[10]= 0 (0x0) >> smb_vwv[11]= 64 (0x40) >> smb_vwv[12]= 0 (0x0) >> smb_vwv[13]= 0 (0x0) >> smb_bcc=0 >> [2011/11/08 03:24:00.069163, 10] ../lib/util/util.c:415(dump_data) >> [2011/11/08 03:24:00.069170, 3] smbd/process.c:1466(switch_message) >> switch message SMBwriteX (pid 64308) conn 0x805008450 >> [2011/11/08 03:24:00.069179, 4] smbd/uid.c:345(change_to_user) >> Skipping user change - already user >> [2011/11/08 03:24:00.069188, 10] >> locking/locking.c:120(strict_lock_default) >> is_locked: optimisation - exclusive oplock on file >> torrent_downloads_finished/Point.Break.1991.720p (1).mkv >> [2011/11/08 03:24:00.069197, 10] >> locking/locking.c:162(strict_lock_default) >> strict_lock_default: flavour = WINDOWS_LOCK brl start=83497201 len=65536 >> unlocked for fnum 49966 file >> torrent_downloads_finished/Point.Break.1991.720p (1).mkv >> [2011/11/08 03:24:00.069221, 10] lib/recvfile.c:65(default_sys_recvfile) >> default_sys_recvfile: from = 33, to = 39, offset=83497201, count = 65536 >> [2011/11/08 03:24:00.069987, 10] smbd/fileio.c:143(real_write_file) >> real_write_file (torrent_downloads_finished/Point.Break.1991.720p >> (1).mkv): pos = 83497201, size = 65536, returned 65536 >> [2011/11/08 03:24:00.070004, 3] smbd/reply.c:4639(reply_write_and_X) >> writeX fnum=49966 num=65536 wrote=65536 >> [2011/11/08 03:24:00.070030, 10] >> lib/util_sock.c:516(read_smb_length_return_keepalive) >> got smb length of 65600 >> [2011/11/08 03:24:00.070044, 10] smbd/reply.c:4459(is_valid_writeX_buffer) >> is_valid_writeX_buffer: true len = 65600, doff = 64, numtowrite = 65536 >> [2011/11/08 03:24:00.070053, 6] smbd/process.c:1659(process_smb) >> got message type 0x0 of len 0x3f >> [2011/11/08 03:24:00.070063, 3] smbd/process.c:1661(process_smb) >> Transaction 15399 of length 67 (65536 toread) >> [2011/11/08 03:24:00.070072, 5] lib/util.c:332(show_msg) >> [2011/11/08 03:24:00.070077, 5] lib/util.c:342(show_msg) >> size=63 >> smb_com=0x2f >> smb_rcls=0 >> smb_reh=0 >> smb_err=0 >> smb_flg=24 >> smb_flg2=51207 >> smb_tid=1 >> smb_pid=65279 >> smb_uid=0 >> smb_mid=36102 >> smt_wct=14 >> smb_vwv[ 0]= 255 (0xFF) >> smb_vwv[ 1]=57054 (0xDEDE) >> smb_vwv[ 2]=49966 (0xC32E) >> smb_vwv[ 3]= 4337 (0x10F1) >> smb_vwv[ 4]= 1275 (0x4FB) >> smb_vwv[ 5]=65535 (0x) >> smb_vwv[ 6]=65535 (0x) >> smb_vwv[ 7]= 0 (0x0) >> smb_vwv[ 8]= 0 (0x0) >> smb_vwv[ 9]= 1 (0x1) >> smb_vwv[10]= 0 (0x0) >> smb_vwv[11]= 64 (0x40) >> smb_vwv[12]= 0 (0x0) >> smb_vwv[13]= 0 (0x0) >> smb_bcc=0 >> >> >> Hopefully maybe someone can shine some light on this >> >> >> Dan. >> >> >> -- >> Dan The Man >> CTO/ Senior System Administrator >> Websites, Domains and Everything else >> http://www.SunSaturn.com >> Email: d...@sunsaturn.com >> >> On Fri, 28 Oct 2011, Garrett Cooper wrote: >> >>> 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 upgrade Samba? >>> - What is your system's operating hardware profile? >>> Thanks! >>> -Garrett >>> I had noticed a similar problem with doing large writes from my windows workstation to my freebsd ZFS array. Previously I had been able to write at around 30MB/s (limited by a slow SATA controller), and those speeds had dropped to 3-5MB/s with long pauses between writes to the array (monitoring with zpool iostat). However, I just updated to stable/9 r227357 and the issue seems to have gone away; I'm back up to 30MB/s writes. Hope you find the same sort of thing, -kurt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: samba+zfs
smb_tid=1 smb_pid=65279 smb_uid=0 smb_mid=36102 smt_wct=14 smb_vwv[ 0]= 255 (0xFF) smb_vwv[ 1]=57054 (0xDEDE) smb_vwv[ 2]=49966 (0xC32E) smb_vwv[ 3]= 4337 (0x10F1) smb_vwv[ 4]= 1275 (0x4FB) smb_vwv[ 5]=65535 (0x) smb_vwv[ 6]=65535 (0x) smb_vwv[ 7]=0 (0x0) smb_vwv[ 8]=0 (0x0) smb_vwv[ 9]=1 (0x1) smb_vwv[10]=0 (0x0) smb_vwv[11]= 64 (0x40) smb_vwv[12]=0 (0x0) smb_vwv[13]=0 (0x0) smb_bcc=0 Hopefully maybe someone can shine some light on this Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: d...@sunsaturn.com On Fri, 28 Oct 2011, Garrett Cooper wrote: 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 upgrade Samba? - What is your system's operating hardware profile? Thanks! -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: samba+zfs
]=0 (0x0) smb_vwv[11]= 64 (0x40) smb_vwv[12]=0 (0x0) smb_vwv[13]=0 (0x0) smb_bcc=0 Hopefully maybe someone can shine some light on this Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: d...@sunsaturn.com On Fri, 28 Oct 2011, Garrett Cooper wrote: 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 upgrade Samba? - What is your system's operating hardware profile? Thanks! -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: samba+zfs
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 upgrade Samba? - What is your system's operating hardware profile? Thanks! -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
samba+zfs
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. Dan. - Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: d...@sunsaturn.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
