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@xxxxxxxxxx> 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
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
