On Sep 11, 2009, at 9:48 PM, Dale Ghent <[email protected]> wrote:
On Sep 11, 2009, at 3:27 PM, Ross Walker wrote:
On Fri, Sep 11, 2009 at 3:01 PM, glidic anthony
<[email protected]> wrote:
Hi all i have make an opensolaris file server and i use comstar.
The first tume i try comstar i have performance nearly 100/110 mb/
s or now i have remake a file server with a different
configuration and the comstar performance is only 10/20 mb/s.
I don't understand why.
Was the first time you built it with OpenSolaris 2008.11 and the
second time with 2009.06?
There was a change in how ZVOL devices behave between 2008.11 and
2009.06 that makes all ZVOL IO synchronous now for data safety.
You can try adding an SSD device as an slog device to the pool.
I've been bitten by the bug fix (6770534) you mention, but while
using the legacy iscsi target server. The exported LUNs comprise a
ZFS file system on the remote client.
Performance is so dismal that I have to stay away from any version
of the ZFS driver that has that bug fix in it. I mean, the
enforcement of synchronous IO, while understandable, just causes IO
performance on the iscsi clients to plummet.
Short of buying SSD for a zil log device, which in all of my servers
there is no physical room for, there is no recourse at all?
Because my clients are using ZFS on those LUNs, I've investigated
the fast write ack option that you can set via iscsitadm, but that
appears to make no difference in IO performance.
This synchronous IO performance, while perhaps a proper thing, just
kills performance.
Without an SSD log or NVRAM caching controller your best bet is to use
use flat or sparse files on the pool.
This has several advantages over zvols anyways.
1) You can move these files to zfs datasets with different
recordsizes, once you set a blocksize on a zvol your stuck with it.
2) You can create loopback mounts to them to recover data, I don't
think you can do that with a zvol (you'll need to offset 64k with
comstar to skip the metadata, why they put it at the front of the
store I will never know).
3) You can have a little better control of the target names with
iscsitgt, you always have have full control with comstar.
To do thin provisioning with iscsitgt you need to set, svccfg -s
iscsitgt setprop iscsitgt/thin-provisioning = boolean: true
If you don't and set a file as a backing store (without creating and
zero'ing it out beforehand) iscsitgt will try to zero it out using
mmap (not the swiftest move), which on a large file will eventually
fill page cache and swap bricking the box.
I always set the thin provisioning option to prevent accidentally
bricking my host and if I want a zero'd out backing file I'll zero it
out myself with dd.
-Ross
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
