linux-kernel - Re: [PATCH] tmpfs: support SEEK_DATA and SEEK

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 29 Nov 2012 07:53:06 +0100
From:	Jim Meyering <jim@...ering.net>
To:	Jeff Liu <jeff.liu@...cle.com>
Cc:	Hugh Dickins <hughd@...gle.com>,
	Jaegeuk Hanse <jaegeuk.hanse@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Theodore Ts'o" <tytso@....edu>, Zheng Liu <wenqing.lz@...bao.com>,
	Paul Eggert <eggert@...ucla.edu>,
	Christoph Hellwig <hch@...radead.org>,
	Josef Bacik <josef@...hat.com>,
	Andi Kleen <andi@...stfloor.org>,
	Andreas Dilger <adilger@...ger.ca>,
	Dave Chinner <david@...morbit.com>,
	Marco Stornelli <marco.stornelli@...il.com>,
	Chris Mason <chris.mason@...ionio.com>,
	Sunil Mushran <sunil.mushran@...cle.com>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-mm@...ck.org
Subject: Re: [PATCH] tmpfs: support SEEK_DATA and SEEK_HOLE (reprise)

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/