On 11/17/2013 02:59 PM, Emmanuel Dreyfus wrote:
Anand Avati <av...@gluster.org> wrote:
If you call fallocate() over an existing region with data it shouldn't be
wiped with 0s. You can also call fallocate() on a hole (in case file was
ftruncate()ed to a large size) and that region should get "allocated" (i.e
future write to an fallocated() region should NOT fail with ENOSPC).
fallocate stuff appears both in fuse and posix xlators. I understand the
fuse one is only used if the kernel sends a FALLOCATE FUSE FOP, which
means I can just #ifndef __NetBSD__ it our, since the NetBSD kernel has
no fallocate() system call, and will never issue that FOP. Am I right?
Yes, that would be right.
Wild guess: the FALLOCATE FOP is tunnelled thorugh all glusterfs
xlators, and not supporting it in the posix xlator would mean a NetBSD
brick would not be able to honour requests from a Linux client using
that FOP. Am I right?
Right again.
On a different note, would it be easier if a NetBSD build was triggered
for every commit through Jenkins? That way, we might realise build
issues on NetBSD automatically. Do you happen to know if a jenkins slave
agent can be setup on NetBSD 6?
-Vijay
_______________________________________________
Gluster-devel mailing list
Gluster-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/gluster-devel
