GNOME Bugzilla – Bug 538264
Want better zip performance and support
Last modified: 2014-03-24 23:48:36 UTC
I want to suggest rewriting gvfs's zip slave with fuse-zip backend. fuse-zip if a FUSE file system for ZIP archivez with write support. You can download it at http://fuse-zip.googlecode.com. At this moment FUSE are present for linux 2.4.x, 2.6.x, FreeBSD, Solaris, Mac OS X. There are experimental implementations for Microsoft Windows platform. Unlike current archive backend, fuse-zip provides a full access to ZIP archive including write support. As shown with tests, accessing archive with fuse-zip are many times faster than accessing it vis gvfs-fuse.
Created attachment 112720 [details] fuse-zip and gvfs-fuse performance comparison
You can't just use another fuse filesystem as backing for a gvfs backend. However, it would be possible to (re)use the same zip code that fuse-zip uses.
> You can't just use another fuse filesystem as backing for a gvfs backend. Why? I think that it is very simple: you need simply redirect vfs calls to real filesystem operations.
(In reply to comment #3) > > You can't just use another fuse filesystem as backing for a gvfs backend. > > Why? I think that it is very simple: you need simply redirect vfs calls to real > filesystem operations. > Some questions for brainstorming - How many extra context switches is this going to add? - How easy will it be to maintain / debug? If you think hard about these and other issues I think you're going to end up agreeing with what Alex said in comment 2.
> How many extra context switches is this going to add? As you can find in performance comparison, fuse-zip is faster than current zip implementation in gvfs even with extra context switches. > How easy will it be to maintain / debug? Also you can write "glue" code to redirect vfs calls to real filesystem _once_ and use it with many FUSE file systems. About debugging: because all operations with zip file structure located in a separate process, it is easy to locate bugs in both gvfs module and fuse filesystem.
Its not *impossible* to make a backend that mounts a zip file with another fuse filesystem and proxy everything to that. Its just a very bad idea. It won't work on things not supporting fuse. It will use multiple levels of indirection causing problems both wrt performance and behaviour. I'm not against having better zip support, but using fuse-zip for it is not gonna happen.
I think that the majority of virtual file systems provided by gvfs are covered by FUSE-based file systems. So, the easiest way is using FUSE for all cases. AFAIK, migration can be done transparently because any gvfs filesystem can be mounted over FUSE.
(In reply to comment #7) > I think that the majority of virtual file systems provided by gvfs are covered > by FUSE-based file systems. And would be badly integrated when used with gvfs. And wouldn't work on systems where fuse isn't available. > So, the easiest way is using FUSE for all cases. AFAIK, migration can be done > transparently because any gvfs filesystem can be mounted over FUSE. Which isn't possible, as mentioned above.
FYI, zip support in libarchive continues to grow and stabilizes every release, recently a write support has been added (see related bug 589617). Better to fix bugs in libarchive directly than porting to different filesystem. Libarchive 3.0 is planned to be released in half a year and noticeable performance boost is expected.
(In reply to comment #5) > Also you can write "glue" code to redirect vfs calls to real filesystem _once_ > and use it with many FUSE file systems. Alexander, you'd better: 1. write a script for mounting FUSE (1) 2. vote for nautilus support of unmounting FUSE (2) That would be more clear approach. (1) Just like mine: http://johan-notes.blogspot.com/2011/07/isomountsh-iso.html (2) https://bugzilla.gnome.org/show_bug.cgi?id=607706
Closing as WONTFIX. See bug 589682 for a bug about improving archive performance.