From: Jan Kara <jack@suse.cz>
To: Zheng Liu <gnehzuil.liu@gmail.com>
Cc: Theodore Ts'o <tytso@mit.edu>, Eric Sandeen <sandeen@redhat.com>,
Ext4 Developers List <linux-ext4@vger.kernel.org>,
Jan Kara <jack@suse.cz>
Subject: Re: [PATCH] ext4: fix ext4_evict_inode() racing against workqueue processing code
Date: Tue, 26 Mar 2013 21:34:03 +0100 [thread overview]
Message-ID: <20130326203403.GE2082@quack.suse.cz> (raw)
In-Reply-To: <20130326055251.GA17165@gmail.com>
On Tue 26-03-13 13:52:51, Zheng Liu wrote:
> Sorry for the late reply.
>
> On Wed, Mar 20, 2013 at 10:45:23AM -0400, Theodore Ts'o wrote:
> > On Wed, Mar 20, 2013 at 09:14:42AM -0500, Eric Sandeen wrote:
> > >
> > > As an aside, is there any reason to have "dioread_nolock" as an option
> > > at this point? If it works now, would you ever *not* want it?
> > >
> > > (granted it doesn't work with some journaling options etc, but that
> > > behavior could be automatic, w/o the need for special mount options).
> >
> > The primary restriction is that diread_nolock doesn't work when fs
> > block size != page size. If your proposal is that we automatically
> > enable diread_nolock when we can use it safely, that's definitely
> > something to consider for the next merge window.
>
> Yes, I also think we can automatically enable dioread_nolock because it
> brings us some benefits.
But isn't there also some overhead due to buffered writes having to go
through uninit->init conversion? Plus there's this potential deadlock in
dioread_nolock code (http://www.spinics.net/lists/linux-ext4/msg36569.html)
which I'm not sure how to fix yet...
> BTW, I think there is an minor improvement for dio overwrite codepath
> with indirect-based file. We don't need to take i_mutex in this
> condition just as we have done for extent-based file. If a user mounts
> a ext2/3 file system with a ext4 kernel modules, he/she could get a
> lower latency. But it seems that it would break dio semantic in ext2/3.
> Currently in ext2/3 if we issue a overwrite dio and then issue a read
> dio. We will always read the latest data because we wait on i_mutex
> lock. But after parallelizing overwite dio, this semantic might breaks.
> I re-read this doc but it seems that it doesn't describe this case. Do
> we need to keep this semantic?
I'm not sure but also I don't think it's important to optimize that
special case.
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
next prev parent reply other threads:[~2013-03-26 20:34 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-20 1:29 [PATCH] ext4: fix ext4_evict_inode() racing against workqueue processing code Theodore Ts'o
2013-03-20 1:38 ` Theodore Ts'o
2013-03-20 13:22 ` Jan Kara
2013-03-20 13:37 ` Theodore Ts'o
2013-03-20 13:42 ` Jan Kara
2013-03-20 13:51 ` Theodore Ts'o
2013-03-20 14:14 ` Eric Sandeen
2013-03-20 14:45 ` Theodore Ts'o
2013-03-20 20:13 ` Jan Kara
2013-03-26 5:52 ` Zheng Liu
2013-03-26 5:55 ` Zheng Liu
2013-03-26 20:34 ` Jan Kara [this message]
2013-03-27 3:13 ` Zheng Liu
2013-03-29 7:32 ` Zheng Liu
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=20130326203403.GE2082@quack.suse.cz \
--to=jack@suse.cz \
--cc=gnehzuil.liu@gmail.com \
--cc=linux-ext4@vger.kernel.org \
--cc=sandeen@redhat.com \
--cc=tytso@mit.edu \
/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;
as well as URLs for NNTP newsgroup(s).