From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de ([195.135.220.15]:59611 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756858AbcJXLpm (ORCPT ); Mon, 24 Oct 2016 07:45:42 -0400 Date: Mon, 24 Oct 2016 13:45:40 +0200 From: Jan Kara To: Christoph Hellwig Cc: Jan Kara , Jens Axboe , linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org Subject: Re: [PATCH 1/4] fs: Provide function to unmap metadata for a range of blocks Message-ID: <20161024114540.GE1108@quack2.suse.cz> References: <1477050941-29682-1-git-send-email-jack@suse.cz> <1477050941-29682-2-git-send-email-jack@suse.cz> <20161021120542.GA20475@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161021120542.GA20475@infradead.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Fri 21-10-16 05:05:42, Christoph Hellwig wrote: > > + * Functionally, this is like unmap_underlying_metadata() for a range of > > + * blocks. It is implemented to be more efficient for larger ranges of blocks > > + * though. > > + */ > > +void unmap_underlying_metadata_ext(struct block_device *bdev, sector_t block, > > + sector_t len) > > Please explain what it does and why you'd call it. And while we're OK. > naming I think the 'metadata' part is highly confusing. What it does > is to clear buffers from the block device mapping, nothing about > metadata really. > > So how about unmap_buffers_range or similar? I can rename the function but I wanted to be consistent with unmap_underlying_metadata() function. It seems strange to have a function for a single block and a function for a range of blocks with very different names... Honza -- Jan Kara SUSE Labs, CR