Which one is the version to use on Lion/64bit?

[Markus Stenberg]

I'm fairly heavy user of encfs, and finally upgraded to Lion my last two machines. As a side effect, I got encfs+fuse4x from MacPorts over the old versions I had been using on Snow Leopard. The 'port info' shows following versions:

encfs: 1.7.4

fuse4x: 0.9.1

Is this some non-stable version? I'm asking because I found some odd behavior, such as apparent deadlock (encfs process to zombie state, filesystem not unmountable, anything that touches it also hangs). 

Also, the inodes do not seem to be consistent anymore, unlike in the old encfs+macfuse combination. Even during a single mount, the inode numbers seem to change at times, which leads to odd behavior from some software such as Unison. Is this a bug or a feature?

Which is the best fuse4x version to use with Lion?

Cheers,

-Markus

[Anatol Pomozov]

Hi, Markus

On Tue, Jun 12, 2012 at 2:59 PM, Markus Stenberg <mste...@gmail.com> wrote:

I'm fairly heavy user of encfs, and finally upgraded to Lion my last two machines. As a side effect, I got encfs+fuse4x from MacPorts over the old versions I had been using on Snow Leopard. The 'port info' shows following versions:

encfs: 1.7.4

fuse4x: 0.9.1

Is this some non-stable version?

This a latest recommended version.

 

I'm asking because I found some odd behavior, such as apparent deadlock (encfs process to zombie state, filesystem not unmountable, anything that touches it also hangs). 

When you said that you use 64bit Lion, do you mean 64bit kernel? (You can find what kernel you use using 'uname -m'). If so then the deadlocks you see is a known issue. Short story long - 64bit kernel code deprecated some flags and fuse4x tried to emulate the old behavior. Unfortunately the emulation is not perfect and contains some race conditions. There is a 0.10.x branch that tries to fix the synchronization issues but it is not stable yet.

For now it is recommended to switch to 32bit kernel.

 

Also, the inodes do not seem to be consistent anymore, unlike in the old encfs+macfuse combination. Even during a single mount, the inode numbers seem to change at times, which leads to odd behavior from some software such as Unison. Is this a bug or a feature?

I've never used Unison software so I am not sure that I understand this issue. Could you please describe it in more details. Also what is the "inode numbers"?

Also is is the issue you started seing in the latest version (0.9.1) or it existed in previous versions as well?

 

Which is the best fuse4x version to use with Lion?

0.9.1

[Markus Stenberg]

keskiviikko, 13. kesäkuuta 2012 19.01.54 UTC+3 Anatol Pomozov kirjoitti:

When you said that you use 64bit Lion, do you mean 64bit kernel? (You can find what kernel you use using 'uname -m'). If so then the deadlocks you see is a known issue. Short story long - 64bit kernel code deprecated some flags and fuse4x tried to emulate the old behavior. Unfortunately the emulation is not perfect and contains some race conditions. There is a 0.10.x branch that tries to fix the synchronization issues but it is not stable yet.

For now it is recommended to switch to 32bit kernel.

Ok, thanks, switched.. ;-) As userland is 64bit anyway, it doesn't really matter I guess.

Also, the inodes do not seem to be consistent anymore, unlike in the old encfs+macfuse combination. Even during a single mount, the inode numbers seem to change at times, which leads to odd behavior from some software such as Unison. Is this a bug or a feature?

I've never used Unison software so I am not sure that I understand this issue. Could you please describe it in more details. Also what is the "inode numbers"?

inode numbers are the #'s which identify data blobs on disc belonging to a particular file.E.g. ls -i. For some reason (not quite sure why) they seem to change in my Lion setup (NFS + fuse4x + encfs), but not in Snow Leopard.. Even without remounting anything in that stack, just after awhile they changed. Could be artifact of Lion NFS too I guess.

Also is is the issue you started seing in the latest version (0.9.1) or it existed in previous versions as well?

I haven't tried with fuse4x, but it works differently from macfuse I had on my SL installations.

 

Cheers,

-Markus 

[Anatol Pomozov]

Hi

On Fri, Jun 15, 2012 at 12:37 PM, Markus Stenberg <mste...@gmail.com> wrote:

keskiviikko, 13. kesäkuuta 2012 19.01.54 UTC+3 Anatol Pomozov kirjoitti:

When you said that you use 64bit Lion, do you mean 64bit kernel? (You can find what kernel you use using 'uname -m'). If so then the deadlocks you see is a known issue. Short story long - 64bit kernel code deprecated some flags and fuse4x tried to emulate the old behavior. Unfortunately the emulation is not perfect and contains some race conditions. There is a 0.10.x branch that tries to fix the synchronization issues but it is not stable yet.

