LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Jan Kara <jack@suse.cz>
Cc: sct@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Fix commit of ordered data buffers
Date: Tue, 13 Sep 2005 18:43:05 -0700	[thread overview]
Message-ID: <20050913184305.24705a98.akpm@osdl.org> (raw)
In-Reply-To: <20050913153024.GL30108@atrey.karlin.mff.cuni.cz>

Jan Kara <jack@suse.cz> wrote:
>
> When a buffer is locked it does not mean that write-out is in progress. We
>  have to check if the buffer is dirty and if it is we have to submit it
>  for write-out. We unconditionally move the buffer to t_locked_list so
>  that we don't mistake unprocessed buffer and buffer not yet given to
>  ll_rw_block(). This subtly changes the meaning of buffer states in
>  t_locked_list - unlock buffer (for list users different from
>  journal_commit_transaction()) does not mean it has been written. But
>  only journal_unmap_buffer() cares and it now checks if the buffer
>  is not dirty.

Seems complex.  It means that t_locked_list takes on an additional (and
undocumented!) meaning.

Also, I don't think it works.  See ll_rw_block()'s handling of
already-locked buffers..

An alternative is to just lock the buffer in journal_commit_transaction(),
if it was locked-and-dirty.  And remove the call to ll_rw_block() and
submit the locked buffers by hand.

That would mean that if someone had redirtied a buffer which was on
t_sync_datalist *while* it was under writeout, we'd end up waiting on that
writeout to complete before submitting more I/O.  But I suspect that's
pretty rare.

One thing which concerns me with your approach is livelocks: if some process
sits in a tight loop writing to the same part of the same file, will it
cause kjournald to get stuck?

The problem we have here is "was the buffer dirtied before this commit
started, or after?".  In the former case we are obliged to write it.  In
the later case we are not, and in trying to do this we risk livelocking.

  reply	other threads:[~2005-09-14  1:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-13 15:30 Jan Kara
2005-09-14  1:43 ` Andrew Morton [this message]
2005-09-14 12:03   ` Jan Kara
2005-09-14 18:30     ` Andrew Morton
2005-09-15  7:23       ` Jan Kara
2005-09-14 13:02   ` Stephen C. Tweedie
2006-09-11 21:05 Jan Kara
2006-09-11 22:12 ` Andrew Morton
2006-09-28  8:31 ` Zhang, Yanmin
2006-09-28 21:35   ` Jan Kara
2006-09-29  1:27     ` Zhang, Yanmin
2006-09-29  9:21       ` Jan Kara

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=20050913184305.24705a98.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=jack@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sct@redhat.com \
    --subject='Re: [PATCH] Fix commit of ordered data buffers' \
    /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

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).