On Wed, Jul 01, 2015 at 07:15:12PM +0200, Xavier Hernandez wrote: > 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/ Thanks! > 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. Ok, yes, that makes sense. We will likely have SEEK as an operation in NFS-Ganesha at one point, and that will use the handle-based gfapi functions. > 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. I'm not sure if I understand what you mean, but that likely has to do that I dont know much about ec. I'll try to think it through later this week. I've rebased your change and put it in the order with the other wip/SEEK_HOLE topic patches. Modifications to any of those patches can best be done like this: $ git review -r origin -d 11474 $ vim ..../the/file.c $ git commit ... $ git rebase -i ... $ git review -r origin -t wip/SEEK_HOLE Note that this is prone to race conditions in the case where different devs do the steps at the same time... I can sort out problems in case they arrive (not expected to see much concurrent movement though). Thanks, Niele _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
