From: Bernd Schubert <bernd.schubert@fastmail.fm>
To: Peter Grandi <pg@xfs.list.sabi.co.UK>, Linux fs XFS <xfs@OSS.SGI.com>
Subject: Re: Problem about very high Average Read/Write Request Time
Date: Mon, 20 Oct 2014 10:00:34 +0200 [thread overview]
Message-ID: <5444C122.4080104@fastmail.fm> (raw)
In-Reply-To: <21571.36364.518119.806191@tree.ty.sabi.co.uk>
On 10/19/2014 12:10 PM, Peter Grandi wrote:
>>> I am using xfs on a raid 5 (~100TB) and put log on external
>>> ssd device, the mount information is: /dev/sdc on
>>> /data/fhgfs/fhgfs_storage type xfs
>>> (rw,relatime,attr2,delaylog,logdev=/dev/sdb1,sunit=512,swidth=15872,noquota).
>>> when doing only reading / only writing , the speed is very
>>> fast(~1.5G), but when do both the speed is very slow (100M),
>>> and high r_await(160) and w_await(200000).
>
>> What are your kernel version, mount options and xfs_info output ?
>
> Those are usually important details, but in this case the
> information that matters is already present.
>
> There is a ratio of 31 (thirty one) between 'swidth' and 'sunit'
> and assuming that this reflects the geometry of the RAID5 set
> and given commonly available disk sizes it can be guessed that
> with amazing "bravery" someone has configured a RAID5 out of 32
> (thirty two) high capacity/low IOPS 3TB drives, or something
> similar.
>
> It is even "braver" than that: if the device name
> "/data/fhgfs/fhgfs_storage" is dedscriptive, this "brave"
> RAID5 set is supposed to hold the object storage layer of a
> BeeFS highly parallel filesystem, and therefore will likely
> have mostly-random accesses.
>
Where do you get the assumption from that FhGFS/BeeGFS is going to do
random reads/writes or the application of top of it is going to do that?
Bernd
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-10-20 8:00 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-18 9:26 Problem about very high Average Read/Write Request Time quanjun hu
2014-10-18 12:38 ` Emmanuel Florac
2014-10-19 10:10 ` Peter Grandi
2014-10-20 8:00 ` Bernd Schubert [this message]
2014-10-21 18:27 ` Peter Grandi
2014-10-23 16:20 ` Bernd Schubert
2014-10-23 20:09 ` Peter Grandi
2014-10-24 21:45 ` Dave Chinner
2014-10-25 11:00 ` Peter Grandi
2014-10-25 19:31 ` Stan Hoeppner
2014-10-25 12:36 ` Peter Grandi
2014-10-23 23:01 ` Peter Grandi
2014-10-19 21:16 ` Stan Hoeppner
2014-10-25 14:47 ` storage with "very high Average Read/Write Request Time" Peter Grandi
2014-10-25 22:07 ` Peter Grandi
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=5444C122.4080104@fastmail.fm \
--to=bernd.schubert@fastmail.fm \
--cc=pg@xfs.list.sabi.co.UK \
--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.