Am Donnerstag, 2. Februar 2012, 22:54:09 schrieb Peter Grandi: > This then the argument that on platforms with bad latency that > decision works still works well because then you might as well go > for throughput. Hi, I just took these lines to reply to your whole mail. I guess that the advantage of XFS will grow on a shared storage type like you typically have on a VM environment. The aggregation XFS does can result in a more bursty type of I/O, with larger I/Os happening at once. That always is better for RAID storage - which you normally have in a VM environment. Also, all better RAID controllers, and especially enterprise RAIDs, have large write buffers, so even more aggregation occurs at the storage itself, helping throughput maximisation. I don't know of any scientific investigation of "which filesystem is better in a VM environment" that could be referenced in a generic way, mostly because there are so many variables there that it doesn't neccessarily fit your own use case. Maybe someone can point me to such research material. My hope is - and that is what Dave is arguing - that minimising I/O "disturbances" by metadata work like log file handling helps keeping overall throughput on a shared storage type in a VM environment high. And that seems very reasonable. I don't really understand your argument about delay for a single thread fsync. First, XFS should do this quicker by "batching" transactions, and second, overall storage throughput is usually much more important than that of a single server performance - at least in a VM environment. I need to run 50 servers on a storage with acceptable performance, and if one server needs more performance than is available, you need to do something else - there are lots of options then. -- mit freundlichen Grüssen, Michael Monnerie, Ing. BSc it-management Internet Services: Protéger http://proteger.at [gesprochen: Prot-e-schee] Tel: +43 660 / 415 6531
Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
