[9fans] Fwd: Reading from FS with inaccurate file sizes? - Plan9

This is a discussion on [9fans] Fwd: Reading from FS with inaccurate file sizes? - Plan9 ; I started a conversation with Amit Singh on the MacFUSE website about the problems I was having with zero-sized files, and he brought up this point. I have neither a Linux nor a FreeBSD system to try this on, but ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: [9fans] Fwd: Reading from FS with inaccurate file sizes?

  1. [9fans] Fwd: Reading from FS with inaccurate file sizes?

    I started a conversation with Amit Singh on the MacFUSE website about
    the problems I was having with zero-sized files, and he brought up
    this point. I have neither a Linux nor a FreeBSD system to try this
    on, but I know some people on this list have used 9pfuse on those
    systems in the past.

    Can someone use 9pfuse -D and try out this test?

    That is:

    prompt # plumber
    prompt # 9pfuse -D `namespace`/plumb /mnt/plumb
    prompt # wc /mnt/plumb/rules # verify output is correct (and file non-
    empty)
    prompt # cat new_rule.txt >> /mnt/plumb/rules # what does the 9pfuse
    debug output show here, specifically for the offset of the write?


    ---------- Forwarded message ----------
    From: "Amit Singh"
    Date: Mar 23, 11:33 am
    Subject: Reading from FS with inaccurate file sizes?
    To: macfuse-devel


    > prompt # cat new_rule.txt >> /mnt/plumb/rules # add a rule


    When you do this on Linux for a file with an advertised size of 0,
    what offset do you get in the write call in your user-space file
    system daemon?


  2. Re: [9fans] Fwd: Reading from FS with inaccurate file sizes?

    When you cat >> file and file has zero length in stat,
    then the write happens at an offset of zero.
    This is perhaps the only time that the stat size should
    be used for a purpose other than returning from stat.

    Synthetic file systems tend not to care about the
    offset on writes anyway.

    There is another difference between > and >> on Plan 9:
    when the shell opens with > it includes OTRUNC;
    when it opens with >> it does not.
    This is enough of a hint for file systems that care.

    On Linux apparently things happen the other way around:
    O_TRUNC is never sent, but O_APPEND is sent for >> opens.
    MacFUSE doesn't send either, which is another bug I've filed:
    http://code.google.com/p/macfuse/issues/detail?id=132

    MacFUSE also seems to employ some subterfuge where fds
    do not map one-to-one with FUSE file handles. Another bug I've filed:
    http://code.google.com/p/macfuse/issues/detail?id=133

    To be fair, these are the kinds of mistakes I would expect any
    Unix-mindset implementation to make, and it surprised me quite
    a bit that Linux FUSE got so much of this right from the start
    (or at least from when I started using it). I wonder how many
    of these mistakes BSD FUSE makes.

    Russ

  3. Re: Fwd: Reading from FS with inaccurate file sizes?

    On Mar 27, 6:20 am, r...@swtch.com (Russ Cox) wrote:
    > To be fair, these are the kinds of mistakes I would expect any
    > Unix-mindset implementation to make, and it surprised me quite
    > a bit that Linux FUSE got so much of this right from the start
    > (or at least from when I started using it). I wonder how many
    > of these mistakes BSD FUSE makes.


    You're assuming quite a bit here, especially in concluding that these
    are "mistakes" that you "expect" because of a "Unix-mindset"
    implementation.

    BTW, I don't know when you started using FUSE on Linux, but it's been
    there on Linux at least since 2001. MacFUSE came out in 2007, so your
    surprise is surprising.

    > Synthetic file systems tend not to care about the
    > offset on writes anyway.


    And the Mac OS X VFS kernel extension environment isn't exactly geared
    towards synthetic file systems. OS X may have an open source kernel,
    *but* it's not practical to write kernel extensions that require
    kernel changes. Therefore, things a kernel extension can do is limited
    by the interfaces/data that are available to the extension in a stock
    kernel. In the case of reads/writes when the advertised size is 0, you
    run into the unified buffer cache, which really wants to believe the
    file size. To get around this, MacFUSE must explicitly implement
    separate read/write paths from the vnode operations to user-space and
    back. Release 0.2.2 does this for reads if you use the 'direct_io'
    option. In other words, if you add the 'direct_io' option while
    mounting, what you are looking for should already work. Note that you
    will have no buffer cache (which is what you'd want anyway in this
    case).

    'direct_io' doesn't do anything for writes in Release 0.2.2. It'd be
    straightforward to expand the write implementation. A future release
    of MacFUSE might have it.

    > MacFUSE also seems to employ somesubterfuge where fds
    > do not map one-to-one with FUSE file handles. Another bug I've filed:http://code.google.com/p/macfuse/issues/detail?id=133


    The subterfuge is intentional and necessary in the current design. The
    open() and close() vnode operations of MacFUSE *do not* have access to
    the file descriptor in question. The data structures involved are
    opaque, so it'd be quite ugly and unmaintainable to try to get at the
    descriptor by brute force. Given the lack of descriptor, you can't
    match opens and closes. Along the same lines, MacFUSE only can look at
    the vnode, and *not* at file structures, which are inaccessible. You
    can't track connections between file structures and FUSE file handles.
    Therefore, as a matter of feasibility and simplicity, MacFUSE shares
    file handles when possible, with reference counting. For multiple
    opens of a single given file, you won't see every open invocation go
    up to user space unless the open flags are different from a previous
    invocation.

    > On Linux apparently things happen the other way around:
    > O_TRUNC is never sent, but O_APPEND is sent for >> opens.
    > MacFUSE doesn't send either, which is another bug I've filed:http://code.google.com/p/macfuse/issues/detail?id=132
    >


    Right now, MacFUSE distinguishes between 3 types of open for a given
    file: O_RDONLY, O_WRONLY, and O_RDWR. Since write handles could be
    shared, adding O_APPEND to the mix means we essentially have two
    additional types of open that MacFUSE must track. This isn't too big
    of a deal eventually, but the extra complexity wasn't justified in
    MacFUSE's nascent days, even though it meant sacrificing some arguably
    contrived semantics. I say contrived because O_APPEND is still handled
    correctly by the kernel (if you report the correct file size)--it's
    just that the flag is not passed to user space. So, like you said in
    your bug report, this matters in cases like "shared append-only files
    on the server side".

    Hope this clarifies things.

  4. Re: Fwd: Reading from FS with inaccurate file sizes?

    If it's an issue for people, sign in to code.google.com and mark/star
    it to hopefully convence the MacFUSE team that it's an important thing
    to address. Otherwise it will just be pushed to the bottom of the
    stack or flushed as not an issue.

    On Mar 27, 8:20 am, r...@swtch.com (Russ Cox) wrote:
    ....
    > To be fair, these are the kinds of mistakes I would expect any
    > Unix-mindset implementation to make, and it surprised me quite
    > a bit that Linux FUSE got so much of this right from the start
    > (or at least from when I started using it). I wonder how many
    > of these mistakes BSD FUSE makes.


  5. Re: [9fans] Re: Fwd: Reading from FS with inaccurate file sizes?

    >And the Mac OS X VFS kernel extension environment isn't exactly geared
    >towards synthetic file systems. ...


    as far as i know, hardly any of them are. that's the `unix mindset'!

  6. Re: [9fans] Re: Fwd: Reading from FS with inaccurate file sizes?

    > BTW, I don't know when you started using FUSE on Linux, but it's been
    > there on Linux at least since 2001. MacFUSE came out in 2007, so your
    > surprise is surprising.


    9P has been around for 20 years, what I find surprising is why anyone
    would bother with FUSE.


    > The subterfuge is intentional and necessary in the current design. The
    > open() and close() vnode operations of MacFUSE *do not* have access to
    > the file descriptor in question. The data structures involved are
    > opaque, so it'd be quite ugly and unmaintainable to try to get at the
    > descriptor by brute force. Given the lack of descriptor, you can't
    > match opens and closes. Along the same lines, MacFUSE only can look at
    > the vnode, and *not* at file structures, which are inaccessible. You
    > can't track connections between file structures and FUSE file handles.
    > Therefore, as a matter of feasibility and simplicity, MacFUSE shares
    > file handles when possible, with reference counting. For multiple
    > opens of a single given file, you won't see every open invocation go
    > up to user space unless the open flags are different from a previous
    > invocation.


    The more I learn about FUSE, the more broken by design it seems. What
    is the point of userspace file systems if they can't even handle
    open() and close() in any meaningful way?

    Ah, the eternal re-invention of square wheels. How infinitely sad *sigh*

    uriel

  7. Re: Fwd: Reading from FS with inaccurate file sizes?

    On Mar 29, 2:26 am, fors...@terzarima.net (Charles Forsyth) wrote:
    > >And the Mac OS X VFS kernel extension environment isn't exactly geared
    > >towards synthetic file systems. ...

    >
    > as far as i know, hardly any of them are. that's the `unix mindset'!


    First off, as much as I find synthetic file systems to be useful, I
    don't have a major problem with the Unix mindset.

    The way I read the post to which I replied earlier, "mistakes made
    because of a Unix mindset" was referring to the MacFUSE
    implementation, not Mac OS X itself.

    Remember that Mac OS X doesn't even have a proc file system. Its
    architecture is also quite stringent about what third parties can do
    in the kernel. Therefore, it "isn't exactly geared" even more than
    other common Unix-like systems.

  8. Re: Fwd: Reading from FS with inaccurate file sizes?

    On Mar 29, 2:55 am, urie...@gmail.com (Uriel) wrote:
    > The more I learn about FUSE, the more broken by design it seems. What
    > is the point of userspace file systems if they can't even handle
    > open() and close() in any meaningful way?
    >
    > Ah, the eternal re-invention of square wheels. How infinitely sad *sigh*


    MacFUSE (http://code.google.com/p/macfuse) is an implementation of the
    FUSE API (http://fuse.sourceforge.net) for Mac OS X. You seem to imply
    I was explaining *the FUSE design*--no, I was talking about MacFUSE's
    departure from the FUSE/Linux behavior because of the underlying OS
    differences.

    As for eternal reinvention, that's hardly limited to userspace file
    systems, or even software. No, the ubiquity of reinvention doesn't
    justify reinvention, but I don't really find it infinitely sad--some
    instances of (re)invention just don't succeed the way others might.
    What *is* sad (well, disappointing rather than sad) is when people are
    ultra-quick in jumping to apparently confident conclusions, especially
    when they might not have the necessary context. That's the sole reason
    I posted here to begin with: to provide some context so those
    interested can understand why something is the way it is, rather than
    concluding based on presumptions and stereotypes.

  9. Re: [9fans] Re: Fwd: Reading from FS with inaccurate file sizes?

    On 3/29/07, Amit Singh wrote:

    > What *is* sad (well, disappointing rather than sad) is when people are
    > ultra-quick in jumping to apparently confident conclusions, especially
    > when they might not have the necessary context. That's the sole reason
    > I posted here to begin with: to provide some context so those
    > interested can understand why something is the way it is, rather than
    > concluding based on presumptions and stereotypes.


    For what it's worth, thanks for posting. As the original poster, I appreciate the time you put in to making the project in the first place.

    Are patches welcome? If so, I might work on the two "easy" ones: direct_io for writes and O_APPEND.

    I need to reread the part of the post about duplicate FDs and such.

    Thanks again;
    Colin DeVilbiss

  10. Re: Fwd: Reading from FS with inaccurate file sizes?

    On Mar 29, 6:40 am, cdevilb...@gmail.com (Colin DeVilbiss) wrote:
    > Are patches welcome? If so, I might work on the two "easy" ones: direct_io for writes and O_APPEND.


    Patches are welcome. direct_io for writes is already included in the
    next release, so don't bother with that. Feel free to give O_APPEND a
    shot, though I might look at it when I get a chance. If you do, it'd
    be more appropriate to discuss things on the macfuse-devel mailing
    list.

    > I need to reread the part of the post about duplicate FDs and such.


    One-to-one mapping of file descriptors to FUSE file handles is not a
    matter of hard-to-implement or not-yet-implemented functionality. It's
    not feasible given the current kernel.

+ Reply to Thread