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
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
Description: This is a digitally signed message part.