All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mingming Cao <cmm@us.ibm.com>
To: Badari Pulavarty <pbadari@us.ibm.com>
Cc: ext2-devel <Ext2-devel@lists.sourceforge.net>,
	lkml <linux-kernel@vger.kernel.org>,
	akpm@osdl.org, sct@redhat.com, hch@lst.de
Subject: Re: [PATCH] ext3 getblocks() support for read
Date: Thu, 01 Dec 2005 16:59:18 -0800	[thread overview]
Message-ID: <438F9C66.6040209@us.ibm.com> (raw)
In-Reply-To: <1133368019.27824.55.camel@localhost.localdomain>

Badari Pulavarty wrote:
> Hi,
> 
> Here is the patch to support ext3 getblocks() for non allocation
> cases. (for reads & re-writes). This is useful with DIO reads,
> DIO re-writes and to go with Christoph's getblocks() for readpages()
> work.
> 
> Mingming is working on adding multiblock allocation support using
> reservation (which can be incrementally added later).
> 
> Comments ? 
> 

My ext3 multiple block allocation patch posted a while ago
includes the multiple blocks map as well. Looks mostly the same way you 
did here, but I like the way that how the # of mapped(or allocated) 
blocks are returned.

My plan is to break the whole ext3 multiple block allocation(also does 
map) patch into small patches, and re-send soon.

> @@ -681,9 +683,10 @@ ext3_get_block_handle(handle_t *handle, 
>  	Indirect *partial;
>  	unsigned long goal;
>  	int left;
> -	int boundary = 0;
> -	const int depth = ext3_block_to_path(inode, iblock, offsets, &boundary);
> +	int blks_boundary = 0;
> +	const int depth = ext3_block_to_path(inode, iblock, offsets, &blks_boundary);
>  	struct ext3_inode_info *ei = EXT3_I(inode);
> +	int count = 1;
>  
>  	J_ASSERT(handle != NULL || create == 0);
>  
> @@ -694,7 +697,18 @@ ext3_get_block_handle(handle_t *handle, 
>  
>  	/* Simplest case - block found, no allocation needed */
>  	if (!partial) {
> +		unsigned long first_block = le32_to_cpu(chain[depth-1].key);
> +
>  		clear_buffer_new(bh_result);
> +
> +		/*
> +		 * Find all the contiguous blocks and return at once.
> +		 */
> +		while (count < max_blocks && count <= blks_boundary &&
> +			(le32_to_cpu(*(chain[depth-1].p+count)) == 
> +				(first_block + count))) {
> +			count++;
> +		}
>  		goto got_it;
>  	}
> 
Here we need to be careful about the branch we just read, since we are 
looking up multiple blocks (they are on the same branch) at the same 
time, it is possible that during the look up, another threads is 
trucating the same branch we are trying to map.  Before since we are 
doing only one look up, a simple verify_chain() should be safe.

The simple way is, for the non-allocation case,  take the truncate_sem 
before the ext3_get_branch, like for the allocation-case, even for the 
simple case -- but that probably will slow down the non-allocation, 
probably a bad option.  But we could re-check(calling 
verify_chain())inside the while loop.


Mingming


  reply	other threads:[~2005-12-02  0:59 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-30 16:26 [PATCH] ext3 getblocks() support for read Badari Pulavarty
2005-12-02  0:59 ` Mingming Cao [this message]
2005-12-02  1:09   ` Badari Pulavarty

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=438F9C66.6040209@us.ibm.com \
    --to=cmm@us.ibm.com \
    --cc=Ext2-devel@lists.sourceforge.net \
    --cc=akpm@osdl.org \
    --cc=hch@lst.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbadari@us.ibm.com \
    --cc=sct@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.