It would be nice to make the fop match the writesame() semantics (@buf, @len, @offset, @repeat) and just use it for zerofill as a specific use case, by providing a 1 byte buffer storing a 0, repeated @len times. Thoughts?
In the storage/bd layer, you can detect if the arguments are trying to zero-fill (by inspecting @buf) and conditionally call ioctl(BLKZEROOUT). This will prepare gluster for providing a more generic block layer interface (in the furtue, for iSCSI?) Avati On Sun, Jun 9, 2013 at 8:53 PM, Bharata B Rao <bharata....@gmail.com> wrote: > Hi, > > We are planning to add a new FOP to GlusterFS to exploit the WRITE > SAME capability of the underlying block device in case of BD xlator. > Linux has recently added support for WRITE SAME by means of a new > ioctl (BLKZEROOUT) that can be used to zero-out a range of blocks. We > are proposing the following FOP to support BLKZEROOUT ioctl in > GlusterFS: > > int zerofill(struct glfs_fd *glfd, off_t offset, size_t len) > > This will zero-out the range of the file represented by @glfd, > starting from @offset for @len bytes. > > Posix backend can implement the zerofill() in whatever way that is > convenient/efficient, all it has do is to write zeroes to the file in > the specified range. > > BD backend will issue ioctl(fd, BLKZEROOUT, params[2]) in response to > zerofill(glfd, offset, len). param[0] is the starting sector number > which should be derived from offset. param[1] is the nr_sectors which > should be derived from len. > > Regards, > Bharata. > -- > http://raobharata.wordpress.com/ > > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/gluster-devel >
_______________________________________________ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel
