linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Jim Meyering <jim@meyering.net>
To: Jeff Liu <jeff.liu@oracle.com>
Cc: Hugh Dickins <hughd@google.com>,
	Jaegeuk Hanse <jaegeuk.hanse@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Theodore Ts'o <tytso@mit.edu>, Zheng Liu <wenqing.lz@taobao.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)
Date: Thu, 29 Nov 2012 07:53:06 +0100	[thread overview]
Message-ID: <87d2yw3not.fsf@rho.meyering.net> (raw)
In-Reply-To: <50B6E7CB.1040504@oracle.com> (Jeff Liu's message of "Thu, 29 Nov 2012 12:42:51 +0800")

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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2012-11-29  6:53 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-29  1:22 Hugh Dickins
2012-11-29  1:29 ` Jaegeuk Hanse
2012-11-29  2:02   ` Hugh Dickins
2012-11-29  4:15     ` Jim Meyering
2012-11-29  4:42       ` Jeff Liu
2012-11-29  6:53         ` Jim Meyering [this message]
2012-11-29  7:27           ` Jeff Liu
2012-11-29 19:52       ` Dave Chinner
2012-11-29 20:17         ` Jim Meyering
2012-11-29  2:44 ` Dave Chinner
2012-11-29  4:22   ` Hugh Dickins
2012-11-29 22:59 ` Andrew Morton
2012-11-29 23:29   ` Hugh Dickins
2012-11-30  0:18     ` Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87d2yw3not.fsf@rho.meyering.net \
    --to=jim@meyering.net \
    --cc=adilger@dilger.ca \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=chris.mason@fusionio.com \
    --cc=david@fromorbit.com \
    --cc=eggert@cs.ucla.edu \
    --cc=hch@infradead.org \
    --cc=hughd@google.com \
    --cc=jaegeuk.hanse@gmail.com \
    --cc=jeff.liu@oracle.com \
    --cc=josef@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=marco.stornelli@gmail.com \
    --cc=sunil.mushran@oracle.com \
    --cc=tytso@mit.edu \
    --cc=wenqing.lz@taobao.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox