On 06/09/2010 04:20 PM, Al Viro wrote: > On Wed, Jun 09, 2010 at 09:02:16AM -0400, Christoph Hellwig wrote: >> On Tue, Jun 08, 2010 at 11:16:02PM +0100, Al Viro wrote: >>> >>> Essentially, the minimal variant of ->evict_inode(). It's >>> a trimmed-down clear_inode(), sans any fs callbacks. Once >>> it returns we know that no async writeback will be happening; >>> every ->evict_inode() instance should do that once and do that >>> before doing anything ->write_inode() could interfere with >>> (e.g. freeing the on-disk inode). >> >> Naming seems a bit unfortunate - this really sounds like something >> in page writeback. In fact I'd almost bet we had a function with >> that name there in the past. >> >> Care to slap an inode_ prefix on it? > > Ehh... I'd been tempted to call it end_async or something like that. > I'm not particulary fond of the name; any better suggestions are welcome. > > The point of what's being done in that function is that it acts as a barrier; > "wait for async activity to run down; new one won't be started since it's > already marked I_FREEING". It was odd for me to. I had to go look at code to understand what it's for. I would prefer the word "wait" in the name or barrier. eg. wait_writeback. end_writeback sounds like something you should call from ->write_end Just my $0.017 Boaz -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
