From: Michael Monnerie <michael.monnerie@is.it-management.at>
To: xfs@oss.sgi.com
Cc: Stan Hoeppner <stan@hardwarefreak.com>,
John Bokma <contact@johnbokma.com>
Subject: Re: 30 TB RAID6 + XFS slow write performance
Date: Fri, 22 Jul 2011 08:10:00 +0200 [thread overview]
Message-ID: <201107220810.01889@zmi.at> (raw)
In-Reply-To: <20110721064838.GA13963@dastard>
[-- Attachment #1.1: Type: Text/Plain, Size: 2684 bytes --]
On Donnerstag, 21. Juli 2011 Dave Chinner wrote:
> If you are writing files that grow like this, then you are doing
> something wrong. If the app can't do it's IO differently, then this
> is exactly the reason we have userspace-controlled preallocation
> interfaces.
>
> Filesystems cannot prevent user stupidity from screwing something
> up....
This can happen if you copy a syslog server over to a new disk, then let
it start it's work again. Many files that start small and grow. Luckily,
the logs are rotated latest monthly, so it shouldn't be too bad.
> > And files >64KiB are immediately fragmented
> > then. At this time, there are only 16384 * 2KiB = 32MiB used, which
> > is 3,125% of the disk. I can't believe my numbers, are they true?
>
> No, because most filesystems have a 4k block size.
I just meant pure disk usage. Of 1GB, only 32MB are used, and this worst
case example hits us badly.
> Not to mention
> that fragmentation is likely to be limited to the single AG the files
> in the directory belong to. i.e. even if we can't allocation a sunit
> aligned chunk in an AG, we won't switch to another AG just to do
> sunit aligned allocation.
This is good to know also, thanks.
> > OK, this is a worst case scenario, and as you've said before, any
> > filesystem can be considered full at 85% fill grade. But it's
> > incredible how quickly you could fuck up a filesystem when using
> > su/sw and writing small files.
>
> Well, don't use a filesystem that is optimised for storing large
> sizes, large files and high bandwidth for storing lots of small
> files, then. Indeed, the point of not packing the files is so they
> -don't fragemnt as they grow-. XFS is not designed to be optimal
> for small filesystems or small files. In most cases it will deal
> with them just fine, so in reality your concerns are mostly
> unfounded...
Yes, I just wanted to know about the corner cases, and how XFS behaves.
Actually, we're changing over to using NetApps, and with their WAFL
anyway I should drop all su/sw usage and just use 4KB blocks.
And even when XFS is optimized for large files, there are often small
ones. Think of a mysql server with hundreds of DBs and
innodb_file_per_table set. Even when some DBs are large, there are many
small files.
But this thread has drifted a bit. XFS does great work, and now I
understand the background a bit more. Thanks, Dave.
--
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
// Haus zu verkaufen: http://zmi.at/langegg/
[-- 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
next prev parent reply other threads:[~2011-07-22 6:10 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-18 19:58 30 TB RAID6 + XFS slow write performance John Bokma
2011-07-19 0:00 ` Eric Sandeen
2011-07-19 8:37 ` Emmanuel Florac
2011-07-19 22:37 ` Stan Hoeppner
2011-07-20 0:20 ` Dave Chinner
2011-07-20 5:16 ` Stan Hoeppner
2011-07-20 6:44 ` Dave Chinner
2011-07-20 12:10 ` Stan Hoeppner
2011-07-20 14:04 ` Michael Monnerie
2011-07-20 23:01 ` Dave Chinner
2011-07-21 6:19 ` Michael Monnerie
2011-07-21 6:48 ` Dave Chinner
2011-07-22 6:10 ` Michael Monnerie [this message]
2011-07-22 18:05 ` Stan Hoeppner
2011-07-22 23:10 ` Dave Chinner
2011-07-24 6:14 ` Stan Hoeppner
2011-07-24 8:47 ` Michael Monnerie
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=201107220810.01889@zmi.at \
--to=michael.monnerie@is.it-management.at \
--cc=contact@johnbokma.com \
--cc=stan@hardwarefreak.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.