linux-kernel - Re: [PATCH] xfstests 255: add a seek_data/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] [day] [month] [year] [list]

Date:	Wed, 31 Aug 2011 10:05:21 +0100
From:	Pádraig Brady <P@...igBrady.com>
To:	Sunil Mushran <sunil.mushran@...cle.com>
CC:	Dave Chinner <david@...morbit.com>,
	Andreas Dilger <adilger@...ger.ca>,
	Christoph Hellwig <hch@...radead.org>,
	Josef Bacik <josef@...hat.com>, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-btrfs@...r.kernel.org,
	xfs@....sgi.com, viro@...IV.linux.org.uk, dchinner@...hat.com
Subject: Re: [PATCH] xfstests 255: add a seek_data/seek_hole tester

On 08/31/2011 05:43 AM, Sunil Mushran wrote:
> On 8/30/2011 8:29 PM, Dave Chinner wrote:
>> And that's -exactly- the ambiguous, vague definition that has raised
>> all these questions in the first place. I was in doubt about whether
>> unwritten extents can be considered a hole, and by your definition
>> that means it should be data. But Andreas seems to be in no doubt it
>> should be considered a hole.
> 
> Fair enough. Let me rephrase.
> 
> Data:
> A range in a file when read could return something other than nulls.
> 
> Hole:
> A range in a file when read only returns nulls.
> 
> Considering preallocated extents only return null, they should
> be considered holes.

I would concur with this.
Treating preallocated extents as holes will allow them to be
processed quickly by `cp` etc.

What we lose is the ability to copy the allocation from src to dst.
But that's less important in comparison, and could probably be done
on a per file rather than per extent basis anyway.
Note preallocation would be good for disk layout and timely ENOSPC.

Note fiemap gives us greater control by distinguishing
holes and empty extents, thus allowing us to both
efficiently copy and maintain allocation.  But that
interface currently requires a sync of the file on some
file systems, which we couldn't enable for performance
reasons in cp.

cheers,
Pádraig.
--
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/