From: Andreas Dilger <adilger@clusterfs.com>
To: "Theodore Ts'o" <tytso@mit.edu>, Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org, ext2-devel@lists.sourceforge.net
Subject: Re: [Ext2-devel] Re: [RFC/RFT] [PATCH] EXT3: Retry allocation after journal commit
Date: Fri, 14 May 2004 15:06:22 -0600 [thread overview]
Message-ID: <20040514210622.GH18086@schnapps.adilger.int> (raw)
In-Reply-To: <20040514195920.GB30501@thunk.org>
On May 14, 2004 15:59 -0400, Theodore Ts'o wrote:
> On Fri, May 14, 2004 at 11:48:37AM -0600, Andreas Dilger wrote:
> > Well, actually my patch just waited on the _previous_ transaction to commit
> > (which can be done anywhere without retrying the operation) and then set
> > h_sync on the _current_ transaction so that as soon as the current operations
> > are completed it will also be committed and the blocks released. One can't
> > of course arbitrarily call journal_stop() or that breaks the transaction
> > atomicity.
> >
> > For 99.9% of cases this should be sufficient and doesn't involve changing
> > the code everywhere - only in ext3_new_block().
>
> I tried that first, actually. In the test case I was trying, it only
> worked 33% of the time. The other 66% of the time, the rm -rf all fit
> into the current running transaction, and waiting on the previous
> transaction wasn't sufficient to solve the problem.
I guess the success ratio dependends on how many blocks are tied up in
the transaction, the size of the journal, and how much free space is
left in the filesystem. In my tests (dd to a file that does O_TRUNC and
overwrites with the same file size) this change wasn't 100% successful
but fixed it the majority of the time.
> > Also, Ted's approach of retrying the operations "outside" the
> > transaction won't work if there are nested journal transactions
> > being done - those will hold the transaction open so doing
> > journal_stop/journal_start doesn't really accomplish anything.
>
> That was why I was retrying at the top-level functions: ext3_mkdir,
> for example. There won't be a nested journal transaction there.
Waiting for the currently committing transaction to complete would
deadlock Lustre, because it starts journal transactions above ext3 so
that it can write update records in the same transaction as the
filesystem operation.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
next prev parent reply other threads:[~2004-05-14 21:06 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-14 0:42 Theodore Ts'o
2004-05-14 2:53 ` Andrew Morton
2004-05-14 4:37 ` [Ext2-devel] " Theodore Ts'o
2004-05-14 4:49 ` Andrew Morton
2004-05-14 17:48 ` Andreas Dilger
2004-05-14 19:59 ` Theodore Ts'o
2004-05-14 21:06 ` Andreas Dilger [this message]
2004-05-15 13:18 ` Theodore Ts'o
2004-05-19 22:04 ` question about ext3_find_goal with reservation Mingming Cao
2004-05-19 22:52 ` Andrew Morton
2004-05-20 1:04 ` [Ext2-devel] " Mingming Cao
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=20040514210622.GH18086@schnapps.adilger.int \
--to=adilger@clusterfs.com \
--cc=akpm@osdl.org \
--cc=ext2-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--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
all inboxes | Powered by JetHome®