public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Michael Monnerie <michael.monnerie@is.it-management.at>
To: xfs@oss.sgi.com
Subject: Re: File system remain unresponsive until the system is rebooted.
Date: Wed, 15 Feb 2012 12:38:52 +0100	[thread overview]
Message-ID: <1851847.umXsU4b99o@saturn> (raw)
In-Reply-To: <20267.5137.85650.499331@tree.ty.sabi.co.UK>


[-- Attachment #1.1: Type: text/plain, Size: 1998 bytes --]

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 #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  parent reply	other threads:[~2012-02-15 11:39 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-30  9:18 File system remain unresponsive until the system is rebooted Supratik Goswami
2012-01-30 17:23 ` Peter Grandi
2012-01-31  1:31 ` Dave Chinner
2012-01-31  5:04   ` Supratik Goswami
2012-01-31  7:19     ` Emmanuel Florac
2012-01-31  9:04     ` Stan Hoeppner
2012-01-31 11:08       ` Emmanuel Florac
2012-02-01 12:31         ` Peter Grandi
2012-02-01 14:31           ` Emmanuel Florac
2012-02-01 22:20             ` Peter Grandi
2012-01-31 20:50       ` Dave Chinner
2012-02-01  0:20         ` Stan Hoeppner
2012-02-01 11:40           ` Peter Grandi
2012-02-01 23:55             ` Dave Chinner
2012-02-02 22:54             ` Peter Grandi
2012-02-03  1:32               ` Dave Chinner
2012-02-15 11:38               ` Michael Monnerie [this message]
2012-01-31 19:44     ` Dave Chinner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1851847.umXsU4b99o@saturn \
    --to=michael.monnerie@is.it-management.at \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox