8.1-STABLE: zfs and sendfile: problem still exists
Hi! I've noticed that ZFS on 8.1-STABLE still has problems with sendfile. When accessing a file at first time the transfer speed is too low, but on following attempts the transfer speed is normal. How to repeat: $ dd if=/dev/random of=/tmp/test bs=1m count=100 100+0 records in 100+0 records out 104857600 bytes transferred in 5.933945 secs (17670807 bytes/sec) $ sudo env LC_ALL=C /usr/libexec/ftpd -D The first attempt to fetch file: $ fetch -o /dev/null ftp://localhost/tmp/test /dev/null 1% of 100 MB 118 kBps 14m07s^C fetch: transfer interrupted The transfer rate is too low (approx. 120 kBps), but any subsequent attempts are success: $ fetch -o /dev/null ftp://localhost/tmp/test /dev/null 100% of 100 MB 42 MBps $ fetch -o /dev/null ftp://localhost/tmp/test /dev/null 100% of 100 MB 47 MBps ... To repeat it is enough to copy a file and to try again: $ cp /tmp/test /tmp/test1 $ fetch -o /dev/null ftp://localhost/tmp/test1 /dev/null 2% of 100 MB 119 kBps 13m50s^C fetch: transfer interrupted $ fetch -o /dev/null ftp://localhost/tmp/test1 /dev/null 100% of 100 MB 41 MBps $ fetch -o /dev/null ftp://localhost/tmp/test1 /dev/null 100% of 100 MB 47 MBps ...and again: $ cp /tmp/test1 /tmp/test2 $ fetch -o /dev/null ftp://localhost/tmp/test2 /dev/null 1% of 100 MB 118 kBps 14m07s^C fetch: transfer interrupted $ fetch -o /dev/null ftp://localhost/tmp/test2 /dev/null 100% of 100 MB 41 MBps $ fetch -o /dev/null ftp://localhost/tmp/test2 /dev/null 100% of 100 MB 47 MBps I've tried ftpd and nginx with sendfile on. The behavior is the same. After disabling using sendfile in nginx (sendfile off) the problem has gone. -- Alexander Zagrebin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS write speed
28.10.10, 01:54, Stefan Bethke s...@lassitu.de: Am 27.10.2010 um 22:51 schrieb S.N.Grigoriev: Hi list, I've got very low write speed using ZFS on a SATA disk. My HDD configuration is: ad4: 70911MB at ata2-master UDMA100 SATA 3Gb/s ad6: 78532MB at ata3-master UDMA100 SATA 1.5Gb/s ad8: 1430799MB at ata4-master UDMA100 SATA 3Gb/s The EARS has 4k sectors, if I'm not mistaken. I don't recall the eventual outcome, but there was a long thread on stable or hackers on how to ensure proper alignment and (minimun) 4k-sized writes to make sure the disk doesn't have to do a read-modify-write cycle, so try and search the archives. Stefan, thank you for your response. I'll try to find the topic you pointed. ad4 and ad6 are single-slice disks (UFS2 with soft updates) ZFS configuration is following: zpool create Z ad8 zfs create Z/music zfs create Z/video All ZFS parameters are default. kern.maxvnodes = 100 To test my configuration I recursively copied from ad6 to ad8 two directories. The first one contains MP3 files (average size = 10MB). The second one contains AVI files (average size = 1GB). To compare performance I repeated above tests with ad8 using UFS2 with soft updates. 18GB of MP3 files required 10m35s to copy to UFS2 and 21m40s to copy to ZFS. 30GB of AVI files required 16m6s to copy to UFS2 and 1h2m39s to copy to ZFS. I used for tests FreeBSD 8.1R amd64. Amount of RAM on my machine is 6GB. Any tips? -- -- Regards, Serguey. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Can't build boot blocks after new GPT attributes added
On Wed, Oct 27, 2010 at 09:27:03AM -0400, John Baldwin wrote: Maybe you could add text to the handbook to say this, but it is already implicitly assumed in the handbook section you are referring to since it assumes you can safely compile a new kernel, etc. [...] If we were to document those every time it would clutter documentation making it harder for someone who is new to FreeBSD to simply setup a serial console on a box that they just installed. It sounds like what we need is a tutorial, and (somewhere else?) the extended version. People seem to trip over things like this fairly often; at least this way we could refer them to a standard text. No, I don't have the backgroud, or cycles, to write it :-) mcl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: cdrtools /devel and wodim broken
on 28/10/2010 00:08 Jakub Lach said the following: Sean C. Farley-2 wrote: For me, the solution appeared to be setting the grace time to three seconds to avoid the slowdown of the drive: gracetime=3 At least, the disc worked on subsequent burns this way. Jakub, you may try to see if this setting helps. No, gracetime doesn't help. Maybe Alexander Motin could shed some light on (ahci?) problem? So maybe it's worth while getting in contact with him? -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: cdrtools /devel and wodim broken
Hi, your problem: Track 01:0 of 2858 MB written.cdrecord: Input/output error. write_g1: scsi sendcmd: retryable error CDB: 2A 00 00 00 00 00 00 00 20 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Sense Key: 0x [], Segment 0 Sense Code: 0x00 Qual 0x00 (no additional sense information) Fru 0x0 Sense flags: Blk 0 (not valid)=20 cmd finished after 23.946s timeout 200s is caused by a bug in a driver in the kernel. Status byte == 2 (Check Condition) together with empty sense data and unset sense key is impossible. Cdrecord can only behave in a useful way if SCSI error messages are correctly returned by the kernel. I recommend you to run scgcheck in order to find whether the driver yiu are using always behaves incorectly or whether this may be a result os a situation the autor of the driver did not expect. If you don't know how to run scgcheck, you may start with scgcheck -auto. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: cdrtools /devel and wodim broken
So maybe it's worth while getting in contact with him? I wanted to confirm problem is related to ahci before bugging him directly. I'm long time ahci user and would like to retain it, it would be nice If somebody with working cdrecord would load ahci for a test (by default it's not used in GENERIC) + run scgcheck. Scgcheck 3.00 (amd64-unknown-freebsd8.1) SCSI user level transport library ABI checker. Copyright (C) 1998-2008 Jörg Schilling ** Checking whether your implementation supports to scan the SCSI bus. Trying to open device: '(NULL POINTER)'. Using libscg version 'schily-0.9' Max DMA buffer size: 65536 scsibus0: 0,0,0 0) '' '' '' NON CCS Disk 0,1,0 1) * 0,2,0 2) * 0,3,0 3) * 0,4,0 4) * 0,5,0 5) * 0,6,0 6) * 0,7,0 7) * scsibus1: 1,0,0 100) 'HL-DT-ST' 'DVDRAM GSA-U20N ' 'HX11' Removable CD-ROM 1,1,0 101) * 1,2,0 102) * 1,3,0 103) * 1,4,0 104) * 1,5,0 105) * 1,6,0 106) * 1,7,0 107) * -- SCSI scan bus test PASSED For the next test we need to open a single SCSI device. Best results will be obtained if you specify a modern CD-ROM drive. No target specified, trying to find one... Using dev=1,0,0. Enter SCSI device name [1,0,0]: Trying to open device: '1,0,0'. Using libscg version 'schily-0.9' Max DMA buffer size: 65536 Device type: Removable CD-ROM Version: 0 Response Format: 2 Capabilities : Vendor_info: 'HL-DT-ST' Identifikation : 'DVDRAM GSA-U20N ' Revision : 'HX11' Ready to start test for second SCSI open? Enter CR to continue: First SCSI open OK - device usable ** Checking for second SCSI open. Second SCSI open for same device succeeded, 1 additional file descriptor(s) used. Second SCSI open is usable Closing second SCSI. Checking first SCSI. First SCSI open is still usable -- Second SCSI open test PASSED. First SCSI open is still usable Ready to start test for succeeded command? Enter CR to continue: ** Checking for succeeded SCSI command. Executing 'inquiry' command on Bus 1 Target 0, Lun 0 timeout 40s CDB: 12 00 00 00 24 00 cmd finished after 0.001s timeout 40s Inquiry Data : 05 80 00 32 5B 00 00 00 48 4C 2D 44 54 2D 53 54 44 56 44 52 41 4D 20 47 53 41 2D 55 32 30 4E 20 48 58 31 31 -- SCSI succeeded command test PASSED Ready to start test for failing command? Enter CR to continue: ** Testing for failed SCSI command. scgcheck: Input/output error. inquiry: scsi sendcmd: retryable error CDB: 12 00 00 FF 24 00 status: 0x0 (GOOD STATUS) cmd finished after 0.013s timeout 40s -- SCSI Transport return != SCG_NO_ERROR (1) -- SCSI status byte set to 0 (0x0) -- SCSI failed command test FAILED Ready to start test for sense data count? Enter CR to continue: ** Testing for SCSI sense data count. ** Testing if at least CCS_SENSE_LEN (18) is supported... Sense Data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -- Method 0x00: expected: 18 reported: 32 max found: 0 Sense Data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -- Method 0xFF: expected: 18 reported: 32 max found: 18 -- Wanted 18 sense bytes, got it. -- Libscg says 32 sense bytes but got (18) ** Testing for 32 bytes of sense data... Sense Data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -- Method 0x00: expected: 32 reported: 32 max found: 0 Sense Data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -- Method 0xFF: expected: 32 reported: 32 max found: 32 -- Wanted 32 sense bytes, got it. -- Got a maximum of 32 sense bytes -- SCSI sense count test FAILED Ready to start test for working DMA residual count? Enter CR to continue: ** Testing for working DMA residual count. ** Testing for working DMA residual count == 0. CDB cnt: 36 DMA cnt: 36 got really: 36 (System says: RDMA cnt: 36 resid 0) CDB cnt: 36 DMA cnt: 36 got really: 36 (System says: RDMA cnt: 36 resid 0) -- Wanted 36 bytes, got it. -- SCSI DMA residual count == 0 test PASSED Ready to start test for working DMA residual count == DMA count? Enter CR to continue: CDB cnt: 0 DMA cnt: 36 got really: 0 (System says: RDMA cnt: 36 resid 0) CDB cnt: 0 DMA cnt: 36 got really: 0 (System says: RDMA cnt: 36 resid 0) -- Wanted 0 bytes, got it. -- Libscg says 36 bytes but got (0) -- SCSI DMA residual count == DMA count test FAILED -- SCSI DMA residual count not working - no further tests -- SCSI transport code test NOT YET READY regards, - Jakub Lach -- View this message in context: http://old.nabble.com/cdrtools--devel-and-wodim-broken-tp29978939p30077727.html Sent from the
Re: hast vs ggate+gmirror sychrnoisation speed
In hast_proto_send() we send header and then data. Couldn't it be that remote_send and sync threads interfere and their packets are mixed? May be some synchronization is needed here? Interesting - I haven't looked very closely at the code, but I didn't realise that more than one thread was in communication with the remote end. If that's true then theres always a possibility for mixed data if you are sending it in chunks surely ? I set sleep(1) in hast_proto_send() between proto_send(header) and proto_send(data). The error started to occur frequently. Where is the potential other write occuring ? I might try wrapping some locking round the calls to see what happens. -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: hast vs ggate+gmirror sychrnoisation speed
On Wed, Oct 27, 2010 at 10:05:20PM +0300, Mikolaj Golub wrote: In hast_proto_send() we send header and then data. Couldn't it be that remote_send and sync threads interfere and their packets are mixed? May be some synchronization is needed here? I set sleep(1) in hast_proto_send() between proto_send(header) and proto_send(data). The error started to occur frequently. Synchronization requests are sent through the remote thread just like regular I/O requests, exactly because of races that can occur. I looked at the code and the keepalive packets arbe sent from another thread. Could you try turning them off in primary.c and see if that helps? -- Pawel Jakub Dawidek http://www.wheelsystems.com p...@freebsd.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpS7yoGKFxb8.pgp Description: PGP signature
Re: repeating crashes with 8.1
On Fri, 22 Oct 2010, Mike Tancsa wrote: Hi Randy, Mike, At 10:18 AM 10/22/2010, Randy Bush wrote: Do you know how this panic is triggered ? Are you able to create it on demand ? no i do not. bring server up and it'll happen in half an hour. and the server was happy for two months. so i am thinking hardware. Perhaps. The reason I ask is that I had a box go down last night with the same set of errors. The box has a number of ipv6 routes, but its next hop was down and the problems started soon after. So I wonder if it has something to do with that. Do you have ipv6 on this box and are all the next hop addresses correct / reachable ? Oct 22 02:06:02 i4 kernel: em1: discard frame w/o packet header Oct 22 02:06:10 i4 kernel: em2: discard frame w/o packet header Oct 22 02:06:21 i4 kernel: em1: discard frame w/o packet header Just a shot in the dark, as I got another private report just now on this one; is any of you by chance running VLANs on the systems you see this happening? /bz -- Bjoern A. Zeeb Welcome a new stage of life. ks Going to jail sucks -- bz All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: repeating crashes with 8.1
At 01:23 PM 10/28/2010, Bjoern A. Zeeb wrote: On Fri, 22 Oct 2010, Mike Tancsa wrote: Hi Randy, Mike, At 10:18 AM 10/22/2010, Randy Bush wrote: Do you know how this panic is triggered ? Are you able to create it on demand ? no i do not. bring server up and it'll happen in half an hour. and the server was happy for two months. so i am thinking hardware. Perhaps. The reason I ask is that I had a box go down last night with the same set of errors. The box has a number of ipv6 routes, but its next hop was down and the problems started soon after. So I wonder if it has something to do with that. Do you have ipv6 on this box and are all the next hop addresses correct / reachable ? Oct 22 02:06:02 i4 kernel: em1: discard frame w/o packet header Oct 22 02:06:10 i4 kernel: em2: discard frame w/o packet header Oct 22 02:06:21 i4 kernel: em1: discard frame w/o packet header Just a shot in the dark, as I got another private report just now on this one; is any of you by chance running VLANs on the systems you see this happening? Hi Bjoern, On the machine that original crashed for me ? yes there are vlans on it, but the path in question was going across a native interface. But when zoo crashed, there were no vlans defined on the box at all. ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: repeating crashes with 8.1
Just a shot in the dark, as I got another private report just now on this one; is any of you by chance running VLANs on the systems you see this happening? no vlans on the two affected systems here randy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: hast vs ggate+gmirror sychrnoisation speed
On Thu, 28 Oct 2010 18:30:36 +0200 Pawel Jakub Dawidek wrote: PJD On Wed, Oct 27, 2010 at 10:05:20PM +0300, Mikolaj Golub wrote: In hast_proto_send() we send header and then data. Couldn't it be that remote_send and sync threads interfere and their packets are mixed? May be some synchronization is needed here? I set sleep(1) in hast_proto_send() between proto_send(header) and proto_send(data). The error started to occur frequently. PJD Synchronization requests are sent through the remote thread just like PJD regular I/O requests, exactly because of races that can occur. PJD I looked at the code and the keepalive packets arbe sent from another PJD thread. Could you try turning them off in primary.c and see if that PJD helps? At first I set RETRY_SLEEP to 1 sec to have more keepalive packets. The errors started to observe frequently: Oct 28 21:35:53 bolek hastd[1709]: [storage] (secondary) Unable to receive request header: RPC version wrong. Oct 28 21:35:54 bolek hastd[1632]: [storage] (secondary) Worker process exited ungracefully (pid=1709, exitcode=75). Oct 28 21:36:12 bolek hastd[1722]: [storage] (secondary) Unable to receive request header: RPC version wrong. Oct 28 21:36:12 bolek hastd[1632]: [storage] (secondary) Worker process exited ungracefully (pid=1722, exitcode=75). ... Now I have been running synchronization for more then a half an hour with keepalive_send disabled and have not seen any error. -- Mikolaj Golub ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Degraded zpool cannot detach old/bad drive
Hello Artem, everyone, Here's an update on my case. After following Artem's advice I downloaded OpenSolaris 2009 06 LiveCD and booted (over IPMI share) from it. Aliasing the proper disk driver I got access to all JBOD disks that I had before. They had different names (OpenSolaris style) but order and configuration seemed fine. I was in fact able to remove those old/nonexisting devices from OpenSolaris without a problem with the same commands that I was using under FreeBSD. The pool started resilvering which wasn't that important at that stage. So I exported the pool and rebooted back into FreeBSD. FreeBSD saw the pool and I managed to mount it fine. All the data was there and resilvering was initiated. There is a problem though. Initially I used gpt labeled partitions to construct the pool. They had names like /dev/gpt/disk-e1:s15 for example and represented a gpt partition on top of a mfidXX device underneat. Now before I import the pool I do see them in /dev/gpt just fine like that: # ls /dev/gpt disk-e1:s10 disk-e1:s11 disk-e1:s12 disk-e1:s13 disk-e1:s14 disk-e1:s15 disk-e1:s16 disk-e1:s18 disk-e1:s19 disk-e1:s20 disk-e1:s21 disk-e1:s22 disk-e1:s23 disk-e1:s3 disk-e1:s4 disk-e1:s5 disk-e1:s6 disk-e1:s7 disk-e1:s8 disk-e1:s9 disk-e2:s0 disk-e2:s1 disk-e2:s10 disk-e2:s11 disk-e2:s2 disk-e2:s3 disk-e2:s4 disk-e2:s5 disk-e2:s6 disk-e2:s7 disk-e2:s8 disk-e2:s9 newdisk-e1:s17 newdisk-e1:s2 But *after* zpool import tank I get a bunch of messages like those (after enabling kern.geom.label.debug) kernel: GEOM_LABEL[1]: Label gptid/a7fb11e8-dfc9-11df-8732-002590087f3a removed. kernel: GEOM_LABEL[1]: Label gpt/newdisk-e1:s2 removed. kernel: GEOM_LABEL[1]: Label gptid/7a36f6f3-b9fd-11df-8105-002590087f3a removed. kernel: GEOM_LABEL[1]: Label gpt/disk-e1:s3 removed. kernel: GEOM_LABEL[1]: Label gptid/7a92d827-b9fd-11df-8105-002590087f3a removed. kernel: GEOM_LABEL[1]: Label gpt/disk-e1:s4 removed. ... and pretty much all of the gpt labels are gone from /dev/gpt. What I have left there is: disk-e1:s10 disk-e1:s20 disk-e2:s0 So my zpool actually falls back somehow to using the mfidXXp1 partition directly instead of the gpt label. Here's how the pool looks like while imported: # zpool status pool: tank state: ONLINE status: One or more devices is currently being resilvered. The pool will continue to function, possibly in a degraded state. action: Wait for the resilver to complete. scrub: resilver in progress for 0h3m, 0.38% done, 16h35m to go config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz1 ONLINE 0 0 0 mfid33p1 ONLINE 0 0 0 4.18G resilvered mfid1p1 ONLINE 0 0 0 28.8M resilvered mfid2p1 ONLINE 0 0 0 28.0M resilvered mfid3p1 ONLINE 0 0 0 18.4M resilvered raidz1 ONLINE 0 0 0 mfid4p1 ONLINE 0 0 0 mfid5p1 ONLINE 0 0 0 mfid6p1 ONLINE 0 0 0 mfid7p1 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 gpt/disk-e1:s10 ONLINE 0 0 0 mfid9p1 ONLINE 0 0 0 mfid10p1 ONLINE 0 0 0 mfid11p1 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 mfid12p1 ONLINE 0 0 0 27.8M resilvered mfid13p1 ONLINE 0 0 0 27.8M resilvered mfid14p1 ONLINE 0 0 0 27.0M resilvered mfid34p1 ONLINE 0 0 0 4.14G resilvered raidz1 ONLINE 0 0 0 mfid15p1 ONLINE 0 0 0 mfid16p1 ONLINE 0 0 0 gpt/disk-e1:s20 ONLINE 0 0 0 mfid18p1 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 mfid19p1 ONLINE 0 0 0 mfid20p1 ONLINE 0 0 0 gpt/disk-e2:s0 ONLINE 0 0 0 mfid22p1 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 mfid23p1 ONLINE 0 0 0 mfid24p1 ONLINE 0 0 0 mfid25p1 ONLINE 0 0 0 mfid26p1 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 mfid27p1 ONLINE 0 0 0 mfid28p1 ONLINE 0 0 0 mfid29p1 ONLINE 0 0 0 mfid30p1 ONLINE 0
Re: ZFS write speed
On 10/28/2010 03:30, S.N.Grigoriev wrote: 28.10.10, 01:54, Stefan Bethke s...@lassitu.de: Am 27.10.2010 um 22:51 schrieb S.N.Grigoriev: Hi list, I've got very low write speed using ZFS on a SATA disk. My HDD configuration is: ad4: 70911MB at ata2-master UDMA100 SATA 3Gb/s ad6: 78532MB at ata3-master UDMA100 SATA 1.5Gb/s ad8: 1430799MB at ata4-master UDMA100 SATA 3Gb/s The EARS has 4k sectors, if I'm not mistaken. I don't recall the eventual outcome, but there was a long thread on stable or hackers on how to ensure proper alignment and (minimun) 4k-sized writes to make sure the disk doesn't have to do a read-modify-write cycle, so try and search the archives. Though this might play a small part in your write performance with the EARS drives, this issue has more to do with the stat() calls and the ACL involvement with ZFS. This was sort of solved in 8.1-STABLE and from 3 cases that I know about and 1 being my own... write/read speeds have doubled from what can be seen to an effect of 8.1-RELEASE. You may want to either upgrade to stable/8 or use one of the snapshots from here: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/201010/ Stefan, thank you for your response. I'll try to find the topic you pointed. ad4 and ad6 are single-slice disks (UFS2 with soft updates) ZFS configuration is following: zpool create Z ad8 zfs create Z/music zfs create Z/video All ZFS parameters are default. kern.maxvnodes = 100 To test my configuration I recursively copied from ad6 to ad8 two directories. The first one contains MP3 files (average size = 10MB). The second one contains AVI files (average size = 1GB). To compare performance I repeated above tests with ad8 using UFS2 with soft updates. 18GB of MP3 files required 10m35s to copy to UFS2 and 21m40s to copy to ZFS. 30GB of AVI files required 16m6s to copy to UFS2 and 1h2m39s to copy to ZFS. I used for tests FreeBSD 8.1R amd64. Amount of RAM on my machine is 6GB. Any tips? -- -- jhell,v ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Degraded zpool cannot detach old/bad drive
but only those 3 devices in /dev/gpt and absolutely nothing in /dev/gptid/ So is there a way to bring all the gpt labeled partitions back into the pool instead of using the mfidXX devices? Try re-importing the pool with zpool import -d /dev/gpt. This will tell ZFS to use only devices found within that path and your pool should be using gpt labels again. --Artem ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Degraded zpool cannot detach old/bad drive
Hi Artem, everyone, Thanks for your quick response. Unfortunately I already did try this approach. Applying -d /dev/gpt only limits the pool to the bare three remaining disks which turns pool completely unusable (no mfid devices). Maybe those labels are removed shortly they are being tried to be imported/accessed? What I don't understand is what exactly makes those gpt labels disappear when the pool is imported and otherwise are just fine?! Something to do with OpenSolaris ? On top of it all gpart show -l keeps showing all the labels right even while the pool is imported. Any other clues would be appreciated. Thank you, Rumen Telbizov On Thu, Oct 28, 2010 at 9:46 PM, Artem Belevich fbsdl...@src.cx wrote: but only those 3 devices in /dev/gpt and absolutely nothing in /dev/gptid/ So is there a way to bring all the gpt labeled partitions back into the pool instead of using the mfidXX devices? Try re-importing the pool with zpool import -d /dev/gpt. This will tell ZFS to use only devices found within that path and your pool should be using gpt labels again. --Artem -- Rumen Telbizov http://telbizov.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
