"Normal" storage backend/driver

[cyl3x]

Is your feature request related to a problem? Please describe.

OCIS does not preserve the user's file structure like ownCloud or Nextcloud does. Sure, there's a directory with symlinks reassembling the actual file structure, but this comes with tradeoffs.
I'm running a home lab, currently using Nextcloud as my cloud for me and my family, providing NFS and CIFS shares for them and mounting subdirectories of mine and their personal spaces in e.g. Jellyfin. With OCIS, this wouldn't be any longer possible. I can't provide a nice NFS or CIFS share (WebDAV is significantly slower) nor can I use symlinks in most other applications, like Jellyfin.
I know the advantages of decomposed FS, but I would rather take the disadvantages and lower performance.

I don't know if this would even fit in with the OCIS vision/direction and if it would have a use case outside a home lab.

Describe the solution you'd like

Have a storage backend that preserves the actual file structure like ownCloud and Nextcloud does.

Describe alternatives you've considered

Not to use OCIS and stay with the alternatives.

[micbar]

@tbsbdr FYI

[springroll12]

This is essentially what is preventing me from using Owncloud OCIS as well.

Another use case: If I want to migrate my data from Owncloud to another storage solution, I don't want to have to do an expensive and time consuming migration to get the raw files. I understand the industry is moving towards S3-style object storage for performance reasons, but this is not really user-friendly.

I believe this issue is related #5358 and it seems like this is not on the OCIS roadmap.. but I would suggest this would be a fantastic way to gain adoption.

[micbar]

@springroll12 @cyl3x

The topic is well understood.

let me explain why we focused on the decomposedFS:

1. We wanted to get rid of the database! (Yes, we did 😊)
2. All Metadata and share information is stored in the filesystem
3. We have the option to store the file blobs in S3. (S3NG driver)
4. We need to have an efficient lookup by id. Every file needs a logical unique ID. This is possible in the decomposedFS via the reverse indexing using symlinks.
5. the decomposedFS can be scaled via NFS

normal FS

this would introduce the dependency to a database again. I agree that it makes sense. But what you really need is a „collaborative“ storage, which can be used directly bypassing the ocis APIs. This is possible via EOS and in the future maybe via SMB or Ceph.

[springroll12]

If this is currently possible through EOS driver, is there some guidance somewhere on how to achieve this? I'm sure many folks currently stuck in other storage solutions would like to try exploring it (or even developing different storage backends).

At the moment EOS seems very nebulous and I'm not sure how it fits into the equation.

[micbar]

@springroll12 Correct. EOS is a large storage Cluster invented by CERN.

GitHUB https://github.com/cern-eos/eos

Basically it is a POSIX filesystem with direct system ACL integration to work as a "collaborative" storage. You can work on the storage directly or in oCIS and have the same data and permissions.

[micbar]

Maybe there is an easier way to go.

Let me assume the following:

1. You are hosting ocis by yourself on a linux machine or VM
2. You want to have some basic access to the files on the disk directly using rsync or another app which "just needs to read and write from the storage" (No high Performance use case, no high IOPS requirements)

Possible Solution

We could create a FUSE layer which mounts the decomposedFS as a normal POSIX tree. We could start something based on https://github.com/bazil/fuse . From my POV, this could be a really low hanging fruit. We could use the existing go implementations of the DecomposedFS from the ocis codebase directly.

Just thinking loud...

@butonic @dragotin @dragonchaser @hodyroff What do you think?

[tbsbdr]

I'd love to have a FUSE layer so that I have full controll via cli (had a similar request a year ago on central )

[dragotin]

Yes, FUSE is nice, but only as a very very last resort. Building it means maintaining another component which is error prone and also complex to use for users.

I wonder if there is a way to build a "simplified" decomposed FS that still has a "natural" and user accessible file tree, but also uses an index directory, that links file IDs to to paths or files.

