[Gluster-devel] Progress on adding support for SEEK_DATA and SEEK_HOLE

[Xavier Hernandez]

On 07/01/2015 08:53 AM, Niels de Vos wrote:
> On Tue, Jun 30, 2015 at 11:48:20PM +0530, Ravishankar N wrote:
>>
>>
>> On 06/22/2015 03:22 PM, Ravishankar N wrote:
>>>
>>>
>>> On 06/22/2015 01:41 PM, Miklos Szeredi wrote:
>>>> On Sun, Jun 21, 2015 at 6:20 PM, Niels de Vos <ndevos at redhat.com> wrote:
>>>>> Hi,
>>>>>
>>>>> it seems that there could be a reasonable benefit for virtual machine
>>>>> images on a FUSE mountpoint when SEEK_DATA and SEEK_HOLE would be
>>>>> available. At the moment, FUSE does not pass lseek() on to the
>>>>> userspace
>>>>> process that handles the I/O.
>>>>>
>>>>> Other filesystems that do not (need to) track the position in the
>>>>> file-descriptor are starting to support SEEK_DATA/HOLE. One example is
>>>>> NFS:
>>>>>
>>>>> https://tools.ietf.org/html/draft-ietf-nfsv4-minorversion2-38#section-15.11
>>>>>
>>>>> I would like to add this feature to Gluster, and am wondering if there
>>>>> are any reasons why it should/could not be added to FUSE.
>>>> I don't see any reason why it couldn't be added.  Please go ahead.
>>>
>>> Thanks for bouncing the mail to me Niels, I would be happy to work on
>>> this. I'll submit a patch by Monday next.
>>>
>>
>>
>> Sent a patch @
>> http://thread.gmane.org/gmane.comp.file-systems.fuse.devel/14752
>> I've tested it with some skeleton code in gluster-fuse to handle lseek().
>
> Ravi also sent his patch for glusterfs-fuse:
>
>    http://review.gluster.org/11474
>
> I have posted my COMPLETELY UNTESTED patches to their own Gerrit topic
> so that we can easily track the progress:
>
>    http://review.gluster.org/#/q/status:open+project:glusterfs+branch:master+topic:wip/SEEK_HOLE
>
> My preference goes to share things early and make everyone able to
> follow progress (know where to find the latest patches). Assistance in
> testing, reviewing and improving is welcome! There are some outstanding
> things like seek() for ec and sharding, and probably more.
>
> This all was done as a suggestion from Christopher (kripper) Pereira,
> for improving the handling of sparse files (like most VM images).

I've posted the patch for ec in the same Gerrit topic:

     http://review.gluster.org/11494/

It has not been tested and some discussion about if it's really needed 
to send the request to all subvolumes will be needed.

The lock and the xattrop are absolutely needed. Even if we send the 
request to only one subvolume, we need to know which ones are healthy 
(to avoid sending the request to a brick that could have invalid hole 
information). This could have been done in open, but since NFS does not 
issue open calls, we cannot rely on that.

Once we know which bricks are healthy we could opt for sending the 
request only to one of them. In this case we need to be aware that even 
healthy bricks could have different hole locations.

What do you think ?

Xavi