On Sun, Apr 12, 2009 at 7:24 PM, Miles Nordin <car...@ivy.net> wrote:
>
> nl> Supermicro have several LSI controllers. AOC-USASLP-L8i with
> nl> the LSI 1068E
>
> That's what I'm using. It uses the proprietary mpt driver.
>
> nl> and AOC-USASLP-H8iR with the LSI 1078.
>
> I'm not using this.
>
> nl> How does is the performance compare to the Marvel?
>
> don't know, but the proprietary Marvell driver uses the SATA
> framework, and the LSI proprietary driver attaches like a SCSI
> controller without using SATA framework. If you are trying to burn
> CD's or play DVD's or use 'smartctl' on your hard disks, I'm not sure
> if it will work with LSI.
Disk storage only. I usually use USB cdroms for servers if I need them.
> nl> The LSI1068E has 16MB SRAM onboard cache - I expect this helps
> nl> performances, but does it causes issues with ZIL?
>
> no, it is just sillyness. It's just part of the controller/driver,
> not something to worry about.
>
I guess when you think, it is actually smaller (now) than the cache on many
HDDs. Probably a waste of space.
>
> nl> The LSI1078 has 512MB DDR2 onboard cache with a battery backup
> nl> option.
>
> yeah, without the battery the onboard cache may be a liability rather
> than an asset. You will have to worry if the card is unsafely
> offering to store things in this volatile cache. I'm not sure how it
> works out in practice.
>
I guess this is my main point of worry about this card.
1. Is the cache only used for RAID modes and not in JBOD mode?
2. If it is used by the controller is it driver dependant? Only works if
the driver can handle the cache
3. If the cache does work what happens if there is a power reset?
- In the first case if it is driver independent, and simply does a
cache to disk flush of IO commands on power restart would cause
corruption
with zfs?
- In the second case, similar to the first case but is it now
dependant on the driver? How stable is the driver? Is corruption a more
likely event?
4. In either case the option to turn off the cache might be important.
5. Furthermore, without a battery you might also desire to turn off the
battery.
> I think the battery-backed caches are much cheaper than a SSD slog,
> and the bandwidth to the cache is much higher than bandwidth to a
> single SATA port too. I don't like it, though, because data collects
> inside the cache which I can't get out. OTOH, slog plus data disks I
> can easily move from one machine to another while diagnosing a
> problem, if i suspect a motherboard or the LSI card itself is bad, for
> example.
>
I agree with your points. Even though an iRAM device seems like a hack,
without good information about the stability of controller base cache they
seem like the more portable solution.
nl> using the battery backup option, allowing "zil disable"?
>
> please reread the best practices. I think you're confusing two
> different options and planning to do something unsafe.
>
Sorry, I meant zfs_nocacheflush - which should only be used when NVRAM
is available or a secure power supply.
> t> UIO fits just fine in a normal chassis, you just have to
> t> remove the bracket. [...] it's really not a big deal.
>
> +1, that supermicro card, Nicholas, is UIO rather than PCIe, and it
> does work for me in plain PCIe slot with the bracket removed. so long
> as you are not moving around the machine too much, I agree it's not a
> big deal.
>
I plan to use supermicro chassis in a rack - so both a m/b designed for UIO
and in a stable location. Should be in fine.
Nicholas
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
