I'm trying to implement a Nexsan SATABeast (an external disk array,
read more: http://www.nexsan.com/satabeast.php, 14 disks available)
with a Sun Fire X4100 M2 server running Solaris 10 u6 (connected via
fiber) and have a couple of questions:
(My motivation for this is the corrupted ZFS volume discussion I had
earlier with no result, and this time I'm trying to make a more robust
implementation)
1. On the external disk array, I not able to configure JBOD or RAID 0
or 1 with just one disk. I can't find any options for my Solaris
server to access the disk directly so I have to configure some raids
on the SATABeast. I was thinking of striping two disks in each raid
and then add all 7 raids to one zpool as a zraid. The problem with
this is if one disk breaks down, I'll loose one RAID 0 disk but maybe
ZFS can handle this? Should I rather implement RAID5 disks one the
SATABeast and then export them to the Solaris machine? 14 disks would
give me 4 RAID5 volumes and 2 spare disks? I'll loose a lot of disk
space. What about create larger RAID volumes on the SATABeast? Like 3
RAID volumes with 5 disks in 2 RAIDS and 4 disks in one RAID? I'm
really not sure what to choose ... At the moment I've striped two
disks in one RAID volume.
2. After reading from the ZFS Evil Tuning Guide (http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide#Cache_Flushes
) about cache flushes I checked the cache configuration on the
SATABaest and I can change these settings:
System Admin
Configure Cache
Cache Configuration
Current write cache state: Enabled, FUA ignored - 495 MB
Manually override current write cache status: [ ] Force write cache to
Disabled
Desired write cache state: [X] Enabled [ ] Disabled
Allow attached host to override write cache configuration: [ ]
Ignore force unit access (FUA) bit: [X]
Write cache streaming mode: [ ]
Cache optimization setting:
[ ] Random access
[X] Mixed sequential/random
[ ] Sequential access
And from the help section:
Write cache will normally speed up host writes, data is buffered in
the RAID controllers memory when the installed disk drives are not
ready to accept the write data. The RAID controller write cache
memory is battery backed, this allows any unwritten array data to be
kept intact during a power failure situation. When power is restored
this battery backed data will be flushed out to the RAID array.
Current write cache state - This is the current state of the write
cache that the RAID system is using.
Manually override current write cache status - This allows the write
caching to be forced on or off by the user, this change will take
effect immediately.
Desired write cache state - This is the state of the write cache the
user wishes to have after boot up.
Allow attached host to override write cache configuration - This
allows the host system software to issue commands to the RAID system
via the host interface that will either turn off or on the write
caching.
Ignore force unit access (FUA) bit - When the force unit access
(FUA) bit is set by a host system on a per command basis data is
written / read directly to / from the disks without using the
onboard cache. This will incur a time overhead, but guarantees the
data is on the media. Set this option to force the controller to
ignore the FUA bit such that command execution times are more
consistent.
Write cache streaming mode - When the write cache is configured in
streaming mode (check box ticked), the system continuously flushes
the cache (it runs empty). This provides maximum cache buffering to
protect against raid system delays adversely affecting command
response times to the host.
When the write cache operates in non-streaming mode (check box not
ticked) the system runs with a full write cache to maximise cache
hits and maximise random IO performance.
Cache optimization setting - The cache optimization setting adjusts
the cache behaviour to maximize performance for the expected host I/
O pattern.
Note that the write cache will be flushed 5 seconds after the last
host write. It is recommended that all host activity is stopped 30
seconds before powering the system off.
Any thoughts about this?
Regards,
Lars-Gunnar Persson
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
