[Top] [All Lists]

Re: [PATCH 1/4] fs: add SEEK_HOLE and SEEK_DATA flags

To: Marco Stornelli <marco.stornelli@xxxxxxxxx>
Subject: Re: [PATCH 1/4] fs: add SEEK_HOLE and SEEK_DATA flags
From: Greg Freemyer <greg.freemyer@xxxxxxxxx>
Date: Sat, 20 Aug 2011 13:18:37 -0400
Cc: linux-btrfs@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx, viro@xxxxxxxxxxxxxxxxxx, Josef Bacik <josef@xxxxxxxxxx>
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YuD+aTTLFuOJtppVphiTQcwgRN0+KdinlS/6YZaYzxE=; b=xlhsB2sOqQVDt/b9GjxiIpKNYvm0WHzc/Ab+aXdSLKx9YkheyslsKe6cZx86iOcHLa YDo1BDJSfvrRsA6oyWNSgI123EVbFTYYGknEUXRxc7kP4o23Ht4aBzo+m4TLLOT3Vs6G Kj5L9Kdb7Eszxd6egzb6LvJQhQaeLEGn7hsPY=
In-reply-to: <CAGpXXZ+xjhadprkc_LiP3qUypLLkCxdeEmo8+K+6mOnBuNhmLg@xxxxxxxxxxxxxx>
References: <1309275199-10801-1-git-send-email-josef@xxxxxxxxxx> <4E4F814B.5070202@xxxxxxxxx> <CAGpXXZ+xjhadprkc_LiP3qUypLLkCxdeEmo8+K+6mOnBuNhmLg@xxxxxxxxxxxxxx>

On Aug 20, 2011 5:52 AM, "Marco Stornelli" <marco.stornelli@xxxxxxxxx> wrote:
> Hi,
> Il 28/06/2011 17:33, Josef Bacik ha scritto:
>> This just gets us ready to support the SEEK_HOLE and SEEK_DATA flags.  Turns out
>> using fiemap in things like cp cause more problems than it solves, so lets try
>> and give userspace an interface that doesn't suck.  We need to match solaris
>> here, and the definitions are
>> *o* If /whence/ is SEEK_HOLE, the offset of the start of the
>> next hole greater than or equal to the supplied offset
>> is returned. The definition of a hole is provided near
>> the end of the DESCRIPTION.
>> *o* If /whence/ is SEEK_DATA, the file pointer is set to the
>> start of the next non-hole file region greater than or
>> equal to the supplied offset.
> I'm implementing the SEEK_DATA/SEEK_HOLE management for pramfs and I've got some doubts about the right behavior:
> 1) when we use SEEK_DATA/SEEK_HOLE, the offset used in lseek means always the offset from the start of the file, right?
> 2) in case of a file with hole at the beginning and data at the end, if I do lseek(fd, 0, SEEK_HOLE) I should receive the end of the file because the idea is to search the *next* hole and we have always a virtual hole at the end of the file, right?
> 3) about the last sentence of point 2), is it always true even if we have a case of block allocation beyond the end of file (fallocate with keep size option)?


You may want to enable the xfstests test(s) for SEEK_HOLE and SEEK_DATA for pramfs.  That should give you some confidence your implementing the api like other filesystems are.


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