xfs
[Top] [All Lists]

Re: SEEK_DATA/SEEK_HOLE support

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: SEEK_DATA/SEEK_HOLE support
From: Jeff Liu <jeff.liu@xxxxxxxxxx>
Date: Mon, 03 Oct 2011 12:04:11 +0800
Cc: xfs@xxxxxxxxxxx
In-reply-to: <20111002175902.GA9420@xxxxxxxxxxxxx>
Organization: Oracle
References: <4E887D7F.2010306@xxxxxxxxxx> <20111002154259.GA14543@xxxxxxxxxxxxx> <4E888C0D.9060701@xxxxxxxxxx> <20111002175902.GA9420@xxxxxxxxxxxxx>
Reply-to: jeff.liu@xxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11
On 10/03/2011 01:59 AM, Christoph Hellwig wrote:

> On Mon, Oct 03, 2011 at 12:06:37AM +0800, Jeff Liu wrote:
>> IMHO, to avoid data loss in some user application like cp(1), for
>> unwritten extents, we always need to check the pages status.  Just as
>> you mentioned above, return the map offset if pages are dirty for
>> SEEK_DATA, or a hole found.
> 
> I'd suggest to first implement the simple versions I schemed below,
> which would treat unwritten extents as data.  That is sub-optimal,
> but a) safe and b) easy to implement.  The second step would be to
> add probing for unwritten extents, which is even something we could
> do as a common helper routine shared by filesystems.

So I'll wait for Dave's patch become ready, and then continue to improve
it if necessary.
In the meantime, I'll try to figure out how to add a helper which can be
shared by all file systems for UNWRITTEN extents.

> 
> And the most important thing is of course adding QA for it.  Josef
> already wrote an xfstests case that needs to be resurrected, compared
> against the latest Posix draft and if nessecary updated.




Thanks,
-Jeff

<Prev in Thread] Current Thread [Next in Thread>