If we accept to use a file notify framework (ie. https://pkg.go.dev/github.com/rjeczalik/notify ) for that it could be possible to maintain the index links during normal access to the file tree.

In reference to what @micbar mentioned in #7126 (comment), I think this simplified driver should have smaller requirements for now, ie.

• not for the "big data" usecase
• no S3 support for blobs
• limited to one local filesystem (no nfs)

Important to note and one of the hard challenges: The File ID that needs to be de-referenced quickly must not change if a file is renamed, ie. the renamed file must still have the exact same ID.

[micbar]

Yes, FUSE is nice, but only as a very very last resort. Building it means maintaining another component which is error prone and also complex to use for users.

Good point. I took a look into the Go Fuse libraries and how we could implement it. For me, it seems way less effort than building a new storage driver. Our storage interface has grown very much.

A full ocis storage driver needs to implement:

• Spaces listing
• Spaces structure
• Sharing
• Async uploads
• Versions
• Trashbin
• Events for postprocessing, antivirus, search
• Locking
• ...

That feels like so much more work than to use the existing go code in the decomposedFS to implement a FUSE driver.

[springroll12]

@dragotin this is exactly what I was hoping was possible. It does seem like a lot more work, but would support most of the simpler use cases.

My understanding of the "no NFS, no S3 support" is that it would support ONLY serving/managing files from a local directory? Would this include NFS / SMB / Ceph volumes that have been mounted independent of OCIS? I think a lot of folks would use a mounted volume of some kind as their primary NAS storage, and if OCIS could not use this transparently (ie. if something about the mounted volume does not jive with the indexed FS), then I'm not sure this solution would cover the use case. To be clear in no way should OCIS speaking NFS/SMB be required in these scenarios.

[rhafer]

Would this include NFS / SMB / Ceph volumes that have been mounted independent of OCIS?

AFAIK the usual change notification mechanisms in linux (inotify/fanotify) don't work for remote filesystem like nfs/cephfs/cifs. So this is a tricky one. (For cifs this might be solvable via libsmbclient).

[dragonchaser]

We could create a FUSE layer which mounts the decomposedFS as a normal POSIX tree. We could start something based on https://github.com/bazil/fuse . From my POV, this could be a really low hanging fruit. We could use the existing go implementations of the DecomposedFS from the ocis codebase directly.

This looks promising, I'd love to see this

[springroll12]

@micbar

Would the FUSE mechanism support filesystems mounted through NFS externally? Or does it suffer from the same challenges @rhafer mentioned?

[dragotin]

@springroll12 if we have the fuse layer, we would not have to use the inotify layer @rhafer was talking about.

Now the question still is if the fuse layer works on a file system that is mounted via NFS.

I tried that with a share mounted like this:
192.168.178.83:/musik on /mnt type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.178.111,local_lock=none,addr=192.168.178.83)
and starting the fuse layer from https://github.com/dragotin/openvfs which should at least be technically similar to what we need.

That (completely un-representative) test was successful, the fuse layer worked as expected on the NFS share.

[springroll12]

Seems like the fuse mechanism might work. I also see a similar feature request here: https://central.owncloud.org/t/is-something-like-external-storage-in-the-long-term-roadmap-for-ocis/42166/7

Any news on if this can be actioned in a future release?

[springroll12]

Any chance this has made it onto a roadmap? If not could you provide guidance on how to implement the fuse layer with a community plugin?

[micbar]

We have great news!

We are currently working actively on a pure POSIX storage driver.

cs3org/reva#4494
cs3org/reva#4562
cs3org/reva#4708

Branch with ongoing work on technical documentation: https://github.com/owncloud/ocis/tree/doc-posixfs

[the-hotmann]

@micbar do you have a roadmap, or a list of features which you guys plan to implement?

Would be very interested to be keep up-to-date on this topic.
Thanks!

[micbar]

Check this out please. #9317

[the-hotmann]

Thanks, will have a look at.

[springroll12]

This is awesome! It looks like considerable progress has been made already!

[micbar]

The rolling release 6.1.0 from yesterday has the new storage driver inlcluded.

Please check it out and report back any isssues.

[the-hotmann]

@micbar any info about, when this will be integrated in the official docker image?
I use the :latest tag and currently run on 5.1.0-prealpha+42e1d39da.
So far from 6.1.0.

Thanks in advance!

[micbar]

Please note:

owncloud/ocis ist the production release.

If you want to get hands on the rolling release, please check out owncloud/ocis-rolling.

[micbar]

More details about the release channels: https://owncloud.dev/ocis/release_roadmap/