<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Nov 16, 2013 at 4:45 PM, Emmanuel Dreyfus <span dir="ltr"><<a href="mailto:manu@netbsd.org" target="_blank">manu@netbsd.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">Anand Avati <<a href="mailto:avati@gluster.org">avati@gluster.org</a>> wrote:<br>
<br>
> If you call fallocate() over an existing region with data it shouldn't be<br>
> wiped with 0s. You can also call fallocate() on a hole (in case file was<br>
> ftruncate()ed to a large size) and that region should get "allocated" (i.e<br>
> future write to an fallocated() region should NOT fail with ENOSPC).<br>
<br>
</div>It seems it can be emulated, should it be atomic?</blockquote><div><br></div><div>I am not aware of any app which depends on it being atomic (though Linux implementations probably are)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
> BTW, does NetBSD have the equivalent of open_by_handle[_at]() and<br>
> name_to_handle[_at]() system calls?<br>
<br>
</div>That is extended API set 2. With the exception of fexecve(2), I<br>
implemented them in NetBSD-current, which means they will be available<br>
in NetBSD-7.0. Are they also mandatory in glusterfs-3.5? Is they are,<br>
then emulating fallocate() in userland is useless, I would better work<br>
on it in kernel for the next release.</blockquote><div><br></div><div>Oh that's interesting, can I get pointers to see how NetBSD implements open_by_handle() and name_to_handle()?</div><div><br></div><div>Thanks,</div>
<div>Avati</div><div><br></div></div></div></div>