search

hanwen / go-fuse

FUSE bindings for Go
Other
2.05k stars 328 forks source link

Create new NodeFS API #264

Closed hanwen closed 5 years ago

hanwen commented 5 years ago

Continued from https://github.com/hanwen/go-fuse/pull/262

the NodeFS + PathFS api is clunky.

Problems:

hanwen commented 5 years ago

Other clunky things:

File.SetInode Node.SetInode

hanwen commented 5 years ago

generation is totally faked.

rfjakob commented 5 years ago

Maybe we could also get the size of a node down. We have to hold a lot of them in memory.

hanwen commented 5 years ago

see https://github.com/hanwen/go-fuse/pull/265 for a sketch

guillaumerose commented 5 years ago

Would it be a good idea to use/adapt/bridge the go-fuse API to the gvisor API ? Some code seems to be similar.

https://github.com/google/gvisor/tree/master/pkg/sentry/fs

hanwen commented 5 years ago

Thanks for the tip. That code looks interesting.

gvisor emulates the linux kernel, so it's obvious that there are similarities, but the FUSE protocol is different, so I think we can't really use the API directly.

The real question pending for the FUSE library is whether to phrase function in terms of the kernel FUSE API or Go library APIs. For example, should Open take OpenIn or look like OpenFile ?

hanwen commented 5 years ago

If you have opinions in either direction, have a look at PR #265

guillaumerose commented 5 years ago

An other example from gVisor is netstack. They offer couple of Go adapters to interact with a network stack. https://github.com/google/netstack/blob/master/tcpip/adapters/gonet/gonet.go#L15

They stay as close as possible of the protocol and offer adapters.

hanwen commented 5 years ago

so, you mean that you prefer something that stays close to the protocol?

guillaumerose commented 5 years ago

I would say both. Direct access to the fuse protocol and an adapter for Golang files.

For instance, in Docker Desktop, we run a VM with docker inside and need filesharing. We have a POC using grpc and this library to be able to share files between Mac/Win host and Linux VM. We use the PathFS API at first but maybe at some point we would need to access more low level details. At least, we need access to NodeFS for instrumentation.

hanwen commented 5 years ago

current new API proposal: https://github.com/hanwen/go-fuse/pull/270

hanwen commented 5 years ago

the current API is merged and but still not set in stone.

Regarding @guillaumerose . The gvisor API certainly looks useful. For example, it would suggest we rename NodeAttr to StableAttr.

ghartz commented 5 years ago

@hanwen Hi! You merged #270 but current issue #264 is still open...

Your work regarding the new NodeFS API is finished? If not, any rough ETA?

hanwen commented 5 years ago

I wanted to get some more feedback from @navytux , but it seems he has been busy.

I was in the middle of porting go-mtpfs to the new API before I left on holidays 2 months ago, and have been busy with my day job since coming back.

There is still polish I intend to make, but overall, I think the API is ready for serious use.

navytux commented 5 years ago

(@hanwen, appologize for the review delay; it is indeed too busy now and in the short-term future)

hanwen commented 5 years ago

The new API is thoroughly documented and can be used. I think it's too late to make major changes now.