From: Stefan Priebe <s.priebe@profihost.ag>
To: Christoph Hellwig <hch@infradead.org>
Cc: Sage Weil <sage@inktank.com>,
"ceph-devel@vger.kernel.org" <ceph-devel@vger.kernel.org>
Subject: Re: FS / Kernel question choosing the correct kernel version
Date: Tue, 26 Jun 2012 10:26:25 +0200 [thread overview]
Message-ID: <4FE97231.4070106@profihost.ag> (raw)
In-Reply-To: <20120626081442.GA12789@infradead.org>
Am 26.06.2012 10:14, schrieb Christoph Hellwig:
> On Mon, Jun 25, 2012 at 03:11:17PM -0700, Sage Weil wrote:
>> On Sat, 23 Jun 2012, Stefan Priebe wrote:
>>> Hi,
>>>
>>> i got stuck while selecting the right FS for ceph / RBD.
>>>
>>> XFS:
>>> - deadlock / hung task under 3.0.34 in xfs_ilock / xfs_buf_lock while syncfs
>>
>> There was an ilock fix that went into 3.4, IIRC. Have you tried vanilla
>> 3.4? We are seeing some lockdep noise currently, but no deadlocks yet.
>
> Stefan, which deadlock is this, did you report it to the XFS list?
Yes i did. You are in CC ;-)
http://oss.sgi.com/archives/xfs/2012-05/msg00307.html
But i did not send a sysrq trigger as i then started to work with btrfs.
As i archieve more than two times better performance with ceph and btrfs.
Stefan
PS: i have this one laying around which is NOT in 3.0.X not sure whether
this is relevant:
From: Christoph Hellwig <hch@lst.de>
Subject: xfs: don't wait for all pending I/O in ->write_inode
If we wait for all pending I/O in ->write_inode we can starve the caller,
which sine recent changes can also be the flusher thread in kupdate mode.
Fortunately there is no good reason to do the wait, as a blocking caller
already waited for buffered I/O using filemap_write_and_wait_range, and thus
we don't have to rely on this, and kupdated doesn't care for us to finish
the write first, but just wants to snapshot the inode metadata to disk.
Upstream this was fixed in a much more intrusive way by
xfs: remove i_iocount
and the various patches leading towards it, including changes to the core
AIO code. I think this simpler patch is the better version for 3.0-stable.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Index: linux-2.6/fs/xfs/linux-2.6/xfs_super.c
===================================================================
--- linux-2.6.orig/fs/xfs/linux-2.6/xfs_super.c 2012-03-18
09:03:27.583397799 +0100
+++ linux-2.6/fs/xfs/linux-2.6/xfs_super.c 2012-03-18
09:03:45.083398125 +0100
@@ -892,7 +892,6 @@ xfs_fs_write_inode(
* ->sync_fs call do that for thus, which reduces the
number
* of synchronous log foces dramatically.
*/
- xfs_ioend_wait(ip);
error = xfs_log_dirty_inode(ip, NULL, 0);
if (error)
goto out;
next prev parent reply other threads:[~2012-06-26 8:26 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-23 18:26 FS / Kernel question choosing the correct kernel version Stefan Priebe
2012-06-25 22:11 ` Sage Weil
2012-06-26 8:14 ` Christoph Hellwig
2012-06-26 8:26 ` Stefan Priebe [this message]
2012-06-26 9:39 ` Stefan Priebe
2012-06-26 16:02 ` Sage Weil
2012-06-26 9:07 ` Stefan Priebe
2012-06-26 16:15 ` Stefan Priebe
2012-06-26 16:29 ` Mark Nelson
2012-06-26 16:43 ` Stefan Priebe
2012-06-26 16:59 ` Mark Nelson
2012-06-26 17:49 ` Stefan Priebe
2012-06-26 17:49 ` Stefan Priebe
2012-06-26 18:04 ` Stefan Priebe
2012-06-26 20:07 ` Mark Nelson
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=4FE97231.4070106@profihost.ag \
--to=s.priebe@profihost.ag \
--cc=ceph-devel@vger.kernel.org \
--cc=hch@infradead.org \
--cc=sage@inktank.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.