From: Miklos S. <mi...@sz...> - 2011-09-09 20:43:49
|
On Fri, Sep 9, 2011 at 7:44 PM, Han-Wen Nienhuys <ha...@gm...> wrote: > On Fri, Sep 9, 2011 at 7:46 AM, Miklos Szeredi <mi...@sz...> wrote: >>> Apparently, the program is assuming that fallocate will create space >>> for it to write to through the mmap. It doesn't fall back to something >>> else, and the write to the mmapped address fails with sigbus. >> >> Very few filesystems currently implement fallocate, so fuse is probably >> not the only fs that this aplicateion will fail with. > > It's a version of GNU ld. The failure surprised me as well, but maybe > they use configure time checks to decide what to do here. Interesting. Ext3 doesn't have fallocate, for example, but ld obviously does work on ext3. So apparently ld decided that the fuse filesystem in question does support fallocate and didn't even check the return value. I guess this is a bug and should be reported... > >>> Has there ever been given thought to implementing (partial) support >>> for fallocate by issuing a SetAttr to the fuse daemon? If not, would >>> it be hard to implement? >> >> fallocate() is documented to be more than just a truncate(size). On >> successful return it will guarantee that writes to the allocated space >> will not fail with ENOSPC. truncate() will not guarantee that. >> >> Adding fallocate to the fuse API should be very easy. Patches are >> welcome, but I can implement it if nobody comes forward with patches. > > I'll have a look. Where can I find the canonical repo for the FUSE > kernel-side library? Is it Linus' tree? Yeah the kernel side is in Linus tree and the userspace side is on sourceforge. Thanks, Miklos |