On Wed, 27 Mar 2013, Theodore Ts'o wrote: > Date: Wed, 27 Mar 2013 08:36:51 -0400 > From: Theodore Ts'o <tytso@xxxxxxx> > To: Lukáš Czerner <lczerner@xxxxxxxxxx> > Cc: Ext4 Developers List <linux-ext4@xxxxxxxxxxxxxxx> > 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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html >
