erik.ableson wrote:
You're running into the same problem I had with 2009.06 as they have "corrected" a bug where the iSCSI target prior to 2009.06 didn't honor completely SCSI sync commands issued by the initiator.
I think I've hit the same thing. I'm using an iscsi volume as the target 
for Time Machine backups for my new Mac Book Pro using the GlobalSAN 
initiator.  Running against an iscsi volume on my zfs pool, with both 
the Mac and the Solaris box on gigE, I was seeing the Time Machine 
backup (of 90GB of data) running at about 600-700KB (yes, KB) per second.
This would mean a backup time on the order of (optimistically) 45 hours, 
so I decided to give your suggestion a go.
For my freewheeling home use where everything gets tried, crashed, patched and put back together with baling twine (and is backed up elsewhere...) I've mounted a RAM disk of 1Gb which is attached to the pool as a ZIL and you see the performance run in cycles where the ZIL loads up to saturation, flushes out to disk and keeps going. I did write a script to regularly dd the ram disk device out to a file so that I can recreate with the appropriate signature if I have to reboot the osol box. This is used with the GlobalSAN initiator on OS X as well as various Windows and Linux machines, physical and VM.
Assuming this is a test system that you're playing with and you can 
destroy the pool with inpunity, and you don't have an SSD lying around 
to test with, try the following :
ramdiskadm -a slog 2g (or whatever size you can manage reasonably with 
the available physical RAM - try "vmstat 1 2" to determine available memory)
zpool add <poolname> log /dev/ramdisk/slog
I used a 2GB ram disk (the machine has 12GB of RAM) and this jumped the 
backup up to somewhere between 18-40MB/s, which means that I'm only a 
couple of hours away from finishing my backup.  This is, as far as I can 
tell, magic (since I started this message nearly 10GB of data have been 
transferred, when it took from 6am this morning to get to 20GB.)
It transfer speed drops like crazy when the write to disk happens, but 
it jumps right back up afterwards.
If you want to perhaps reuse the slog later (ram disks are not preserved over reboot) write the slog volume out to disk and dump it back in after restarting.
 dd if=/dev/ramdisk/slog of=/root/slog.dd
Now my only question is:  what do I do when it's done?  If I reboot and 
the ram disk disappears, will my tank be dead? Or will it just continue 
without the slog?  I realize that I'm probably totally boned if the 
system crashes, so I'm copying off the stuff that I really care about to 
another pool (the Mac's already been backed up to a USB drive.)
Have I meddled in the affairs of wizards?  Is ZFS subtle and quick to anger?

Steve
--
Stephen Green
http://blogs.sun.com/searchguy

_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to