On 4/1/2012 12:12 AM, daobang wang wrote: > Thank you very much! > I got it, so we can remove the Volume Group and Logical Volume to save resource. > And i will try RAID5 with 16 disks to write 96 total streams again. Why do you keep insisting on RAID5?!?! It is not suitable for your workload. It sucks Monday through Saturday and twice on Sunday for this workload. Test your 16 drive RAID5 array head to head with the linear array + XFS architecture I gave you instructions to create, and report back your results. > I used the Linux kernel 2.6.26.4. Which distro? 2.6.26 is *ancient* and has storage layer bugs. It does NOT have delaylog, which was introduced in 2.6.35, and wasn't fully performant until 2.6.38+. You're building and testing a new platform with a terribly obsolete distribution. You need a much newer kernel and distro. 3.0.x would be best. Debian 6.0.4 with a backport 3.0.x kernel would be a good start. > And we do not have BBWC Then you must re-enable barriers or perennially suffer more filesystem problems. I simply cannot emphasize enough how critical write barriers are to filesystem consistency. > The application has 16kb cache per stream, Is it possible to optimize > it if we use 32kb or 64kb cache? No. Read the app's documentation. This caching is to prevent dropped frames in the recorded file. Increasing this value won't affect disk performance. -- Stan -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