For now it is recommended to switch to 32bit kernel.

Ok, thanks, switched.. ;-) As userland is 64bit anyway, it doesn't really matter I guess.

Also, the inodes do not seem to be consistent anymore, unlike in the old encfs+macfuse combination. Even during a single mount, the inode numbers seem to change at times, which leads to odd behavior from some software such as Unison. Is this a bug or a feature?

I've never used Unison software so I am not sure that I understand this issue. Could you please describe it in more details. Also what is the "inode numbers"?

inode numbers are the #'s which identify data blobs on disc belonging to a particular file.E.g. ls -i. For some reason (not quite sure why) they seem to change in my Lion setup (NFS + fuse4x + encfs), but not in Snow Leopard.. Even without remounting anything in that stack, just after awhile they changed. Could be artifact of Lion NFS too I guess.

Ok, got it. TL;DR try to add "-o noforget" option. It might help you.

Here is longer explanation of what is going on here. inode number is a kind of a unique id that filesystem uses to identify files (vnodes). In case of fuse these ino numbers come from userspace filesystem. The kernel receives these id's during lookup() (e.g. when you do 'ls' or 'cd'). When kernel does not need the file information it sends FUSE_FORGET request and then deallocates the kernel structure memory. Kernel might do this when it has memory pressure and tries to find resources for other processes. Later if user lookups() these files again it asks for these same data again.

In case of low-level fuse API the filesystem should provide such unique id, but in case of high-level API a counter used to generate id automatically. And by default it just increments counter on every LOOKUP and returns its value to kernel. Thus if kernel sends FORGET and then LOOKUP it will receive a new id. This is the problem you have.

To prevent it you need to tell fuse filesystem to preserve 'filename'->'ino id' and I believe 'noforget' does it. Try it and let me know if it helps.

Take into account that "noforget" will not help you to preserve ino between fuse filesystem restarts.

 

Also is is the issue you started seing in the latest version (0.9.1) or it existed in previous versions as well?

I haven't tried with fuse4x, but it works differently from macfuse I had on my SL installations.

It is difficult to tell what is going on here. Maybe macosx kernel started to reclaim vnodes memory more aggressively?

[JT Olds]

> When you said that you use 64bit Lion, do you mean 64bit kernel? (You can
> find what kernel you use using 'uname -m'). If so then the deadlocks you see
> is a known issue. Short story long - 64bit kernel code deprecated some flags
> and fuse4x tried to emulate the old behavior. Unfortunately the emulation is
> not perfect and contains some race conditions. There is a 0.10.x branch that
> tries to fix the synchronization issues but it is not stable yet.
>
> For now it is recommended to switch to 32bit kernel.

Unrelated to Markus' question, but what are these flags? If I'm
writing a new filesystem using Fuse4x and I want to work with 64bit
Mac kernels, what can I do to avoid these race conditions?

-JT

[Anatol Pomozov]

Hi

There is no such flag that removes race conditions in 64bit kernel.

Ok, here is the code that tries to improve syncronization in 64bit kernel and make fuse4x more scalable https://github.com/anatol/kext/tree/biglock_refactoring Although it seems work fine when I use a filesystem from command like, using it from Finder crashes my computer. Finder generates a bunch of fs requests in parallel and some race condition leads to kernel panic.

But for you there is no any reason to use 64bit kernel. Fuse works (should work) the same way both with 32 and 64bit kernel. So you can develop your fs on 32bit kernel and later (when fuse4x will work better with 64bit) switch to it.

[JT Olds]

So, downgrading is not really an option for me. I'm writing a client
application that hopefully will have mass audience (soonish). Snow
Leopard's default (and newer) is a 64 bit kernel, and I can't really
ask my customers to downgrade their kernel. :(

What do you think the timeframe is on fixing the 64bit race
conditions? What's your opinion of OSXFUSE?

Thanks again,

-JT

[Anatol Pomozov]

Hi

It is not really downgrade. Both 32 and 64 bit kernels work perfectly fine. Remember that userspace uses 64bit adressing with *both* kernels.

 

What do you think the timeframe is on fixing the 64bit race
conditions?

I would estimate a month or two. There is some ubc/caching cleanup happens now that hopefully will make the "remove biglock" refactoring easier.

 

What's your opinion of OSXFUSE?

I think currently it has better 64bit kernel support, they solved most of their syncronization issues by making fuse single-threaded. Unfortunately such solution is not an good option for the current multi-core computers.