On Sat, Nov 16, 2013 at 4:45 PM, Emmanuel Dreyfus <[email protected]> wrote:
> Anand Avati <[email protected]> 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). > > It seems it can be emulated, should it be atomic? I am not aware of any app which depends on it being atomic (though Linux implementations probably are) > > BTW, does NetBSD have the equivalent of open_by_handle[_at]() and > > name_to_handle[_at]() system calls? > > That is extended API set 2. With the exception of fexecve(2), I > implemented them in NetBSD-current, which means they will be available > in NetBSD-7.0. Are they also mandatory in glusterfs-3.5? Is they are, > then emulating fallocate() in userland is useless, I would better work > on it in kernel for the next release. Oh that's interesting, can I get pointers to see how NetBSD implements open_by_handle() and name_to_handle()? Thanks, Avati
_______________________________________________ Gluster-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/gluster-devel
