File system remain unresponsive until the system is rebooted.

[Michael Monnerie]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20120215/fc598303/attachment.sig>