Re: [PATCH 5/7] ext4: refactor truncate code

["Lukáš Czerner" <lczerner@redhat.com>]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2384 bytes --]

On Wed, 27 Mar 2013, Theodore Ts'o wrote:

> Date: Wed, 27 Mar 2013 08:36:51 -0400
> From: Theodore Ts'o <tytso@mit.edu>
> To: Lukáš Czerner <lczerner@redhat.com>
> Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>
> Subject: Re: [PATCH 5/7] ext4: refactor truncate code
> 
> On Wed, Mar 27, 2013 at 11:53:42AM +0100, Lukáš Czerner wrote:
> > > +	up_write(&ei->i_data_sem);
> > 
> > In ext_truncate we used to unlock it after the ext4_handle_sync(),
> > however in ind_truncate we used to unlock it before the
> > ext4_handle_sync(). Which one is correct ? I guess it does not have
> > to be done under the i_data_sem, so maybe we can move it outside the
> > semaphore in the punch_hole code as well ?
> 
> Yes, we can move this outside of the semaphore protected code.  Given
> that ext4_handle_sync() an inline function which sets a single memory
> location, my guess is that it didn't make a huge amount of difference,
> but it's better to keep the critical section as small as possible.
> I'll make that change.
> 
> 
> Hmm.... one thing I'm not sure about, now that I'm looking at this
> code.  We call ext4_discard_preallocations() twice; once before we
> remove the extent, and once afterwards.  I'm not sure why we're doing
> that.  It doesn't look to me like ext4_free_blocks() ever releases
> blocks back to the preallocation space.  Am I missing something, or
> could we eliminate one of the calls to ext4_discard_preallocations()?

I was wondering about that as well. There is a possibility of
allocation occurring in ext4_ext_remove_space() however it is only
metadata allocation and as such there should be no preallocation so
it seems to me that the second ext4_discard_preallocations() is
unnecessary. Note that it has been there from the introduction of
punch hole.

However let's take it one step further. What about the first call of
ext4_discard_preallocations() is this entirely necessary for a punch
hole ? I am wondering whether we can optimize things by dropping the
preallocation only within the hole we're punching, or possibly only
when we punch a hole at the end, or past the end of the file.

-Lukas

> 
>       	 	       	      	       - Ted
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>