Re: Help on Implementation of EXT3 type Ordered Mode in EXT4

[Jan Kara <jack@suse.cz>]

  Hi,

On Fri 19-03-10 08:53:08, Kailas Joshi wrote:
> I am facing some problems while implementing alloc_on_commit.
> While performing exhaustive write operations(for example using postmark),
> system locks up after some time.
> It runs fine for (simple)non-exhaustive write operations.
> 
> I am using filemap_write_and_wait() in journal commit callback for
> performing synchronous block allocation. It uses special journal handle
> which enables use of early reservations.
> Is it right to use this function here? If no, is there any other alternative
> that should be used in this scenario?
> 
> I am using following strategy -
> 1) ext4_da_get_block_prep() marks delayed-allocation buffers with BH_DA
> after reserving space for them.
  We have a BH_Delay flag for this already. OK, probably you need a
temporary flag which you can clear in ext4_da_write_begin. I'd find
counting number of BH_Delay buffers before and after block_write_begin
call nicer...

> 2) ext4_da_write_begin() counts the number of buffers marked with BH_DA and
> reserves credits for block allocation.
> 3) journal_stop() accumulates the unused credits of a handle in the
> transaction.
> 4) journal_start() when called with nblocks=0, creates a special handle with
> the credits accumulated by all previous handles(by step 2).
  This is a hack. I'd rather create a separate JBD2 function for this.

> 5) journal_commit() creates special handle for block allocation(as in step
> 4) and calls filemap_write_and_wait() to perform block allocation.
> 
> I am also sending the patch(for kernel 2.6.32.4) for my implementation (also
> available at
> http://www.cse.iitb.ac.in/~kailasjoshi/files/alloc_on_commit.patch).
> 
> Being new to filesystem development, I am not able to identify the problem.
> I will be very greatful if someone can help me out.
  Probably you are hitting some lock inversion problem. I suggest you
compile the kernel with lockdep enabled (in Kernel hacking -> Lock debugging
-> Prove lock correctness or something like that) and see whether it issues
some warnings. If not, you can get backtraces of the locked up processes
by pressing Alt-Sysrq-w (or echo "w" >/proc/sysrq-trigger).

									Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR