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

On 13 February 2010 01:37,  <tytso@....edu> wrote:
> On Fri, Feb 12, 2010 at 08:52:15AM +0530, Kailas Joshi wrote:
>> Won't this get fixed by performing early reservations as mentioned in
>> my scheme? We are reserving required credits in the path of write
>> system call and these will be kept reserved until transaction commit.
>> So, the journal space for allocation at commit will be guaranteed.
>
> Yes, if you account for these separately.  One challenge is
> over-estimating the needed credits will be tricky.  If we go down this
> path, be sure that the bonnie style write(fd, &ch, 1) in a tight loop
> doesn't end up reserving a separate set of credits for each write
> system call to the same block.  (It can be done; if the DA block is
> already instantiated, you can assume that credits have already been
> reserved.)
Okay

>> 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 am not sure whether this is feasible or not. Please let me know more on this.

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