Re: [zfs-discuss] Importing old vdev
On 10/07/2011 11:02 AM, James Lee wrote:
Hello,
I had a pool made from a single LUN, which I'll call c4t0d0 for the
purposes of this email. We replaced it with another LUN, c4t1d0, to
grow the pool size. Now c4t1d0 is hosed and I'd like to see about
recovering whatever data we can from the original LUN, c4t0d0.
I can still see the ZFS labels on t0 with zdb [1], but it is not
available for importing (even with zpool import -D). Are there any
tools available for me to tweak the metadata on the old LUN so that I
can import it? Is there anything else I can try?
I am using Solaris 10 U9, and before anyone says anything, our SAN guys
don't really understand ZFS or else I would have made the pool redundant
in the first place.
I found an old post by Jeff Bonwick with some code that does EXACTLY
what I was looking for [1]. I had to update the 'label_write' function
to support the newer ZFS interfaces:
/*
* Write a label block with a ZBT checksum.
*/
static void
label_write(int fd, uint64_t offset, uint64_t size, void *buf)
{
zio_eck_t *zbt, zbt_orig;
zio_cksum_t zc;
zbt = (zio_eck_t *)((char *)buf + size) - 1;
zbt_orig = *zbt;
ZIO_SET_CHECKSUM(zbt-zec_cksum, offset, 0, 0, 0);
zio_checksum_SHA256(buf, size, zc);
zbt-zec_cksum = zc;
VERIFY(pwrite64(fd, buf, size, offset) == size);
*zbt = zbt_orig;
}
Then I compiled it against the illumos headers...something like:
/usr/sfw/bin/gcc -I illumos-gate/usr/src/uts/common/fs/zfs -o labelfix
labelfix.c illumos-gate/usr/src/uts/common/fs/zfs/sha256.c assfail.o -lzfs
-lnvpair -lmd
And finally ran the resulting binary against the old LUN:
# zpool import
# ./labelfix /dev/rdsk/c4t697192602845533030373032d0s0
# zpool import
pool: idmtestdb2
id: 10473782060848894552
state: DEGRADED
action: The pool can be imported despite missing or damaged devices. The
fault tolerance of the pool may be compromised if imported.
config:
idmtestdb2 DEGRADED
replacing-0 DEGRADED
c4t697192602845533030373032d0 ONLINE
c4t697192602845533030363743d0 UNAVAIL cannot open
# zpool import idmtestdb2
# zpool detach idmtestdb2 18335497050081682816
# zpool status idmtestdb2
pool: idmtestdb2
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
idmtestdb2 ONLINE 0 0 0
c4t697192602845533030373032d0 ONLINE 0 0 0
errors: No known data errors
Thank you Jeff!
[1]
http://thread.gmane.org/gmane.os.solaris.opensolaris.zfs/15796/focus=15929
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Importing old vdev
Hello, I had a pool made from a single LUN, which I'll call c4t0d0 for the purposes of this email. We replaced it with another LUN, c4t1d0, to grow the pool size. Now c4t1d0 is hosed and I'd like to see about recovering whatever data we can from the original LUN, c4t0d0. I can still see the ZFS labels on t0 with zdb [1], but it is not available for importing (even with zpool import -D). Are there any tools available for me to tweak the metadata on the old LUN so that I can import it? Is there anything else I can try? I am using Solaris 10 U9, and before anyone says anything, our SAN guys don't really understand ZFS or else I would have made the pool redundant in the first place. Thanks, James [1] starlight ~ # zdb -l /dev/dsk/c4t0d0s0 LABEL 0 version=22 name='idmtestdb2' state=0 txg=0 pool_guid=10473782060848894552 hostid=2237159492 hostname='starlight.es.gwu.edu' top_guid=16179157240083602291 guid=5824491362217506815 vdev_children=1 vdev_tree type='replacing' id=0 guid=16179157240083602291 whole_disk=0 metaslab_array=23 metaslab_shift=31 ashift=9 asize=268425232384 is_log=0 children[0] type='disk' id=0 guid=5824491362217506815 path='/dev/dsk/c4t0d0s0' devid='id1,ssd@n0/a' phys_path='/scsi_vhci/ssd@g0:a' whole_disk=1 DTL=60 children[1] type='disk' id=1 guid=18335497050081682816 path='/dev/dsk/c4t1d0s0' devid='id1,ssd@n1/a' phys_path='/scsi_vhci/ssd@g1:a' whole_disk=1 DTL=254 create_txg=0 LABEL 1 version=22 name='idmtestdb2' state=0 txg=0 pool_guid=10473782060848894552 hostid=2237159492 hostname='starlight.es.gwu.edu' top_guid=16179157240083602291 guid=5824491362217506815 vdev_children=1 vdev_tree type='replacing' id=0 guid=16179157240083602291 whole_disk=0 metaslab_array=23 metaslab_shift=31 ashift=9 asize=268425232384 is_log=0 children[0] type='disk' id=0 guid=5824491362217506815 path='/dev/dsk/c4t0d0s0' devid='id1,ssd@n0/a' phys_path='/scsi_vhci/ssd@g0:a' whole_disk=1 DTL=60 children[1] type='disk' id=1 guid=18335497050081682816 path='/dev/dsk/c4t1d0s0' devid='id1,ssd@n1/a' phys_path='/scsi_vhci/ssd@g1:a' whole_disk=1 DTL=254 create_txg=0 LABEL 2 version=22 name='idmtestdb2' state=0 txg=0 pool_guid=10473782060848894552 hostid=2237159492 hostname='starlight.es.gwu.edu' top_guid=16179157240083602291 guid=5824491362217506815 vdev_children=1 vdev_tree type='replacing' id=0 guid=16179157240083602291 whole_disk=0 metaslab_array=23 metaslab_shift=31 ashift=9 asize=268425232384 is_log=0 children[0] type='disk' id=0 guid=5824491362217506815 path='/dev/dsk/c4t0d0s0' devid='id1,ssd@n0/a' phys_path='/scsi_vhci/ssd@g0:a' whole_disk=1 DTL=60 children[1] type='disk' id=1 guid=18335497050081682816 path='/dev/dsk/c4t1d0s0' devid='id1,ssd@n1/a' phys_path='/scsi_vhci/ssd@g1:a' whole_disk=1 DTL=254 create_txg=0 LABEL 3 version=22 name='idmtestdb2' state=0 txg=0 pool_guid=10473782060848894552 hostid=2237159492 hostname='starlight.es.gwu.edu' top_guid=16179157240083602291 guid=5824491362217506815 vdev_children=1 vdev_tree type='replacing' id=0 guid=16179157240083602291 whole_disk=0 metaslab_array=23 metaslab_shift=31 ashift=9 asize=268425232384 is_log=0 children[0] type='disk' id=0 guid=5824491362217506815 path='/dev/dsk/c4t0d0s0' devid='id1,ssd@n0/a' phys_path='/scsi_vhci/ssd@g0:a'
Re: [zfs-discuss] Adaptec AAC driver
On 03/29/2010 09:32 AM, Yariv Graf wrote: Hi I had the same problem with 2405 Remove aac of 134 and istall driver from adaptec . Driver for sol10u4 On Mar 29, 2010, at 4:25 PM, Bruno Sousa bso...@epinfante.com mailto:bso...@epinfante.com wrote: Currently i'm evaluating a system with an Adaptec 52445 Raid HBA, and the driver supplied by Opensolaris doesn't support JBOD drives. FYI, there is a bug report open for this issue: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6862536 Hopefully we'll see some action on it soon. James ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] ZFS Dedup Performance
I haven't seen much discussion on how deduplication affects performance. I've enabled dudup on my 4-disk raidz array and have seen a significant drop in write throughput, from about 100 MB/s to 3 MB/s. I can't imagine such a decrease is normal. # zpool iostat nest 1 (with dedup enabled): ... nest1.05T 411G 91 18 197K 2.35M nest1.05T 411G147 15 443K 1.98M nest1.05T 411G 82 28 174K 3.59M # zpool iostat nest 1 (with dedup disabled): ... nest1.05T 410G 0787 0 96.9M nest1.05T 410G 1899 253K 95.0M nest1.05T 409G 0533 0 48.5M I do notice when dedup is enabled that the drives sound like they are constantly seeking. iostat shows average service times around 20 ms which is normal for my drives and prstat shows that my processor and memory aren't a bottleneck. What could cause such a marked decrease in throughput? Is anyone else experiencing similar effects? Thanks, James ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS Dedup Performance
On 01/08/2010 02:42 PM, Lutz Schumann wrote: See the reads on the pool with the low I/O ? I suspect reading the DDT causes the writes to slow down. See this bug http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6913566. It seems to give some backgrounds. Can you test setting the primarycache=metadata on the volume you test ? This would be my initial test. My suggestion would be that it may improve the situation because your ARC can be better utilized for DDT (this does not make much sence for production without a SSD cache, because you practially disable all caches for reading without a L2ARC (aka SSD)!) As I read the bug report above - it seems the if the DDT (deduplication table) does not fit into memory or dropped from there the DDT has to be read from disk causing massive random I/O. The symptoms described in that bug report do match up with mine. I have also experienced long hang times (1hr) destroying a dataset while the disk just thrashes. I tried setting primarycache=metadata, but that did not help. I pulled the DDT statistics for my pool, but don't know how to determine its physical size-on-disk from that. If deduplication ends up requiring a separate sort-of log device, that will be a real shame. # zdb -DD nest DDT-sha256-zap-duplicate: 780321 entries, size 338 on disk, 174 in core DDT-sha256-zap-unique: 6188123 entries, size 335 on disk, 164 in core DDT histogram (aggregated over all DDTs): bucket allocated referenced __ __ __ refcnt blocks LSIZE PSIZE DSIZE blocks LSIZE PSIZE DSIZE -- -- - - - -- - - - 15.90M752G729G729G5.90M752G729G729G 2 756K 94.0G 93.7G 93.6G1.48M188G187G187G 45.36K152M 80.3M 81.5M22.4K618M325M330M 8 258 4.05M 1.93M 2.00M2.43K 36.7M 16.3M 16.9M 16 30434K 42K 50.9K 597 10.2M824K 1003K 325255K 65.5K 66.6K 204 10.5M 3.26M 3.30M 64 20 2.02M906K910K1.41K141M 62.0M 62.2M 1284 2K 2K 2.99K 723362K362K541K 2561 512 512 766 277138K138K207K 5122 1K 1K 1.50K1.62K830K830K 1.21M Total6.65M846G823G823G7.41M941G917G917G dedup = 1.11, compress = 1.03, copies = 1.00, dedup * compress / copies = 1.14 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
