From: Jim Meyering <jim@meyering.net>
To: Hugh Dickins <hughd@google.com>
Cc: Jaegeuk Hanse <jaegeuk.hanse@gmail.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        "Theodore Ts'o" <tytso@mit.edu>, Zheng Liu <wenqing.lz@taobao.com>,
        Jeff liu <jeff.liu@oracle.com>, Paul Eggert <eggert@cs.ucla.edu>,
        Christoph Hellwig <hch@infradead.org>, Josef Bacik <josef@redhat.com>,
        Andi Kleen <andi@firstfloor.org>, Andreas Dilger <adilger@dilger.ca>,
        Dave Chinner <david@fromorbit.com>,
        Marco Stornelli <marco.stornelli@gmail.com>,
        Chris Mason <chris.mason@fusionio.com>,
        Sunil Mushran <sunil.mushran@oracle.com>, 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: <alpine.LNX.2.00.1211281745200.1641@eggly.anvils> (Hugh Dickins's
	message of "Wed, 28 Nov 2012 18:02:21 -0800 (PST)")
References: <alpine.LNX.2.00.1211281706390.1516@eggly.anvils>
	<20121129012933.GA9112@kernel>
	<alpine.LNX.2.00.1211281745200.1641@eggly.anvils>
Date: Thu, 29 Nov 2012 05:15:50 +0100
Message-ID: <87lidlxcw9.fsf@rho.meyering.net>
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1684
Lines: 33

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.

With the rise of virtualization, copying sparse images efficiently
(probably searching, too) is becoming more and more important.

So, yes, GNU cp will soon use this feature.

[*] https://plus.google.com/u/0/114228401647637059102/posts/FDV3JEaYsKD
--
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/