On Fri, 4 Jan 2008, Changliang Chen wrote:
Hi Justin£¬
From your report£¬It looks that the p34-default's behavior is
better£¬which item make you consider that the p34-dchinner looks nice£¿
--
Best Regards
The re-write and sequential input and output is faster for dchinner.
Justin.
Why does mdadm still use 64k for the default chunk size?
Probably because this is the best balance for average file
sizes, which are smaller than you seem to be testing with?
Well average file sizes relate less to chunk sizes than access
patterns do. Single threaded sequential reads with
Peter Grandi wrote:
In particular if one uses parity-based (not a good idea in
general...) arrays, as small chunk sizes (as well as stripe
sizes) give a better chance of reducing the frequency of RMW.
Thanks for your thoughts - the above was my thinking when I posted.
Regards,
Richard
-
To
what is nobarrier ?
On 12/31/07, Justin Piszcz [EMAIL PROTECTED] wrote:
Dave's original e-mail:
# mkfs.xfs -f -l lazy-count=1,version=2,size=128m -i attr=2 -d agcount=4
dev
# mount -o logbsize=256k dev mtpt
And if you don't care about filsystem corruption on power loss:
# mount -o
In message [EMAIL PROTECTED] you wrote:
what is nobarrier ?
...
# mount -o logbsize=256k,nobarrier dev mtpt
See http://oss.sgi.com/projects/xfs/faq.html
Q: How can I address the problem with the write cache?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang
Justin Piszcz wrote:
Why does mdadm still use 64k for the default chunk size?
Probably because this is the best balance for average file sizes, which
are smaller than you seem to be testing with?
Regards,
Richard
-
To unsubscribe from this list: send the line unsubscribe linux-raid in
the
