Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752947Ab2K2GxR (ORCPT ); Thu, 29 Nov 2012 01:53:17 -0500 Received: from smtp5-g21.free.fr ([212.27.42.5]:37448 "EHLO smtp5-g21.free.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751039Ab2K2GxQ (ORCPT ); Thu, 29 Nov 2012 01:53:16 -0500 From: Jim Meyering To: Jeff Liu Cc: Hugh Dickins , Jaegeuk Hanse , Andrew Morton , "Theodore Ts'o" , Zheng Liu , Paul Eggert , Christoph Hellwig , Josef Bacik , Andi Kleen , Andreas Dilger , Dave Chinner , Marco Stornelli , Chris Mason , Sunil Mushran , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] tmpfs: support SEEK_DATA and SEEK_HOLE (reprise) In-Reply-To: <50B6E7CB.1040504@oracle.com> (Jeff Liu's message of "Thu, 29 Nov 2012 12:42:51 +0800") References: <20121129012933.GA9112@kernel> <87lidlxcw9.fsf@rho.meyering.net> <50B6E7CB.1040504@oracle.com> Date: Thu, 29 Nov 2012 07:53:06 +0100 Message-ID: <87d2yw3not.fsf@rho.meyering.net> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2071 Lines: 40 Jeff Liu wrote: > On 11/29/2012 12:15 PM, Jim Meyering wrote: >> Hugh Dickins wrote: >>> On Thu, 29 Nov 2012, Jaegeuk Hanse wrote: >> ... >>>> But this time in which scenario will use it? >>> >>> I was not very convinced by the grep argument from Jim and Paul: >>> that seemed to be grep holding on to a no-arbitrary-limits dogma, >>> at the expense of its users, causing an absurd line-length issue, >>> which use of SEEK_DATA happens to avoid in some cases. >>> >>> The cp of sparse files from Jeff and Dave was more convincing; >>> but I still didn't see why little old tmpfs needed to be ahead >>> of the pack. >>> >>> But at LinuxCon/Plumbers in San Diego in August, a more convincing >>> case was made: I was hoping you would not ask, because I did not take >>> notes, and cannot pass on the details - was it rpm building on tmpfs? >>> I was convinced enough to promise support on tmpfs when support on >>> ext4 goes in. >> >> Re the cp-vs-sparse-file case, the current FIEMAP-based code in GNU >> cp is ugly and complicated enough that until recently it harbored a >> hard-to-reproduce data-corrupting bug[*]. Now that SEEK_DATA/SEEK_HOLE >> support work will work also for tmpfs and ext4, we can plan to remove >> the FIEMAP-based code in favor of a simpler SEEK_DATA/SEEK_HOLE-based >> implementation. > How do we teach du(1) to aware of the real disk footprint with Btrfs > clone or OCFS2 reflinked files if we remove the FIEMAP-based code? > > How about if we still keep it there, and introduce SEEK_DATA/SEEK_HOLE > code to the extent-scan module which is dedicated to deal with sparse files? Hi Jeff, By "removing the FIEMAP-based code" I mean the uses in copy.c. All of that should remain independent of how du does its job, so if FIEMAP is required for your planned du enhancement, then feel free to use it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/