Anand Avati <avati@xxxxxxxxxxx> 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? > 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. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu@xxxxxxxxxx