Re: [zfs-discuss] about variable block size
Files are stored as either a single record (ajusted to the size of the file) multiple number of fixed size records. -r Le 25 août 08 à 09:21, Robert a écrit : > Thanks for your response, from which I have known more details. > However, there is one thing I am still not clear--maybe at first the > size of a file is smaller than 128KB(or user-defined value), zfs can > adopt some block size as you described, but when the size becomes > more than 128KB by reason of appending, then should it adopt the > "bigger" strategy? If so, what would happen to the blocks? I guess > that the size of those blocks which are allocated when the size of > the file is smaller than 128KB remains unchanged, while those new > blocks allocated when the file size has exceeded 128KB would adopt > new strategy. > Is that right? > Thanks! > > > This message posted from opensolaris.org > ___ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] zpool CKSUM errors since drive replace
After performing the following steps in exact order, I am now seeing CKSUM errors in my zpool. I've never seen any Checksum errors before in the zpool. 1. Performing running setup (RAIDZ 7D+1P) - 8x 1TB. Solaris 10 Update 3 x86. 2. Disk 6 (c6t2d0) was dying, $(zpool status) read errors, and device errors in /var/adm/messages. 3. Additional to replacing this disk, I thought I would give myself a challenge and upgrade to Solaris 10 and change my CPU/Motherboard. > 3.1 CPU went to AthlonXP 3500+ from an Athlon FX-51 > 3.2 Motherboard went to Asus A8N-SLI Premium from Asus SK8N. > 3.3 Memory stayed the same at 2GB ECC DRR (all other components identical). > 3.4 And finally, I replaced the failed Disk 6. 4. Solaris 10 U5 x86 Install was fine without a problem. zpool imported fine (obviously DEGRADED). 5. zpool replace worked without a problem and it resilvered with 0 read, write or cksum errors. 6. After zpool replace, zfs recommended I run zfs upgrade to upgrade from zfs3 to zfs4, which I have done. This is where the problem starts to appear. The Upgrade was fine, however immediately after the upgrade I ran a scrub and I noticed a very high number of cksum errors on the newly replaced disk 6 (now c4t2d0, previously before reinstall c6t2d0). Here is the progress of the scrub and you can see how the cksum is quickly, and constantly increasing: [/root][root]# date Fri Oct 10 00:19:16 EST 2008 [root][root]# zpool status -v pool: rzdata state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-9P scrub: scrub in progress, 7.34% done, 6h10m to go config: NAMESTATE READ WRITE CKSUM rzdata ONLINE 0 0 0 raidz1ONLINE 0 0 0 c3t0d0 ONLINE 0 0 0 c3t1d0 ONLINE 0 0 0 c3t2d0 ONLINE 0 0 0 c3t3d0 ONLINE 0 0 0 c4t0d0 ONLINE 0 0 0 c4t1d0 ONLINE 0 0 0 c4t2d0 ONLINE 0 0 390 c4t3d0 ONLINE 0 0 0 errors: No known data errors [/root][root]# date Fri Oct 10 00:23:12 EST 2008 [root][root]# zpool status -v pool: rzdata state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-9P scrub: scrub in progress, 8.01% done, 6h6m to go config: NAMESTATE READ WRITE CKSUM rzdata ONLINE 0 0 0 raidz1ONLINE 0 0 0 c3t0d0 ONLINE 0 0 0 c3t1d0 ONLINE 0 0 0 c3t2d0 ONLINE 0 0 1 c3t3d0 ONLINE 0 0 0 c4t0d0 ONLINE 0 0 0 c4t1d0 ONLINE 0 0 2 c4t2d0 ONLINE 0 0 768 c4t3d0 ONLINE 0 0 0 [/root][root]# date Fri Oct 10 00:29:44 EST 2008 [/root][root]# zpool status -v pool: rzdata state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-9P scrub: scrub in progress, 9.88% done, 5h57m to go config: NAMESTATE READ WRITE CKSUM rzdata ONLINE 0 0 0 raidz1ONLINE 0 0 0 c3t0d0 ONLINE 0 0 0 c3t1d0 ONLINE 0 0 0 c3t2d0 ONLINE 0 0 2 c3t3d0 ONLINE 0 0 0 c4t0d0 ONLINE 0 0 0 c4t1d0 ONLINE 0 0 2 c4t2d0 ONLINE 0 0 931 c4t3d0 ONLINE 0 0 1 It eventually finished with 6.4K CKSUM errors against c4t2d0 and an average of sub 5 errors on the remaining disks. I was not (and still not) convinced it's a physical hardware problem and my initial thoughts was that there is/was(?) a bug with zfs and zpool upgrade a mounted and running zpool. So to be pedantic, I rebooted the server, and initiated another scrub. This is the outcome of this scrub: [/root][root]# zpool status -v pool: rzdata state: ONLINE status: One or more devices has experienced an unrecove
Re: [zfs-discuss] am I "screwed"?
Lori Alt wrote: > dick hoogendijk wrote: >> Lori Alt wrote: > Since I don't fully understand the problem, I can't > be sure this will work, but I'm pretty sure it won't > hurt: try setting the mountpoint of the dataset to "/": > > zfs set mountpoint=/ rpool/ROOT/snv99 > > Then reboot and see if your problem is solved. If not, > we'll dig deeper with kmdb into what's happening. The reboot is still the same. The machine still hangs. After that I did a failsafe reboot to see if ROOT/snv99 was mountend now. This is the message: ROOT/snv99 was found on rpool. Do you wish to have it mounted read-write on /a? [y,n,?] y mounting rpool on /a [...] That was ten minutes ago. Nothing happens after this message. There seems to be some kind of resemblance with 'normal' booting. ROOT/snv99 seems OK (zpool scrub; status; etc do say so). Still nothing happens with this BE. We have to dig deeper with kmdb. But before we do that, tell me please what is an easy way to transfer the messages from the failsafe login on the problematic machine to i.e. this S10u5 server. All former screen output had to be typed in by hand. I didn't know of another way. -- Dick Hoogendijk -- PGP/GnuPG key: F86289CE ++ http://nagual.nl/ | SunOS 10u5 05/08 ++ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] scrub restart patch status..
Correct, that is a workaround. The fact that I use the beta (alpha?) zfs auto-snaphot service means that when the service checks for active scrubs, it kills the resilver. I think I will talk to Tim about modifying his method script to run the scrub check with least privileges (ie, not as root). On 10/13/08, Richard Elling <[EMAIL PROTECTED]> wrote: > Blake Irvin wrote: >> I'm also very interested in this. I'm having a lot of pain with status >> requests killing my resilvers. In the example below I was trying to test >> to see if timf's auto-snapshot service was killing my resilver, only to >> find that calling zpool status seems to be the issue: >> > > workaround: don't run zpool status as root. > -- richard > >> [EMAIL PROTECTED] ~]# env LC_ALL=C zpool status $POOL | grep " in progress" >> scrub: resilver in progress, 0.26% done, 35h4m to go >> >> [EMAIL PROTECTED] ~]# env LC_ALL=C zpool status $POOL >> pool: pit >> state: DEGRADED >> status: One or more devices could not be opened. Sufficient replicas >> exist for >> the pool to continue functioning in a degraded state. >> action: Attach the missing device and online it using 'zpool online'. >>see: http://www.sun.com/msg/ZFS-8000-D3 >> scrub: resilver in progress, 0.00% done, 484h39m to go >> config: >> >> NAME STATE READ WRITE CKSUM >> pit DEGRADED 0 0 0 >>raidz2 DEGRADED 0 0 0 >> c2t0d0ONLINE 0 0 0 >> c3t0d0ONLINE 0 0 0 >> c3t1d0ONLINE 0 0 0 >> c2t1d0ONLINE 0 0 0 >> spare DEGRADED 0 0 0 >>c3t3d0 UNAVAIL 0 0 0 cannot open >>c3t7d0 ONLINE 0 0 0 >> c2t2d0ONLINE 0 0 0 >> c3t5d0ONLINE 0 0 0 >> c3t6d0ONLINE 0 0 0 >> spares >>c3t7d0 INUSE currently in use >> >> errors: No known data errors >> -- >> This message posted from opensolaris.org >> ___ >> zfs-discuss mailing list >> zfs-discuss@opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >> > > ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Segmentation fault / core dump with recursive
Ok so I left the thumb drive to try to backup all weekend. It got *most* of the first snapshot copied over, about 50MB, and that's it. So I tried an external USB hard drive today, and it actually bothered to copy over the snapshots, but it does so very slowly. It copied over the first snapshot (the "full stream") at about 25MB/s (uncompressed). Seems silly that it won't retain compression during copy, which would speed up my transfer, but oh well. However, once it gets to the incrementals, it slows down to about 1MB-5MB/s. Then, once it got to the last incremental snapshot, copied it over and then hung. (By the way, when I say incrementals, I don't mean I'm doing a zfs send -i, just a zfs send -R to a clean drive.) Now if I try to do a zfs list on my backup pool, it hangs and never comes back. My zfs send -R command has now also hung. iostat and the little green light on the external drive both show no further activity on the external drive. This is crazy. I feel like I'm beta testing a brand new feature or something. Nothing works. Does anybody actually use this? -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Improving zfs send performance
Hi Thomas, Thomas Maier-Komor wrote: > > Carsten, > > the summary looks like you are using mbuffer. Can you elaborate on what > options you are passing to mbuffer? Maybe changing the blocksize to be > consistent with the recordsize of the zpool could improve performance. > Is the buffer running full or is it empty most of the time? Are you sure > that the network connection is 10Gb/s all the way through from machine > to machine? Well spotted :) right now plain mbuffer with plenty of buffer (-m 2048M) on both ends and I have not seen any buffer exceeding the 10% watermark level. The network connection are via Neterion XFrame II Sun Fire NICs then via CX4 cables to our core switch where both boxes are directly connected (WovenSystmes EFX1000). netperf tells me that the TCP performance is close to 7.5 GBit/s duplex and if I use cat /dev/zero | mbuffer | socat ---> socat | mbuffer > /dev/null I easily see speeds of about 350-400 MB/s so I think the network is fine. Cheers Carsten ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] am I "screwed"?
dick hoogendijk wrote: Lori Alt wrote: It would also be useful to see the output of `zfs list` and `zfs get all rpool/ROOT/snv_99` while booted from the failsafe archive # zfs list rpool 69.0G 76.6G40K /a/rpool rpool/ROOT22.7G 18K legacy rpool/ROOT/snv99 22.7G 10.8G /a/.alt.tmp.b-yh.mnt/ Well, this is clearly a problem. I've seen it before (there are some bugs in LU that can leave the root dataset of a BE in this state), but I've always seen the system boot anyway because the zfs_mountroot code in the kernel appeared to ignore the value of the moutnpoint property and just mounted the dataset at "/" anyway. Since I don't fully understand the problem, I can't be sure this will work, but I'm pretty sure it won't hurt: try setting the mountpoint of the dataset to "/": zfs set mountpoint=/ rpool/ROOT/snv99 I do mean "/", not "/a". After executing the command, the mountpoint shown with `zfs list` should be "/a" (in the zfs list output, the current alternate root for the pool is prepended to the persistent mount point of the datasets to show the effective mount point). Then reboot and see if your problem is solved. If not, we'll dig deeper with kmdb into what's happening. Lori rpool/dump1.50G 1.50G - rpool/export 36.6G 796M /a/export rpool/export/home 36.8G 35.8G /a/export/home rpool/local234M 234M /a/usr/local rpool/swap 8G 84.6G 6.74G - # zfs get all rpool/ROOT/snv99 type filesystem creation wed ... used 22.7G available 76.6G referenced 10.8G compressratio 1.00x mounted no quota none reservation none recordsize 128K mountpoint /a/.alt.tmp.b-yh.mnt/ sharefs off checksum on compression off atime on devices on exec on setuid on readonly off zoned off snapdir hidden aclmode groupmask aclinherit restricted canmount noauto shareiscsi off xattr on copies 1 version 3 utf8only off normalization none casesensitive sensitive vscan off nbmand off sharesmb off refquota none refreservation none primarycache all secondarycache all usedbysnapshots 11.9G usedbydataset 10.8G usedbychildren 0 usedbyrefreservation 0 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Improving zfs send performance
Hi Darren J Moffat wrote: > > What are you using to transfer the data over the network ? > Initially just plain ssh which was way to slow, now we use mbuffer on both ends and socket transfer the data over via socat - I know that mbuffer already allows this, but in a few tests socat seemed to be faster. Sorry for not writing this into the first email. Cheers Carsten ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] restore from snapshot
> "r" == Ross <[EMAIL PROTECTED]> writes: r> roll back to a previous configuration, while keeping r> the ability to roll forward again if you wanted. I believe that's called a ``clone''. It doesn't make sense to roll back, write, roll forward, unless you will accept that you are branching the snapshot tree (=making a clone). pgpzocR0amcyY.pgp Description: PGP signature ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] scrub restart patch status..
Blake Irvin wrote: > I'm also very interested in this. I'm having a lot of pain with status > requests killing my resilvers. In the example below I was trying to test to > see if timf's auto-snapshot service was killing my resilver, only to find > that calling zpool status seems to be the issue: > workaround: don't run zpool status as root. -- richard > [EMAIL PROTECTED] ~]# env LC_ALL=C zpool status $POOL | grep " in progress" > scrub: resilver in progress, 0.26% done, 35h4m to go > > [EMAIL PROTECTED] ~]# env LC_ALL=C zpool status $POOL > pool: pit > state: DEGRADED > status: One or more devices could not be opened. Sufficient replicas exist > for > the pool to continue functioning in a degraded state. > action: Attach the missing device and online it using 'zpool online'. >see: http://www.sun.com/msg/ZFS-8000-D3 > scrub: resilver in progress, 0.00% done, 484h39m to go > config: > > NAME STATE READ WRITE CKSUM > pit DEGRADED 0 0 0 > raidz2 DEGRADED 0 0 0 > c2t0d0ONLINE 0 0 0 > c3t0d0ONLINE 0 0 0 > c3t1d0ONLINE 0 0 0 > c2t1d0ONLINE 0 0 0 > spare DEGRADED 0 0 0 > c3t3d0 UNAVAIL 0 0 0 cannot open > c3t7d0 ONLINE 0 0 0 > c2t2d0ONLINE 0 0 0 > c3t5d0ONLINE 0 0 0 > c3t6d0ONLINE 0 0 0 > spares > c3t7d0 INUSE currently in use > > errors: No known data errors > -- > This message posted from opensolaris.org > ___ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] am I "screwed"?
Lori Alt wrote: > > It would also be useful to see the output of `zfs list` > and `zfs get all rpool/ROOT/snv_99` while > booted from the failsafe archive. # zfs list rpool 69.0G 76.6G40K /a/rpool rpool/ROOT22.7G 18K legacy rpool/ROOT/snv99 22.7G 10.8G /a/.alt.tmp.b-yh.mnt/ rpool/dump1.50G 1.50G - rpool/export 36.6G 796M /a/export rpool/export/home 36.8G 35.8G /a/export/home rpool/local234M 234M /a/usr/local rpool/swap 8G 84.6G 6.74G - # zfs get all rpool/ROOT/snv99 type filesystem creation wed ... used 22.7G available 76.6G referenced 10.8G compressratio 1.00x mounted no quota none reservation none recordsize 128K mountpoint /a/.alt.tmp.b-yh.mnt/ sharefs off checksum on compression off atime on devices on exec on setuid on readonly off zoned off snapdir hidden aclmode groupmask aclinherit restricted canmount noauto shareiscsi off xattr on copies 1 version 3 utf8only off normalization none casesensitive sensitive vscan off nbmand off sharesmb off refquota none refreservation none primarycache all secondarycache all usedbysnapshots 11.9G usedbydataset 10.8G usedbychildren 0 usedbyrefreservation 0 -- Dick Hoogendijk -- PGP/GnuPG key: F86289CE ++ http://nagual.nl/ | SunOS 10u5 05/08 ++ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Solved - a big THANKS to Victor Latushkin @ Sun / Moscow
On Thu, Oct 9, 2008 at 10:33 PM, Mike Gerdts <[EMAIL PROTECTED]> wrote: > On Thu, Oct 9, 2008 at 10:18 AM, Mike Gerdts <[EMAIL PROTECTED]> wrote: >> On Thu, Oct 9, 2008 at 10:10 AM, Greg Shaw <[EMAIL PROTECTED]> wrote: >>> Nevada isn't production code. For real ZFS testing, you must use a >>> production release, currently Solaris 10 (update 5, soon to be update 6). >> >> I misstated before in my LDoms case. The corrupted pool was on >> Solaris 10, with LDoms 1.0. The control domain was SX*E, but the >> zpool there showed no problems. I got into a panic loop with dangling >> dbufs. My understanding is that this was caused by a bug in the LDoms >> manager 1.0 code that has been fixed in a later release. It was a >> supported configuration, I pushed for and got a fix. However, that >> pool was still lost. > > Or maybe it wasn't fixed yet. I see that this was committed just today. > > 6684721 file backed virtual i/o should be synchronous > > http://hg.genunix.org/onnv-gate.hg/rev/eb40ff0c92ec The related information from the LDoms Manager 1.1 Early Access release notes (820-4914-10): Data Might Not Be Written Immediately to the Virtual Disk Backend If Virtual I/O Is Backed by a File or Volume Bug ID 6684721: When a file or volume is exported as a virtual disk, then the service domain exporting that file or volume is acting as a storage cache for the virtual disk. In that case, data written to the virtual disk might get cached into the service domain memory instead of being immediately written to the virtual disk backend. Data are not cached if the virtual disk backend is a physical disk or slice, or if it is a volume device exported as a single-slice disk. Workaround: If the virtual disk backend is a file or a volume device exported as a full disk, then you can prevent data from being cached into the service domain memory and have data written immediately to the virtual disk backend by adding the following line to the /etc/system file on the service domain. set vds:vd_file_write_flags = 0 Note – Setting this tunable flag does have an impact on performance when writing to a virtual disk, but it does ensure that data are written immediately to the virtual disk backend. -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] scrub restart patch status..
I'm also very interested in this. I'm having a lot of pain with status requests killing my resilvers. In the example below I was trying to test to see if timf's auto-snapshot service was killing my resilver, only to find that calling zpool status seems to be the issue: [EMAIL PROTECTED] ~]# env LC_ALL=C zpool status $POOL | grep " in progress" scrub: resilver in progress, 0.26% done, 35h4m to go [EMAIL PROTECTED] ~]# env LC_ALL=C zpool status $POOL pool: pit state: DEGRADED status: One or more devices could not be opened. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Attach the missing device and online it using 'zpool online'. see: http://www.sun.com/msg/ZFS-8000-D3 scrub: resilver in progress, 0.00% done, 484h39m to go config: NAME STATE READ WRITE CKSUM pit DEGRADED 0 0 0 raidz2 DEGRADED 0 0 0 c2t0d0ONLINE 0 0 0 c3t0d0ONLINE 0 0 0 c3t1d0ONLINE 0 0 0 c2t1d0ONLINE 0 0 0 spare DEGRADED 0 0 0 c3t3d0 UNAVAIL 0 0 0 cannot open c3t7d0 ONLINE 0 0 0 c2t2d0ONLINE 0 0 0 c3t5d0ONLINE 0 0 0 c3t6d0ONLINE 0 0 0 spares c3t7d0 INUSE currently in use errors: No known data errors -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] am I "screwed"?
It would also be useful to see the output of `zfs list` and `zfs get all rpool/ROOT/snv_99` while booted from the failsafe archive. - lori dick hoogendijk wrote: James C. McPherson wrote: Please add -kv to the end of your kernel$ line in grub, #GRUB kernel$ add -kv cmdk0 at ata0 target 0 lun 0 cmdk0 is /[EMAIL PROTECTED],0/[EMAIL PROTECTED]/[EMAIL PROTECTED]/cmdk0,0 ### end the machine hangst here have you tried mount -F zfs rpool/ROOT/snv_99 /a # mount -F zfs rpool/ROOT/snv99 /a (*) filesystem 'rpool/ROOT/snv99' cannot be mounted using 'mount -F zfs' Use 'zfs set mountpoint=/a' instead If you must use 'mount -F zfs' or /etc/vfstab, use 'zfs set mountpoint=legacy'. See zfs(1M) for more information. zpool status -v rpool # zpool status -v rpool pool: rpool state: ONLINE scrub: none requested config: NAMESTATE READWRITE CKSUM rpool ONLINE 0 0 0 c0d0s0ONLINE 0 0 0 zpool get all rpool # zpool get all rpool NAMEPROPERTYVALUE SOURCE rpool size148G- used61.1G available 89.9G capacity41% altroot /a local health ONLINE guid936248... version 13 bootfs rpool/ROOT/snv99local delegation on default autoreplace off default cachefile nonelocal failmodecontinuelocal listsnapshots off default (*) If I chose not to mount the boot env rpool/ROOT/snv99 rw on /a I cannot do a thing in my failsafe login. The dataset does no exist then. I have to say 'y' to the question; get some error msgs that it fails but then at least I can see the pool. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] External storage recovery?
C. Bergström пишет: > I had to hard power reset the laptop... Now I can't import my pool.. > > zpool status -x > bucket UNAVAIL 0 0 0 insufficient replicas > c6t0d0UNAVAIL 0 0 0 cannot open > > > cfgadm > > usb8/4 usb-storage connectedconfigured ok > > --- > I see a ton of these in dmesg > > Oct 13 17:22:08 fuzzy scsi: [ID 107833 kern.warning] WARNING: > /[EMAIL PROTECTED],0/pci1028,[EMAIL PROTECTED],7/[EMAIL PROTECTED]/[EMAIL > PROTECTED],0 (sd2): > Oct 13 17:22:08 fuzzy drive offline > --- Looks like device has gone bad. Are you able to read anything off it (e.g. with dd)? What does 'zdb -l /dev/dsk/c6t0d0s0' show? Victor ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] scrub restart patch status..
Any news on if the scrub/resilver/snap reset patch will make it into 10/08 update? Thanks! Wade Stuart we are fallon P: 612.758.2660 C: 612.877.0385 ** Fallon has moved. Effective May 19, 2008 our address is 901 Marquette Ave, Suite 2400, Minneapolis, MN 55402. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Improving zfs send performance
Carsten Aulbert schrieb: > Hi all, > > although I'm running all this in a Sol10u5 X4500, I hope I may ask this > question here. If not, please let me know where to head to. > > We are running several X4500 with only 3 raidz2 zpools since we want > quite a bit of storage space[*], but the performance we get when using > zfs send is sometimes really lousy. Of course this depends what's in the > file system, but when doing a few backups today I have seen the following: > > receiving full stream of atlashome/[EMAIL PROTECTED] into > atlashome/BACKUP/[EMAIL PROTECTED] > in @ 11.1 MB/s, out @ 11.1 MB/s, 14.9 GB total, buffer 0% full > summary: 14.9 GByte in 45 min 42.8 sec - average of 5708 kB/s > > So, a mere 15 GB were transferred in 45 minutes, another user's home > which is quite large (7TB) took more than 42 hours to be transferred. > Since all this is going a 10 Gb/s network and the CPUs are all idle I > would really like to know why > > * zfs send is so slow and > * how can I improve the speed? > > Thanks a lot for any hint > > Cheers > > Carsten > > [*] we have some quite a few tests with more zpools but were not able to > improve the speeds substantially. For this particular bad file system I > still need to histogram the file sizes. > Carsten, the summary looks like you are using mbuffer. Can you elaborate on what options you are passing to mbuffer? Maybe changing the blocksize to be consistent with the recordsize of the zpool could improve performance. Is the buffer running full or is it empty most of the time? Are you sure that the network connection is 10Gb/s all the way through from machine to machine? - Thomas ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Solved - a big THANKS to Victor Latushkin @ Sun / Moscow
[EMAIL PROTECTED] wrote on 10/11/2008 09:36:02 PM: > > On Oct 10, 2008, at 7:55 PM 10/10/, David Magda wrote: > > > > > If someone finds themselves in this position, what advice can be > > followed to minimize risks? > > Can you ask for two LUNs on different physical SAN devices and have > an expectation of getting it? Better yet also ask for multiple paths over different SAN infrastructure to each. Then again, I would hope you don't need to ask your SAN folks for that? -Wade ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zpool import of bootable root pool renders it unbootable
> Again, what I'm trying to do is to boot the same OS from physical > drive - once natively on my notebook, the other time from withing > Virtualbox. There are two problems, at least. First is the bootpath as > in VB it emulates the disk as IDE while booting natively it is sata. When I started experimenting with installing SXCE to an USB flash memory stick, which should be bootable on different machines, I initially worked around this problem by creating multiple /boot/grub/menu.lst boot entries, one for each supported bootable machine. The difference between the grub boot entries was the "-B bootpath=/physical/device/path" option. Fortunately, this has become much easier in recent builds, because zfs boot is now able to open the pool by using a disk unique "devid" in addition to using physical device paths. Whatever the physical device path will be on a random selected x86 machine where I try to boot my usb flash memory stick, the sd driver will always generate the same unique "devid" for the flash memory stick, and zfs boot is able to find and open the correct usb storage device in the system that has the desired "devid" for the pool. In case sata on the notebook will create the same "devid" for the disk as virtualbox with p-ata, the zpool should be bootable just fine on the two different boxes. But apparently the "devid" created for the disk with sata on the notebook is different from the "devid" created for the disk when running under virtualbox... (that is, pool open by physical device path and by devid fails) I guess what we need is the fix for this bug, which allows to open the pool by the boot disk's unique "guid": Bug ID 6513775 Synopsiszfs root disk portability http://bugs.opensolaris.org/view_bug.do?bug_id=6513775 > The other one seems to be hostid stored in a pool. This shouldn't be a problem for x86, because the hostid is stored in a file (sysinit kernel module) in the root filesystem, on x86. Wherever you boot that disk, the hostid will move with it. Well, unless you boot some other installed Solaris / OpenSolaris system (has a unique hostid / sysinit file) and import that zfs root pool. In this case the hostid stored in the zpool label will change. This should change in build 100, with the putback for this bug: Bug ID 6716241 SynopsisChanging hostid, by moving in a new sysinit file, panics a zfs root file system http://bugs.opensolaris.org/view_bug.do?bug_id=6716241 AFAIR, a hostid mismatch will be ignored when mounting a zfs root file system. -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] External storage recovery?
I had to hard power reset the laptop... Now I can't import my pool.. zpool status -x bucket UNAVAIL 0 0 0 insufficient replicas c6t0d0UNAVAIL 0 0 0 cannot open cfgadm usb8/4 usb-storage connectedconfigured ok --- I see a ton of these in dmesg Oct 13 17:22:08 fuzzy scsi: [ID 107833 kern.warning] WARNING: /[EMAIL PROTECTED],0/pci1028,[EMAIL PROTECTED],7/[EMAIL PROTECTED]/[EMAIL PROTECTED],0 (sd2): Oct 13 17:22:08 fuzzy drive offline --- What's the best way to proceed? (I don't have time to kmdb the issue right now, but hopefully that won't be necessary) Thanks ./Christopher ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Improving zfs send performance
Carsten Aulbert wrote: > Hi all, > > although I'm running all this in a Sol10u5 X4500, I hope I may ask this > question here. If not, please let me know where to head to. > > We are running several X4500 with only 3 raidz2 zpools since we want > quite a bit of storage space[*], but the performance we get when using > zfs send is sometimes really lousy. Of course this depends what's in the > file system, but when doing a few backups today I have seen the following: > > receiving full stream of atlashome/[EMAIL PROTECTED] into > atlashome/BACKUP/[EMAIL PROTECTED] > in @ 11.1 MB/s, out @ 11.1 MB/s, 14.9 GB total, buffer 0% full > summary: 14.9 GByte in 45 min 42.8 sec - average of 5708 kB/s > > So, a mere 15 GB were transferred in 45 minutes, another user's home > which is quite large (7TB) took more than 42 hours to be transferred. > Since all this is going a 10 Gb/s network and the CPUs are all idle I > would really like to know why What are you using to transfer the data over the network ? -- Darren J Moffat ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Improving zfs send performance
Hi all, although I'm running all this in a Sol10u5 X4500, I hope I may ask this question here. If not, please let me know where to head to. We are running several X4500 with only 3 raidz2 zpools since we want quite a bit of storage space[*], but the performance we get when using zfs send is sometimes really lousy. Of course this depends what's in the file system, but when doing a few backups today I have seen the following: receiving full stream of atlashome/[EMAIL PROTECTED] into atlashome/BACKUP/[EMAIL PROTECTED] in @ 11.1 MB/s, out @ 11.1 MB/s, 14.9 GB total, buffer 0% full summary: 14.9 GByte in 45 min 42.8 sec - average of 5708 kB/s So, a mere 15 GB were transferred in 45 minutes, another user's home which is quite large (7TB) took more than 42 hours to be transferred. Since all this is going a 10 Gb/s network and the CPUs are all idle I would really like to know why * zfs send is so slow and * how can I improve the speed? Thanks a lot for any hint Cheers Carsten [*] we have some quite a few tests with more zpools but were not able to improve the speeds substantially. For this particular bad file system I still need to histogram the file sizes. -- Dr. Carsten Aulbert - Max Planck Institute for Gravitational Physics Callinstrasse 38, 30167 Hannover, Germany Phone/Fax: +49 511 762-17185 / -17193 http://www.top500.org/system/9234 | http://www.top500.org/connfam/6/list/31 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] am I "screwed"?
James C. McPherson wrote: > Please add -kv to the end of your kernel$ line in > grub, #GRUB kernel$ add -kv cmdk0 at ata0 target 0 lun 0 cmdk0 is /[EMAIL PROTECTED],0/[EMAIL PROTECTED]/[EMAIL PROTECTED]/cmdk0,0 ### end the machine hangst here > have you tried > mount -F zfs rpool/ROOT/snv_99 /a # mount -F zfs rpool/ROOT/snv99 /a (*) filesystem 'rpool/ROOT/snv99' cannot be mounted using 'mount -F zfs' Use 'zfs set mountpoint=/a' instead If you must use 'mount -F zfs' or /etc/vfstab, use 'zfs set mountpoint=legacy'. See zfs(1M) for more information. > zpool status -v rpool # zpool status -v rpool pool: rpool state: ONLINE scrub: none requested config: NAMESTATE READWRITE CKSUM rpool ONLINE 0 0 0 c0d0s0ONLINE 0 0 0 > zpool get all rpool # zpool get all rpool NAMEPROPERTYVALUE SOURCE rpool size148G- used61.1G available 89.9G capacity41% altroot /a local health ONLINE guid936248... version 13 bootfs rpool/ROOT/snv99local delegation on default autoreplace off default cachefile nonelocal failmodecontinuelocal listsnapshots off default (*) If I chose not to mount the boot env rpool/ROOT/snv99 rw on /a I cannot do a thing in my failsafe login. The dataset does no exist then. I have to say 'y' to the question; get some error msgs that it fails but then at least I can see the pool. -- Dick Hoogendijk -- PGP/GnuPG key: F86289CE ++ http://nagual.nl/ | SunOS 10u5 05/08 ++ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zpool import of bootable root pool renders it unbootable
Hello Jürgen, Monday, October 6, 2008, 6:27:54 PM, you wrote: >> Cannot mount root on /[EMAIL PROTECTED],0/pci103c,[EMAIL PROTECTED],2/[EMAIL >> PROTECTED],0:a fstype zfs JK> Is that physical device path correct for your new system? JK> Or is this the physical device path (stored on-disk in the zpool label) JK> from some other system? In this case you may be able to work around JK> the problem by passing a "-B bootpath=..." option to the kernel JK> e.g. something like this: JK> kernel$ /platform/i86pc/kernel/$ISADIR/unix -B JK> $ZFS-BOOTFS,bootpath="/[EMAIL PROTECTED],0/[EMAIL PROTECTED],1/[EMAIL PROTECTED]/[EMAIL PROTECTED],0:a" JK> You can find out the correct physical device path string JK> for the zfs root disk by booting the system from the optical JK> installation media, and running the format utility. JK> OTOH, if you already have booted from the optical installation JK> media, it's easiest to just import the root zpool from the JK> installation system, because that'll update the physical device JK> path in the zpool's label on disk (and it clears the hostid stored in JK> the zpool label - another problem that could prevent mounting JK> the zfs root). Again, what I'm trying to do is to boot the same OS from physical drive - once natively on my notebook, the other time from withing Virtualbox. There are two problems, at least. First is the bootpath as in VB it emulates the disk as IDE while booting natively it is sata. The other one seems to be hostid stored in a pool. Yes, importing the pool when booted from cdrom is a working workaround... but it's not practical. The other thing is - if one boots from another media with root-fs on zfs and tries to import other root-fs on zfs, there will be the problem with both pools having the same name. I could import the pool under different name but one can't export the pool while reverting it back to original name. So far I workaround it by booting from media where root-fs is not on zfs - probably an ability to import same pool name or export with name change at the same time would be useful for some cases. -- Best regards, Robert Milkowskimailto:[EMAIL PROTECTED] http://milek.blogspot.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] am I "screwed"?
James C. McPherson wrote: > Lots of things. We can't channel A nice way for a smiley.. Thanks for the mail so far. I'm in Holland and at work right now (13.45h) but I'll check out your suggestions as soon as I get home. -- Dick Hoogendijk -- PGP/GnuPG key: F86289CE ++ http://nagual.nl/ | SunOS 10u5 05/08 ++ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
