Message-ID: <38f6fb7d1002160210x6dc86fb5o82825e7677c07994@mail.gmail.com>
Date:	Tue, 16 Feb 2010 15:40:22 +0530
From:	Kailas Joshi <kailas.joshi@...il.com>
To:	Jan Kara <jack@...e.cz>
Cc:	tytso@....edu, linux-ext4@...r.kernel.org,
	Jiaying Zhang <jiayingz@...gle.com>
Subject: Re: Help on Implementation of EXT3 type Ordered Mode in EXT4

On 15 February 2010 20:30, Jan Kara <jack@...e.cz> wrote:
> On Sat 13-02-10 14:13:17, Kailas Joshi wrote:
>> On 13 February 2010 01:37,  <tytso@....edu> wrote:
>> > On Fri, Feb 12, 2010 at 08:52:15AM +0530, Kailas Joshi wrote:
>> >> Sorry, I didn't understand why processes need to be suspended.
>> >> In my scheme, I am issuing magic handle only after locking the current
>> >> transaction.  AFAIK after the transaction is locked, it can receive the
>> >> block journaling requests for already created handles(in our case, for
>> >> already reserved journal space), and the new concurrent requests for
>> >> journal_start() will go to the new current transaction. Since, the
>> >> credits for locked transaction are fixed (by means of early
>> >> reservations) we can know whether journal has enough space for the new
>> >> journal_start(). So, as long as journal has enough space available,
>> >> new processes need now be stalled.
>> >
>> > But while you are modifying blocks that need to go into the journal
>> > via the locked (old) transaction, it's not safe to start a new
>> > transaction and start issuing handles against the new transaction.
>> >
>> > Just to give one example, suppose we need to update the extent
>> > allocation tree for an inode in the locked/committing transaction as
>> > the delayed allocation blocks are being resolved --- and in another
>> > process, that inode is getting truncated or unlinked, which also needs
>> > to modify the extent allocation tree?  Hilarty ensues, unless you use
>> > a block all attempts to create a new handle (practically speaking, by
>> > blocking all attempts to start a new transaction), until this new
>> > delayed allocation resolution phase which you have proposed is
>> > complete.
>> Okay. So, basically process stalling is unavoidable as we cannot
>> modify a buffer data in past transaction after it has been modified in
>> current transaction.
>> Can we restrict the scope for this blocking? Blocking on
>> journal_start() will block all processes even though they are
>> operating on mutually exclusive sets of metadata buffers. Can we
>> restrict this blocking to allocation/deallocation paths by blocking in
>> get_write_access() on specific cases(some condition on buffer)? This
>> way, since all files will use commit-time allocation, very few(sync
>> and direct-io mode) file operations will be stalled.
>  I doubt blocking at buffer-level would be enough. I think that the
> journalling layer just does not have enough information for such decisions.
> It could be feasible to block on per-inode basis but you'd still have to
> give a good thought to modification of filesystem global structures like
> bitmaps, superblock, or inode blocks.
Okay. So, blocking at buffer level will not be easy as global
structures shared among inodes will need modifications(for example,
changing access time for a file in inode block).

One last doubt, while looking at the code, I saw that journal_start()
always stalls all file operations while currently running transaction
is in LOCKED state. Only when the current transaction moves to FLUSH,
the new transaction is created and the stalled operations continue. Is
this interpretation correct?
If yes, why this stalling does not have significant negative impact on
performance of file operations? Also, if it does not have, will
stalling for delayed block allocation really have such significant
negative impact?

Please reply.

Thanks & Regards,
Kailas
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists