linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: Anatol Pomozov <anatol.pomozov@gmail.com>
Cc: Dmitry Monakhov <dmonakhov@openvz.org>, linux-ext4@vger.kernel.org
Subject: Re: ext4_orphan_del() sleeps in non-journal mode
Date: Sat, 15 Sep 2012 21:54:30 -0400	[thread overview]
Message-ID: <20120916015430.GA11797@thunk.org> (raw)
In-Reply-To: <CAOMFOmWh3CVdREk5uyPCxwFQBTopiqainfGYxC6HijieM1rEWA@mail.gmail.com>

On Sat, Sep 15, 2012 at 03:28:19PM -0700, Anatol Pomozov wrote:
> 
> But the other more general issue "ext4_orphan_del sleeps in no-journal
> mode" still applies. As Dmitry mentioned in this commit 3d287de3b828
> such sleep might degrade performance. In no-journal mode we do not
> need to manipulate with i_orphan list and no reason to take the mutex....
> 
> In this example we take handle and important thing to note here is
> that IS_ERR(handle) can be true only in journal mode when starting
> journal failed. In non-journal mode ext4_journal_start() *always*
> returns a fake handle that is non-error (see ext4_get_nojournal). So
> the example above never sleeps in ext4_orphan_del().

Instead of trying to "fix" this at all of the call sites for
ext4_orphan_del(), the better way to fix this something like this:

-	/* ext4_handle_valid() assumes a valid handle_t pointer */
-	if (handle && !ext4_handle_valid(handle))
-	   return 0;
+	sbi = EXT4_SB(inode->i_sb);
+	if (!sbi->journal)
+		return 0;

I don't consider it a high priority fir for upstream, since all of the
places where ext4_orphan_del(NULL, ..) is called are in error paths,
where performance is not critical.  However, it should fix the problem
you're working on.

As far as the the local Google patch to 2.6.34, it might be worth
looking to see if it's still worth upstreaming it in the light of
commit 4bd809dbb: "ext4: don't take the i_mutex lock when doing DIO
overwrites".  It's been a while since I've looked that the DIO fast
path changes, but if it's worth geting upstream, we should do that ---
but we _will_ need to make it workable for file systems with journals.
(Which is someting I'd really like to fix for Google kernels, since
leaving things broken for file systems with journal is a bad ju-ju ---
at the very least we should disable the fast path codepath if one of
our customers try to mount file system with a journal.)

Cheers,

						- Ted

      parent reply	other threads:[~2012-09-16  1:54 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-14 21:06 ext4_orphan_del() sleeps in non-journal mode Anatol Pomozov
2012-09-15  2:15 ` Anatol Pomozov
2012-09-15 10:06 ` Dmitry Monakhov
2012-09-15 22:28   ` Anatol Pomozov
2012-09-15 22:51     ` Anatol Pomozov
2012-09-16  1:54     ` Theodore Ts'o [this message]

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=20120916015430.GA11797@thunk.org \
    --to=tytso@mit.edu \
    --cc=anatol.pomozov@gmail.com \
    --cc=dmonakhov@openvz.org \
    --cc=linux-ext4@vger.kernel.org \
    /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).