Re: new caching behavior in 10.8?
Re: new caching behavior in 10.8?
- Subject: Re: new caching behavior in 10.8?
- From: Mike Shal <email@hidden>
- Date: Fri, 04 Jan 2013 09:54:45 -0500
On Fri, Dec 14, 2012 at 5:35 PM, Mike Shal <email@hidden> wrote:
> Hello,
>
> I am trying to use FUSE in OSX 10.8 (currently Fuse4x, though I see
> the same behavior in OSXFUSE). I posted this in the OSXFUSE mailing
> list as well, but maybe someone here has an idea. Basically I am
> seeing what I think is some new caching behavior in 10.8 that wasn't
> present in 10.7 and earlier. As a test I am using fusexmp.c, which is
> just a loopback filesystem that comes with fuse (attached).
>
> In 10.7, I can do the following:
>
> (terminal A) ./fusexmp -d tmp
> (terminal B) cd tmp/Users/me/
> (terminal B) gcc ok.c
> (terminal B) cd /Users/me
> (terminal B) ./a.out
> Hello!
>
> Where /Users/me/ok.c contains:
> #include <stdio.h>
>
> int main(void)
> {
> printf("Hello!\n");
> return 0;
> }
>
> The debug in terminal A from FUSE shows that the WRITE occurs before
> the gcc command returns to the shell:
>
> mknod /Users/marf/a.out 0100755 0x0 umask=0135000
> getattr /Users/marf/a.out
> NODEID: 31
> unique: 1, success, outsize: 160
> unique: 2, opcode: LOOKUP (1), nodeid: 29, insize: 48
> LOOKUP /Users/marf/._a.out
> getattr /Users/marf/._a.out
> unique: 2, error: -2 (No such file or directory), outsize: 16
> unique: 0, opcode: GETATTR (3), nodeid: 31, insize: 56
> getattr /Users/marf/a.out
> unique: 0, success, outsize: 136
> unique: 1, opcode: OPEN (14), nodeid: 31, insize: 48
> open flags: 0x1 /Users/marf/a.out
> open[0] flags: 0x1 /Users/marf/a.out
> unique: 1, success, outsize: 32
> unique: 2, opcode: WRITE (16), nodeid: 31, insize: 8768
> write[0] 8688 bytes to 0 flags: 0x0
> write[0] 8688 bytes to 0
> unique: 2, success, outsize: 24
>
> However, repeating the same test (same fusexmp.c, ok.c, and Fuse4X
> 0.9.2) in 10.8 shows:
>
> ...
> (terminal B) ./a.out
> -bash: ./a.out: cannot execute binary file
>
> This is strange, since the gcc process has long since quit. Using od shows:
>
> $ od -t x1 a.out
> 0000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> *
> 0021060
>
> In contrast to 10.7 where I see the WRITE call during the gcc process,
> in 10.8 I don't see the WRITE call until the unmount:
>
> unique: 5, opcode: OPEN (14), nodeid: 29, insize: 48
> open flags: 0x2 /Users/marf/a.out
> open[0] flags: 0x2 /Users/marf/a.out
> unique: 5, success, outsize: 32
> unique: 0, opcode: WRITE (16), nodeid: 29, insize: 8832
> write[0] 8752 bytes to 0 flags: 0x0
> write[0] 8752 bytes to 0
> unique: 0, success, outsize: 24
>
> Note that I *can* run ./a.out inside the FUSE fs, but not in the fs
> where it was actually written. I can only run it in the real fs after
> unmounting FUSE. Anyone know what might have changed in 10.8 to cause
> this? Is there a mount option or something I can pass in when creating
> the FUSE fs to disable this behavior?
>
> In my actual program I synchronize several separate processes to run
> in different virtual directories that all map to the same underlying
> filesystem. One process may write to a file (like a.out here), and
> another process tries to read from it using a different path. This
> works in 10.7 (as well as Linux), but not in 10.8.
>
> Thanks,
> -Mike
Hey all,
Anyone have any ideas here? Is there a new caching behavior or
something in 10.8 that would cause files written through FUSE to not
actually go to the backing filesystem until FUSE is unmounted? And is
there a way to disable that (with a mount option, perhaps?)
Thanks,
-Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden