Comments on: Home Fileserver: Backups

By: Simon

Simon — Mon, 28 Apr 2008 20:06:58 +0000

Hi Justin,

Thanks for the compliment! Yes, iSCSI seems quite magical so far. It makes it easy to see how streaming data for backups could be easy to a remote offsite location, as iSCSI needs an IP address. Have fun, and you reminded me that I need to tackle that article on incremental backups… have fun!

Simon

By: Justin

Justin — Mon, 28 Apr 2008 17:00:06 +0000

Hi Simon,

I’m fairly new to ZFS, but as I’m in charge of setting up my lab’s fileserver, I figured I’d give it a shot! I think it’s great but always had trouble with the incremental backups until I found this page - iSCSI is amazing! Looking forward to the incremental backups post. Keep up the good work!

-Justin

By: Simon

Simon — Tue, 01 Apr 2008 22:22:49 +0000

Ah yes, I see what you mean now. Yes, it may well perform better using it directly. If you try it let me know if you see any difference, as I still have a load of other stuff to learn like snapshots, clones, zfs send/recv for incremental backups etc.

If I wanted to try using the imported iSCSI disk directly, rather than attaching it to a pool, how would I write to it with ZFS? There seems relatively little documentation about using iSCSI on Solaris with fully explained examples. Either that, or I have not looked well enough, perhaps.

Yes, those transfer speeds are quite decent, I thought. And I haven’t yet looked into (1) setting the MTU size to 9000 for jumbo frames, or (2) using the 2 onboard GbE ports simultaneously to get a 2Gbps full-duplex pipe using trunking/bonding — something else to try out one day Although I’ll probably use the 2 built-in GbE’s on the Mac Pro and the 2 built-in GbE’s on the ZFS fileserver as this is probably where I’d get the most benefit, as the backup machine will only be taking incremental backups once I get that going properly using snapshot ranges combined with use of zfs send/recv.

Good to know about the striping — thanks a lot!

By: Wout Mertens

Wout Mertens — Tue, 01 Apr 2008 10:02:39 +0000

Hi Simon,

I meant, you have your zvols exported as iSCSI targets, and then you give those as raw disks to ZFS which implements another layer of ZFS on it. So you basically are storing ZFS blocks inside ZFS blocks on the disks…

So I was wondering if it would be faster if you made the individual disks available as iSCSI targets instead of the ZVOL. The iSCSI server would have to do slightly less processing and block sizes would perhaps be better aligned? Plus the client would have more insight in broken disks, which might or might not make a difference.

Although I must say I like those transfer rates

ZFS will stripe at all times, so don’t worry about that.

By: Simon

Simon — Mon, 31 Mar 2008 21:13:36 +0000

Oops, forgot to say: I got 73MBytes/sec sustained copying 4GB of video data. On a much larger transfer (650GB) I got a sustained 48MBytes/sec, and this included a mixture of different file sizes. Then again, I don’t know how the iSCSI target zvol block device is written to: stripe across all disks or simply sequential write across a series of disks as each becomes full. Perhaps the latter, which would mean if you were writing to a really slow disk, you might get lousy slow writes. Maybe it’s described somewhere?

By: Simon

Simon — Mon, 31 Mar 2008 20:29:20 +0000

Hi Wout, I would say it’s more like a zvol (block device) that has been exported from the backup machine in the form of an iSCSI target, and mounted via the iSCSI initiator in the form of a local ZFS pool — local to the fileserver, that is.

Simon

By: wout mertens

wout mertens — Sun, 30 Mar 2008 22:01:26 +0000

So you’re creating a zvol on top of a zvol? How is the performance? I wonder if making the back end storage available as plain iscsi targets will make much of a difference…

Thanks for the overview!

Wout.