> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- > boun...@opensolaris.org] On Behalf Of Roy Sigurd Karlsbakk > > The test box is a supermicro thing with a Core2duo CPU, 8 gigs of RAM, 4 gigs > of mirrored SLOG and some 150 gigs of L2ARC on 80GB x25-M drives. The > data drives are 7 2TB drives in RAIDz2. We're getting down to 10-20MB/s on > Bacula backup to this system, meaning streaming, which should be good for > RAIDz2. Since the writes are local (bacula-sd running), async writes will be > the > main thing. Initial results show pretty good I/O perfrmance, but after about > 2TB used, the I/O speed is down to the numbers I mentioned
You probably know this already, but while you're doing async writes, neither the slog nor the l2arc offer any benefit to you. Also, your problem might be completely unrelated to your pool. You might try writing to /dev/null instead, and just see what the performance is. If it's still slow, you know you're waiting for something else that's not zpool related. Also, you might try making an old backup file available on something like external disk or whatever, and simply copy it to the zpool in question. If it goes fast, once again you're eliminating the possibility that the problem is zpool related. I don't know what bacula uses in the background, but I know I've had terrible performance using dd to write to tape while dd would perform just fine writing to anything else ... and anything else would work fine writing to tape. My point is only to say that you should question precisely *what* is causing the performance bottleneck. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
