Hi,

On Thu, Apr 17, 2008 at 12:35:28PM -0700, Amit Singh wrote:
> On Apr 17, 6:17 am, Forest Bond <[EMAIL PROTECTED]> wrote:
> > I know direct_io is frowned upon in the MacFUSE camp, but I was hoping to 
> > get
> 
> Whatever gave you that impression? And I don't know this "camp" that
> you speak of!

:)

Sorry, I was sure I remembered seeing some posts that indicated that direct_io
ought to be avoided, but I'm having a hard time finding them now.

> > some clarification as to whether or not mmap is disabled by using direct_io.
> >
> > (I think have to use direct_io, anyway, so this is not the only reason for
> > turning it on.)
> 
> A file system cannot "disable" mmap() on Mac OS X. However, when you
> use direct_io, mmap() will not work, as should be the case, but you
> won't get to know that it doesn't work until you try to read/write
> that memory--at that point, you'll get a fault. Unfortunate, but like
> I said, that's how it is on Mac OS X. Without changing the kernel
> itself, this can't be improved.

Ah, this is what I'm not entirely pleased with.  I'd like for mmap to simply
fail, rather than *almost* work.  Then, applications that try to detect whether
or not mmap is supported will be able to fall back on a reasonable substitute if
mmap is unavailable.

(This can lead to file corruption in cases where the application hasn't been
coded very carefully, too.)

Currently, I see SIGBUS in the one application that I've tested when it tries to
use mmap.  SIGBUS can't be catched, so the app just gets killed.  It's not
perfect, but I'm not sure how to deal with it.

> > I'm using MacPorts to install dependencies, but I have replaced the MacPorts
> > fusefs-1.1 port with a fusefs-1.3 port (I modified the port file and created
> > a new tarball).  However, I noticed that MacPorts has libfuse
> > fromhttp://fuse.sourceforge.net, rather than installing libfuse from
> > MacFUSE.  Could this be contributing to the issues that I am seeing?
> 
> I am not very familiar with what MacPorts is doing. It's also odd and
> incorrect if they call it a "fusefs port". MacFUSE != Linux FUSE. The kext is
> a completely different implementation from Linux fusefs; they just happen to
> export similar (not even same) user-level interfaces.  The kext's behavior,
> its nuances, subtleties, features, limitations are *very* different from Linux
> fusefs, and are often dictated by what's possible/impossible and needed/not
> needed on Mac OS X. "fusefs port" incorrectly implies otherwise. And libfuse
> != MacFUSE either.  MacFUSE consists of a kernel extension (fusefs.kext), a
> user-space library (libfuse.dylib), programming headers, and a bunch of
> support tools/scripts.
> 
> I don't know if this is contributing to any of your problems, but the only
> binary distribution I can support is the one I make available.

Understood.  I think they are doing the right thing, although the package naming
is a bit strange.  I'm not that familiar with MacPorts, so it was a little
confusing for me at first.

-Forest
-- 
Forest Bond
http://www.alittletooquiet.net
http://www.pytagsfs.org

Attachment: signature.asc
Description: Digital signature

Reply via email to