Can't set nonseekable for open files about cgofuse HOT 9 CLOSED

Perhaps I oversimplified the Open method by not including any of the fuse_file_info flags.

There are two issues:

• How to best pass fuse_file_info back and forth in Open and Create.
• Many of these fields are ignored on WinFsp-FUSE. Specifically the nonseekable flag is not being honored.

Let me give it some thought.

from cgofuse.

From WinFsp fuse_intf.c:

    /*
     * Ignore fuse_file_info::direct_io, fuse_file_info::keep_cache
     * WinFsp does not currently support disabling the cache manager
     * for an individual file although it should not be hard to add
     * if required.
     *
     * Ignore fuse_file_info::nonseekable.
     */

[The first part of the comment is actually wrong now, because WinFsp currently supports selectively disabling the cache manager.]

So unfortunately nonseekable is not supported on WinFsp.

from cgofuse.

I'll just make sure that seeking returns an EIO which is probably all that libfuse does, though I guess it might do some magic in the kernel.

from cgofuse.

If I get some free time later today, I will investigate the specific behavior.

from cgofuse.

My findings:

• OSX: the nonseekable flag appears to be ignored (FOPEN_NONSEEKABLE query).
• Linux: causes the lseek, pread and pwrite calls to fail with ESPIPE.

So it looks like the nonseekable flag is Linux specific. Returning -ESPIPE if you can detect the out-of-sequence I/O should be sufficient. But I am wondering if that severely cripples the file system (e.g. no memory mapping support, no caching support, etc.)

from cgofuse.

Thanks for looking that up. I'm not checking this at the moment on OS X so that is a bug which needs fixing in rclone.

I had to look up ESPIPE, but it is "Illegal seek" which makes perfect sense.

But am wondering if that severely cripples the file system (e.g. no memory mapping support, no caching support, etc.)

Yes there are certainly things a fs with no seek can't do, but most application just read and write files sequentially so it is more useful than you might think.

from cgofuse.

Yes there are certainly things a fs with no seek can't do, but most application just read and write files sequentially so it is more useful than you might think.

I agree.

Going back to the original ask ("can't set nonseekable for open files") it looks like that these flags tend to be os/implementation specific. I therefore suggest that we close this issue with "wontfix". Do you agree?

I thought a bit more about the general problem that you have with rclone and seekability. If I understand correctly the problem is that most cloud storages provide a method to do a ranged GET, but no method to do a ranged PUT.

I think that you mentioned caching files locally in a different thread (or the rclone docs); I believe such a scheme could work nicely. As an example I mention the Andrew File System, which fetches a file on the first open and satisfies all I/O from the local file system. When the file gets closed AFS uploads the file to the server, but only if it has been updated.

Here is a very nice writeup of how AFS works. I believe the AFSv1 protocol might be sufficient for rclone.

[You also have to worry about issues with eventual consistency on cloud storage systems, but I am sure you are already aware of those.]

from cgofuse.

Going back to the original ask ("can't set nonseekable for open files") it looks like that these flags tend to be os/implementation specific. I therefore suggest that we close this issue with "wontfix". Do you agree?

Yes that sounds fine.

I thought a bit more about the general problem that you have with rclone and seekability. If I understand correctly the problem is that most cloud storages provide a method to do a ranged GET, but no method to do a ranged PUT.

That is correct.

I think that you mentioned caching files locally in a different thread (or the rclone docs); I believe such a scheme could work nicely. As an example I mention the Andrew File System, which fetches a file on the first open and satisfies all I/O from the local file system. When the file gets closed AFS uploads the file to the server, but only if it has been updated.

That is exactly the scheme I've been thinking of. Thanks for the AFS writeup link. That has the additional idea that you'd keep the local file in a cache and check it hadn't changed on open which I hadn't thought of. That would be relatively easy.

[You also have to worry about issues with eventual consistency on cloud storage systems, but I am sure you are already aware of those.]

Yes... File systems on cloud storage systems tend to be a little approximate. The main problem is that the PUT/GET is much less reliable than file systems expect. This isn't a problem for reading - you can retry, but writing is a real problem which is the major desire for caching the whole file for upload.

from cgofuse.

Going back to the original ask ("can't set nonseekable for open files") it looks like that these flags tend to be os/implementation specific. I therefore suggest that we close this issue with "wontfix". Do you agree?

Yes that sounds fine.

Ok closing this, but will continue the discussion below. Let me know if you believe we should move this discussion elsewhere (like an rclone issue).

[You also have to worry about issues with eventual consistency on cloud storage systems, but I am sure you are already aware of those.]

Yes... File systems on cloud storage systems tend to be a little approximate. The main problem is that the PUT/GET is much less reliable than file systems expect. This isn't a problem for reading - you can retry, but writing is a real problem which is the major desire for caching the whole file for upload.

I am familiar with eventual consistency problems as I have done some cloud file system work myself. The worst I have seen is overwriting an object on cloud storage, only to read it back from the same machine and discover that I am getting back the previous version of the object. It is for this reason that I designed my own secfs as a copy-on-write file system (i.e. objects on storage are written only once and never overwritten; this gets around the eventual consistency issues (cloud objects in secfs are file chunks and never full files themselves)).

In your case you must work with existing objects ("files") on cloud storage and cannot afford to design your own file system structure to avoid consistency issues. So some of the AFSv1 ideas may not work outright. For example, I am not certain that you can implement a version of TestAuth reliably.

You may therefore have to cache files only while they are open (for updating). This way you do not have to issue TestAuth against an unreliable cloud storage.

I am happy to discuss protocol specifics if you want me to (here or elsewhere).

from cgofuse.