Re: [zfs-discuss] replace same sized disk fails with too small error
Grab the AOE driver and pull "aoelabinit" out of the package.They wrote it just for forcing EFI or Sun labels onto disks when the normal Solaris tools get in the way. coraid's website looks like it's broken at the moment, so you may need to find it elsewhere on the web. -- 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] replace same sized disk fails with too small error
I ran into a bad label causing this once. Usually the s2 slice is a good bet for your whole disk device, but if it's EFI labeled, you need to use p0 (somebody correct me if I'm wrong). I like to zero the first few megs of a drive before doing any of this stuff. This will destroy any data. Obviously, change "c7t1d0p0" to whatever your drive's device is. dd if=/dev/zero of=/dev/rdsk/c7t1d0p0 bs=512 count=8192 For EFI you may also need to zero the end of the disk too because it writes the VTOC to both the beginning and end for redundancy. I'm not sure of the best way to get the drive size in blocks without using format(1M) so I'll leave that as an exercise for the reader.For my 500gb disks it was something like: 976533504 is $number_of_blocks (from format) - 8192 (4mb in 512 byte blocks). dd if=/dev/zero of=/dev/rdsk/c7t0d0p0 bs=512 count=8192 seek=976533504 When you run format -> fdisk, it should prompt you to write a new Solaris label to the disk.Just accept all the defaults. format -d c7t1d0 Remember to double-check your devices and wait a beat before pressing enter with those dd commands as they destroy without warning or checking. -- 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] zfs not yet suitable for HA applications?
Ok. I figured out how to basically backport snv104's iscsi initiator (version 1.55 versus snv101b's 1.54) into snv101b. Set everything up as in my previous post then create a new C file: cat > boot_sym.c <
Re: [zfs-discuss] zfs not yet suitable for HA applications?
I compiled just the iscsi initiator this evening and remembered this thread, so here are the simple instructions. This is not the "right" way to do it. It's just the easiest. I should (and probably will) use a Makefile for this, but for now, this works and I've been able to tweak some of the timeouts in my system. Tests are still running, so I have no results on whether it's a good idea or not yet. # Check out all of ONNV (mercurial does not have partial checkouts AFAIK) hg clone -U ssh://a...@hg.opensolaris.org/hg/onnv/onnv-gate # go into the iscsi initiator directory cd onnv-gate/usr/src/uts/common/io/scsi/adapters/iscsi # edit your files vim iscsi.h # compile! PATH=/opt/SunStudioExpress/bin:/usr/ccs/bin:$PATH export PATH for cfile in *.c ../../../../../../common/iscsi/*.c ../../../../inet/kifconf/kifconf.c do cc -I. -I../../../.. -D_KERNEL -D_SYSCALL32 -m64 -xO3 -xmodel=kernel -c $cfile done ld -m64 -dy -r -N misc/scsi -N fs/sockfs -N sys/doorfs -N misc/md5 -N inet/kifconf -o iscsi *.o # back up the default driver cp /kernel/drv/amd64/iscsi /root/iscsi.bak # install cp iscsi /kernel/drv/amd64/iscsi # if you want to avoid reboot, shut down iscsi_initiator update_drv iscsi # reboot if necessary - I prefer to "zfs export" and "rm -f /etc/iscsi/*" before doing so in my lab There was a bit more that went into this when I did it, but that should get you far enough to play with timeouts. Be sure to check out elfdump(1).It can tell you a lot about your new driver -- it's how I verified I got all the right bits in my build before I tried it in the kernel for the first time. See also: http://docs.sun.com/app/docs/doc/819-3196/eqbvo?a=view Enjoy! -- 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] Status of zpool remove in raidz and non-redundant stripes
They also mentioned this at some of the ZFS talks at LISA 2008.The general argument is that, while plenty of hobbyists are clamoring for this, not enough paying customers are asking to make it a high enough priority to get done. If you think about it, the code is not only complicated but will be incredibly hard to get right and _prove_ it's right. Maybe the ZFS guys can just borrow the algorithm from Linux mdraid's experimental CONFIG_MD_RAID5_RESHAPE: http://git.kernel.org/?p=linux/kernel/git/djbw/md.git;a=blob;f=drivers/md/raid5.c;h=224de022e7c5d6574cf46747947b3c9e326c8632;hb=HEAD#1885 -- 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] ZFS space efficiency when copying files from
Rsync can update in-place. From rsync(1): --inplace update destination files in-place -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
