[zfs-discuss] Mount ZFS pool on different system
Hi, I have a faulty hard drive on my notebook, but I have all my data stored on an external USB HDD with a zfs. Now I want to mount that external zfs hdd on a different notebook running solaris and supporting zfs as well. I am unable to do so. If I'd run zpool create, it would wipe out my external hdd what I of course want to avoid. So how can I mount a zfs filesystem on a different machine without destroying it? Thanks and Regards, Dave. -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] SOLVED: Mount ZFS pool on different system
RTFM seems to solve many problems ;-) :# zpool import poolname -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] ZFS disk read failure when pools are simultaneously scrubbed, x86 snv_104
Hi. Running snv_104 x86 against some very generic hardware as a testbed for some fun projects and as a home fileserver. Rough specifications of the host: * Intel Q6600 * 6GB DDR2 * Multiple 250GB, 500GB SATA connected HDD's of mixed vendors * Gigabyte GA-DQ6 series motherboard * etc. The problem or interesting scenario. I decided to cron a zpool scrub of all three zpool's on the host system simultaneously. Something like this: 00 01 * * * /usr/sbin/zpool scrub backups > /dev/null 2>&1 00 01 * * * /usr/sbin/zpool scrub ztank > /dev/null 2>&1 00 01 * * * /usr/sbin/zpool scrub zebraware_root > /dev/null 2>&1 So, we know from reading documentation that: [i]Because scrubbing and resilvering are I/O-intensive operations, ZFS only allows one at a time. If a scrub is already in progress, the "zpool scrub" command ter- minates it and starts a new scrub. If a resilver is in progress, ZFS does not allow a scrub to be started until the resilver completes[/i] Please note the "[b]ZFS only allows one at a time[/b]" statement. Maybe relevant to what I'm about to explain. Maybe not. I've noticed that when I lay my cron out in such a way two things happen: 1. On the "backups" pool, which is a simple zpool "stripe" with no redundancy, mirroring or anything of use, the pool will fault at some interminant point inside the scrub operation 2. The same thing will ALSO occur on the root pool (zebraware_root). However, if the scrubs are cron'ed at DIFFERENT times, allowing a period of time to lapse where each will complete before the next starts, these errors are not presented in /var/adm/messages, and a "zpool status -x" reports all pools as healthy. It is only if the pools are cron'ed to scrub simultaneously will read errors occur. Some interesting output, occurring just after the simultaneous scrub starts on the three pools that exist on the host: Dec 30 06:37:22 rapoosev5 scsi: [ID 107833 kern.warning] WARNING: /p...@0,0/pci8086,2...@1c,4/pci-...@0/i...@0 (ata0): Dec 30 06:37:22 rapoosev5 timeout: abort request, target=0 lun=0 Dec 30 06:37:22 rapoosev5 scsi: [ID 107833 kern.warning] WARNING: /p...@0,0/pci8086,2...@1c,4/pci-...@0/i...@0 (ata0): Dec 30 06:37:22 rapoosev5 timeout: abort device, target=0 lun=0 Dec 30 06:37:22 rapoosev5 scsi: [ID 107833 kern.warning] WARNING: /p...@0,0/pci8086,2...@1c,4/pci-...@0/i...@0 (ata0): Dec 30 06:37:22 rapoosev5 timeout: reset target, target=0 lun=0 Dec 30 06:37:22 rapoosev5 scsi: [ID 107833 kern.warning] WARNING: /p...@0,0/pci8086,2...@1c,4/pci-...@0/i...@0 (ata0): Dec 30 06:37:22 rapoosev5 timeout: reset bus, target=0 lun=0 Dec 30 06:37:22 rapoosev5 scsi: [ID 107833 kern.warning] WARNING: /p...@0,0/pci8086,2...@1c,4/pci-...@0/i...@0 (ata0): Dec 30 06:37:22 rapoosev5 timeout: early timeout, target=1 lun=0 Dec 30 06:37:22 rapoosev5 scsi: [ID 107833 kern.warning] WARNING: /p...@0,0/pci8086,2...@1c,4/pci-...@0/i...@0 (ata0): Dec 30 06:37:22 rapoosev5 timeout: early timeout, target=0 lun=0 Dec 30 06:37:22 rapoosev5 gda: [ID 107833 kern.warning] WARNING: /p...@0,0/pci8086,2...@1c,4/pci-...@0/i...@0/c...@0,0 (Disk0): Dec 30 06:37:22 rapoosev5 Error for command 'read sector' Error Level: Informational Dec 30 06:37:22 rapoosev5 gda: [ID 107833 kern.notice] Sense Key: aborted command Dec 30 06:37:22 rapoosev5 gda: [ID 107833 kern.notice] Vendor 'Gen-ATA ' error code: 0x3 Dec 30 06:37:22 rapoosev5 gda: [ID 107833 kern.warning] WARNING: /p...@0,0/pci8086,2...@1c,4/pci-...@0/i...@0/c...@1,0 (Disk1): Dec 30 06:37:22 rapoosev5 Error for command 'read sector' Error Level: Informational Dec 30 06:37:22 rapoosev5 gda: [ID 107833 kern.notice] Sense Key: aborted command Dec 30 06:37:22 rapoosev5 gda: [ID 107833 kern.notice] Vendor 'Gen-ATA ' error code: 0x3 Dec 30 06:37:22 rapoosev5 gda: [ID 107833 kern.warning] WARNING: /p...@0,0/pci8086,2...@1c,4/pci-...@0/i...@0/c...@0,0 (Disk0): Dec 30 06:37:22 rapoosev5 Error for command 'read sector' Error Level: Informational Dec 30 06:37:22 rapoosev5 gda: [ID 107833 kern.notice] Sense Key: aborted command Dec 30 06:37:22 rapoosev5 gda: [ID 107833 kern.notice] Vendor 'Gen-ATA ' error code: 0x3 Shortly after this, we'll see: Jan 1 06:39:58 rapoosev5 fmd: [ID 441519 daemon.error] SUNW-MSG-ID: ZFS-8000-FD, TYPE: Fault, VER: 1, SEVERITY: Major Jan 1 06:39:58 rapoosev5 EVENT-TIME: Thu Jan 1 06:39:56 EST 2009 Jan 1 06:39:58 rapoosev5 PLATFORM: P35-DQ6, CSN: , HOSTNAME: rapoosev5 Jan 1 06:39:58 rapoosev5 SOURCE: zfs-diagnosis, REV: 1.0 Jan 1 06:39:58 rapoosev5 EVENT-ID: e6d95684-5ec0-4897-d761-b7e16ed40f2c Jan 1 06:39:58 rapoosev5 DESC: The number of I/O errors associated with a ZFS device exceeded Jan 1 06:39:58 rapoosev5acceptable levels. Refer to http://sun.com/msg/ZFS-8000-FD for more information. And bang. Part of a pool is taken offline. We all know where that ends up. At this point, I can issue a "zpool clear" to the filesys
Re: [zfs-discuss] ZFS disk read failure when pools are simultaneously scrubbed, x86 snv_104
On 03 January, 2009 - Jake Carroll sent me these 5,9K bytes:
> Hi.
>
> Running snv_104 x86 against some very generic hardware as a testbed for some
> fun projects and as a home fileserver. Rough specifications of the host:
>
> * Intel Q6600
> * 6GB DDR2
> * Multiple 250GB, 500GB SATA connected HDD's of mixed vendors
> * Gigabyte GA-DQ6 series motherboard
> * etc.
>
> The problem or interesting scenario.
>
> I decided to cron a zpool scrub of all three zpool's on the host system
> simultaneously. Something like this:
>
> 00 01 * * * /usr/sbin/zpool scrub backups > /dev/null 2>&1
> 00 01 * * * /usr/sbin/zpool scrub ztank > /dev/null 2>&1
> 00 01 * * * /usr/sbin/zpool scrub zebraware_root > /dev/null 2>&1
>
> So, we know from reading documentation that:
>
> [i]Because scrubbing and resilvering are I/O-intensive
> operations, ZFS only allows one at a time. If a scrub is
> already in progress, the "zpool scrub" command ter-
> minates it and starts a new scrub. If a resilver is in
> progress, ZFS does not allow a scrub to be started until
> the resilver completes[/i]
>
> Please note the "[b]ZFS only allows one at a time[/b]" statement.
> Maybe relevant to what I'm about to explain. Maybe not.
One at a time per pool.
> So, my puzzling thoughts:
>
> 1. Am I just experiencing some form of crappy consumer grade
> controller I/O limitations or an issue of the controllers on this
> consumer grade kit not being up to the task of handling multiple
> scrubs occurring on different filesystems at any given time>?
Probably. When getting too much load, you might get some overhearing or
something. Shouldn't happen if the hw + drivers works as expected..
You will probably get similar results if you start too much regular io..
> 2. Is this natural and to be expected (and moreover, am I breaking the
> rules) by attempting to scrub more than one pool at once - ergo
> [i]"well, what did you expect?[/i]"
I scrub more than one pool at a time all the time, no issues.
> Out of fear and sensibility, I've never simultaneously scrubbed
> production pools on our 6 series arrays at work, or for anything that
> actually matters - but I am interested in getting to the bottom of
> this, all the same.
/Tomas
--
Tomas Ögren, st...@acc.umu.se, http://www.acc.umu.se/~stric/
|- Student at Computing Science, University of Umeå
`- Sysadmin at {cs,acc}.umu.se
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS poor performance on Areca 1231ML
Le 20 déc. 08 à 22:34, Dmitry Razguliaev a écrit : > Hi, I faced with a similar problem, like Ross, but still have not > found a solution. I have raidz out of 9 sata disks connected to > internal and 2 external sata controllers. Bonnie++ gives me the > following results: > nexenta,8G, > 104393,43,159637,30,57855,13,77677,38,56296,7,281.8,1,16,26450,99,+++ > ++,+++,29909,93,24232,99,+,+++,13912,99 > while running on a single disk it gives me the following: > nexenta,8G, > 54382,23,49141,8,25955,5,58696,27,60815,5,270.8,1,16,19793,76,+,+ > ++,32637,99,22958,99,+,+++,10490,99 > The performance difference of between those two seems to be too > small. I checked zpool iostat -v during bonnie++ itelligent writing > and it looks it, every time more or less like this: > Did you run : zpool iostat -v 1 ? > capacity operationsbandwidth > pool used avail read write read write > -- - - - - - - > iTank 7.20G 2.60T 12 13 1.52M 1.58M > raidz17.20G 2.60T 12 13 1.52M 1.58M >c8d0- - 1 1 172K 203K >c7d1- - 1 1 170K 203K >c6t0d0 - - 1 1 172K 203K >c8d1- - 1 1 173K 203K >c9d0- - 1 1 174K 203K >c10d0 - - 1 1 174K 203K >c6t1d0 - - 1 1 175K 203K >c5t0d0s0 - - 1 1 176K 203K >c5t1d0s0 - - 1 1 176K 203K > > As far as I understand it, less each vdev executes only 1 i/o in a > time. time. however, on a single device zpool iostat -v gives me the > following: > > > capacity operationsbandwidth > pool used avail read write read write > -- - - - - - - > rpool5.47G 181G 3 3 441K 434K > c7d0s05.47G 181G 3 3 441K 434K > -- - - - - - - > > In this case this device performs 3 i/o in a time, which gives it > much higher bandwidth per unit. > > Is there any way to increase i/o counts for my iTank zpool? > I'm running OS-11.2008 on MSI P45 Diamond with 4G of memory > > Best Regards, Dmitry > -- > 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] zfs & iscsi sustained write performance
Le 9 déc. 08 à 03:16, Brent Jones a écrit : > On Mon, Dec 8, 2008 at 3:09 PM, milosz wrote: >> hi all, >> >> currently having trouble with sustained write performance with my >> setup... >> >> ms server 2003/ms iscsi initiator 2.08 w/intel e1000g nic directly >> connected to snv_101 w/ intel e1000g nic. >> >> basically, given enough time, the sustained write behavior is >> perfectly periodic. if i copy a large file to the iscsi target, >> iostat reports 10 seconds or so of -no- writes to disk, just small >> reads... then 2-3 seconds of disk-maxed writes, during which time >> windows reports the write performance dropping to zero (disk queues >> maxed). >> This looks consistent with being limited by the network factors. Disks are idling while the next ZFS transaction group is being formed. What is less clear is why windows write performance drops to zero. One possible explanation is that during, the write bursts the small reads are being starved preventing progress on the Initiator side. -r >> so iostat will report something like this for each of my zpool >> disks (with iostat -xtc 1) >> >> 1s: %b 0 >> 2s: %b 0 >> 3s: %b 0 >> 4s: %b 0 >> 5s: %b 0 >> 6s: %b 0 >> 7s: %b 0 >> 8s: %b 0 >> 9s: %b 0 >> 10s: %b 0 >> 11s: %b 100 >> 12s: %b 100 >> 13s: %b 100 >> 14s: %b 0 >> 15s: %b 0 >> >> it looks like solaris hangs out caching the writes and not actually >> committing them to disk... when the cache gets flushed, the >> iscsitgt (or whatever) just stops accepting writes. >> >> this is happening across controllers and zpools. also, a test copy >> of a 10gb file from one zpool to another (not iscsi) yielded >> similar iostat results: 10 seconds of big reads from the source >> zpool, 2-3 seconds of big writes to the target zpool (target zpool >> is 5x bigger than source zpool). >> >> anyone got any ideas? point me in the right direction? >> >> thanks, >> >> milosz >> -- >> This message posted from opensolaris.org >> ___ >> zfs-discuss mailing list >> zfs-discuss@opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >> > > Are you running at compression? I see this behavior with heavy loads, > and GZIP compression enabled. > What does 'zfs get compression' say? > > -- > Brent Jones > br...@servuhome.net > ___ > 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] Mount ZFS pool on different system
> Now I want to mount that external zfs hdd on a different notebook running > solaris and > supporting zfs as well. > > I am unable to do so. If I'd run zpool create, it would wipe out my external > hdd what I of > course want to avoid. > > So how can I mount a zfs filesystem on a different machine without destroying > it? > zpool import ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS disk read failure when pools are simultaneously scrubbed, x86 snv_104
On Sat, 3 Jan 2009, Jake Carroll wrote: > > 1. Am I just experiencing some form of crappy consumer grade > controller I/O limitations or an issue of the controllers on this > consumer grade kit not being up to the task of handling multiple > scrubs occurring on different filesystems at any given time>? This seems like the result of either a device weakness, or a device driver weakness. Many people here have requested shorter timeouts on devices and it seems that this is an example of why shorter timeouts are not a good idea. It would useful to find out of you can cause this problem by causing severe I/O loads other than via 'scrub'. Bob == Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Error 16: Inconsistent filesystem structure after a change in the system
I recovered the system and created the opensolaris-12 BE. The system was working fine. I had the grub menu, it was fully recovered. At this stage I decided to create a new BE but leave the opensolaris-12 BE as an active BE and manually boot to the opensolaris-13 BE. So the situation looked like this: beadm list opensolaris-12 R / 3.73G static 2009-01-03 14:44 opensolaris-13 N - 120.74M static 2009-01-03 14:51 Running the opensolaris-13 BE I installed 2 packages: SUNWsmbs SUNWsmbskr responsible for the solaris CIFS service. I reboot the box and it still was fine. I had the grub menu and the boot_archive wasn't corrupted. After the reboot I configured the solaris CIFS service and exchanged some data between the opensolaris and a laptop via a network. I've been doing this for 3h. Then I decided to reboot the box again to see if it's still OK. I used init 6, but this time I ended up in the grub> menu. When I manually wanted to boot it looked like this: bootfs rpool/ROOT/opensolaris-13 OK kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS Error 16: Inconsistent filesystem structure I had to use rpool/ROOT/opensolaris-12 and it was fine. I didn't even get to load the boot_archive module. Usually it breaks during the boot_archive module load. I'm unable to use the opensolaris-13 BE and I've lost the CIFS configuration as I can't boot the BE. Can someone wise help me to narrow down this bug. Thanks in advance Rafal -- 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] Error 16: Inconsistent filesystem structure after a change in the system
Hey Rafal, this sounds like missing GANG block support in GRUB. Checkout putback log for snv_106 (afaik), there's a bug where grub fails like this. Cheers, Spity On 3.1.2009, at 21:11, Rafal Pratnicki wrote: > I recovered the system and created the opensolaris-12 BE. The system > was working fine. I had the grub menu, it was fully recovered. > At this stage I decided to create a new BE but leave the > opensolaris-12 BE as an active BE and manually boot to the > opensolaris-13 BE. > So the situation looked like this: > beadm list > opensolaris-12 R / 3.73G static 2009-01-03 14:44 > opensolaris-13 N - 120.74M static 2009-01-03 14:51 > Running the opensolaris-13 BE I installed 2 packages: SUNWsmbs > SUNWsmbskr responsible for the solaris CIFS service. I reboot the > box and it still was fine. I had the grub menu and the boot_archive > wasn't corrupted. After the reboot I configured the solaris CIFS > service and exchanged some data between the opensolaris and a laptop > via a network. I've been doing this for 3h. Then I decided to reboot > the box again to see if it's still OK. I used init 6, but this time > I ended up in the grub> menu. When I manually wanted to boot it > looked like this: > bootfs rpool/ROOT/opensolaris-13 > OK > kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS > Error 16: Inconsistent filesystem structure > I had to use rpool/ROOT/opensolaris-12 and it was fine. > I didn't even get to load the boot_archive module. Usually it breaks > during the boot_archive module load. > I'm unable to use the opensolaris-13 BE and I've lost the CIFS > configuration as I can't boot the BE. > > Can someone wise help me to narrow down this bug. > Thanks in advance > Rafal > -- > 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] ZFS vs HardWare raid - data integrity?
On Wed, Dec 31, 2008 at 01:53:03PM -0500, Miles Nordin wrote: > The thing I don't like about the checksums is that they trigger for > things other than bad disks, like if your machine loses power during a > resilver, or other corner cases and bugs. I think the Netapp > block-level RAID-layer checksums don't trigger for as many other > reasons as the ZFS filesystem-level checksums, so chasing problems is > easier. Why does losing power during a resilver cause any issues for the checksums in ZFS? Admittedly, bugs can always cause problems, but that's true for any software. I'm not sure that I see a reason that the integrated checksums and the separate checksums are more or less prone to bugs. Under what situations would you expect any differences between the ZFS checksums and the Netapp checksums to appear? I have no evidence, but I suspect the only difference (modulo any bugs) is how the software handles checksum failures. -- Darren ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] What will happen when write a block of 8k if the recordsize is 128k. Will 128k be written instead of 8k?
Hello qihua, Saturday, December 27, 2008, 7:04:06 AM, you wrote: > After we changed the recordsize to 8k, We first used dd to move the data files around. We could see the time recovering a archive log dropped from 40mins to 4 mins. But when using iostat to check, the read io is about 8K for each read, the write IO is still 128k for each write. Then we used cp to move the data files around as someone said dd might not change the recordsize. after that, the time to recover a log file was drop from 4mins to 1/4 mins. So it seems dd doens't change the recordsize completely, and cp does. And is there any utility that could check the recordsize of an existing file? Probably what happened was that when you did your dd first old files were still occupying disk space, possibly outer regions. Then you deleted them and did cp again - this time zfs probably put most of the data on the outer regions of disks and your backup got faster. (it all depends on your file sizes and disk sizes). -- Best regards, Robert Milkowski mailto:mi...@task.gda.pl http://milek.blogspot.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
