Do your performance test on Linux using 32k or 64k i/o blocks, then do
it on FreeBSD using the same. You'll seem similar performance between
the two. Unless your application is bypassing the filesystem to do
raw I/O that is larger than that, you won't see any benefit from the
larger i/o sizes that Linux can do.
Scott
Fredrik Widlund wrote:
Yes I received it, and no I'm not saying it's a driver bug. However I
did assume this would be the driver specific.
Do I understand you correctly; you're saying that it's FreeBSD's
controller I/O framework in general that cause this performance gap to
Windows and Linux, and it's not driver specific?
Kind regards,
Fredrik Widlund
Scott Long wrote:
You seem convinced that this is a driver bug. Did you receive my
series of emails 2 days ago that explained why it is not?
Scott
Fredrik Widlund wrote:
Please don't direct this to me as I've already pointed out that I'm not
asking about this. Fyi. the cards were shipped in a hurry mistakenly
without bbus, we have to wait until next week for them to arrive, and
until then we will use cache without batteries since the performance
degradation using wthru on fbsd gives us no choice. This is not up for
debate here so please let that thread end here and now.
In general it's not up to you to decide how people evaluate
performance/safety/price ratios. In our case, for example, performance
is not an option, regardless of safety. With a 20MB/s bottleneck for
writing we can throw the system out the window. Our problem was
receiving a card that performed 200MB/s (not using cache) on a different
platform, but 20MB/s (not using cache) on fbsd with no apparent or
logical explanation as to why. If the fbsd mfi-driver's wthru support
comes with a severe performance penalty I suggest the man page mentions
it, regardless of whether you think "WThru is a bad thing (tm)" or not.
Kind regards,
Fredrik Widlund
Scott Long wrote:
The battery unit should not be considered optional. It's not about
performance on silly 'dd' tests, it's about data safety. Way back
when,
all enterprise RAID cards were sold with an integrated battery because
it was the right thing to do. These days, when you're shopping for
RAID
cards, you should just add in the cost of the battery as a
matter-of-fact and not try to skimp by without one.
Scott
Fredrik Widlund wrote:
Because the card itself will deal with the buffered writes
independently
of the kernel activity the risk should be less than using softupdates.
Words like "screwed" seems to me to be exaggerated in the generic
case.
I our case specific you would need to understand the nature of what we
are doing to be able to make a comment like that. For example data is
redundant (exists in many copies), consists of very large sequencial
files, we have plenty of backup power, and the greatest risk is fbsd
locking up/crashing.
Anyway our specific case is not of interest here, I just wanted to
share
our experiences with the LSI MegaSAS with other fbsd users so they
understand why they get a severe performance degradation if they
try to
use such a card w/o a bbu, and what their options are.
The generic case of how great the risk really is of corrupting
filesystems completely using caches of any kind on the way to
secondary
storage still is interesting to me, so if you could elaborate here
that
would be great!
Kind regards,
Fredrik Widlund
Bob Willcox wrote:
On Wed, Nov 01, 2006 at 12:34:22AM +0100, Fredrik Widlund wrote:
Yes, it forces writeback even when the controller has no BBU.
Choosing WBack itself will default back to WThru. It's dangerous,
but I guess it should be much less dangerous than using for example
softupdates.
I don't see how it could be *less* dangerous than using softupdates.
Any
loss of power while writing and it seems to me that you are going
to be
screwed w/o a BBU.
[snip]
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to
"[EMAIL PROTECTED]"
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
