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
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
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
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
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
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
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
Hi,
We have a problem with the MFI raid-driver under FreeBSD 6.1 and 6.2-PRE.
Hardware: Dell 1850
Raid adapter: LSI 8480E
There is no problem to detect, initialize and configure, but there is a
serious problem with performance with Raid-5. Read performance is good,
but write performance
Fredrik Widlund wrote:
setups but hit the same limitation again and again. The strange part is
that a Dell raid adapter based on the same chipset, the Perc 5/I, works
well with writes achieving 200MB/s.
Any ideas would be greatly appreciated.
Several:
- are there cache differences between
Ivan Voras wrote:
Several:
- are there cache differences between the controllers (amount of
memory, cache policy)?
Default settings on both.
- how does writing directly to the device (bypassing file system)
compare?
Drives are four seagate 7200.10 400GB in a Raid-5 configuration.
[/mnt/test
Fredrik Widlund wrote:
Ivan Voras wrote:
Several:
- are there cache differences between the controllers (amount of
memory, cache policy)?
Default settings on both.
Maybe you should check what the defaults are :) Especially the amount of
memory and is there a battery to back the cache.
-
Fredrik Widlund wrote:
Ivan Voras wrote:
Several:
- are there cache differences between the controllers (amount of
memory, cache policy)?
Default settings on both.
- how does writing directly to the device (bypassing file system)
compare?
Drives are four seagate 7200.10
256MB cache, no BBU. Tried a lot of different combinations of settings.
fbsd 6.2pre writes 220MB/s with raid-0
If I boot windows server 2003 instead, it writes at around 180MB/s with
raid-5 (same configs).
With fbsd6.2pre, I get the best performance with BadBBU/direct
io/disabled cache and 8
The adapter won't allow me to do so since there's no BBU.
Fredrik
Tom Judge wrote:
Have you tried setting the write cache policy to write back rather
than write thru?
Tom
___
freebsd-stable@freebsd.org mailing list
Solved my issue with LSI 8480E without BBU. With write: BadBBU,
cache: enabled, and io: cached, performance rose to around 200MB/s
from 20MB/s.
With BadBBU/enabled cache/io cached:
[root@ ~/bench]# ./bench /dev/mfid0p1 65536
file /dev/mfid0p1, bs 65536
rate: 228130816 Bps, write: 285 us
rate:
Fredrik Widlund wrote:
Solved my issue with LSI 8480E without BBU. With write: BadBBU,
cache: enabled, and io: cached, performance rose to around 200MB/s
from 20MB/s.
I don't know what BadBBU is, but from some Googling it seems to be a
setting that overrides BBU detection, and enables write
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. We
have little choice until our order of BBUs get here, since the
performance
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. We
have little
As I said in private email, you need the battery in order to restore
performance. Linux and Windows get by because they can send larger
I/O's to the controller than FreeBSD can. The larger I/O's aren't
terribly useful for most real-world applications, though.
Scott
Fredrik Widlund wrote:
19 matches
Mail list logo
