--On Wednesday, March 24, 2010 5:12 PM +0000 Michal <mic...@ionic.co.uk>
wrote:
If you were to do something like this, I'd make sure to have a fast
local ZIL (log) device on the head node. That would reduce latency
for writes, you might also do the same for reads. Then your bulk
storage comes from the iSCSI boxes.
Just a thought.
I've not come across ZIL so I think I will have to do my research
ZFS Intent Log, basically ZFS's WAL (Write Ahead Log) -- write committed to
the ZIL are considered durable, and the system then batches up ZIL writes
to normal storage. For reads there's the cache devices. I honestly do not
know the state of this in FreeBSD, I gave up using ZFS on FreeBSD for now
due to poor performance. Also the *linux* iSCSI kernel initiator is
*really* buggy, can't say anything about FreeBSD iSCSI initiator nor
target, nor anything about the Linux iSCSI target.
By using (fast) ZFS log and ZFS cache devices that are local to the 'san
head end' you can *greatly* increase the array's perceived/usable speed.
At least in theory you could use geom_gate and zfs I suppose, never
tried it though.
ggatec(8), ggated(8) are your friends for that.
Vince
Just had a look at ggatec, I've not seen or heard of that so I will
continue looking through that.
Many thanks to all, if I get something solid working I will be sure to
update the list with what will hopefully be a very cheap (other then
HDD's) SAN
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"