s3ql VS Allusion

i used to use [0]s3ql on-top of "slow" fuse storage. it comes with its own caching layer and some strategies around handling larger blobs of data efficiently even at high latency with ease but its a non shared filesystem. you mount/lock it only once per system. otherwise this was a perfect solution to me at the time.

[0] s3ql: https://github.com/s3ql/s3ql

Off the cuff, you can probably use s3ql or something similar as a posix compatible abstraction layer over b2.

I use a S3QL mount to store user data, but do hacks and keep the 4-5 log files, the cache, templates, and tmp stored locally on file systems.

Another alternative to rclone mount is S3QL, which in my experience, is much faster (https://github.com/s3ql/s3ql).

An option may be to use https://github.com/sismics/docs and enable S3 support using https://github.com/s3ql/s3ql

Thank you! It wasn't s3fs-fuse I was remembering, but their github site referenced the project I was looking for: s3ql

I’ve been using s3ql to mount an S3-backed filesystem for the Nextcloud data folder. It has been reasonably fast and very stable so far (~1.5 years, 270GB hosted).

Well - I am using s3ql. It builds an encrypted file system into an S3 bucket, and works quite nicely and reliably. I started using that before Linode offered S3, and I was not keen on sharing my files with any of the big providers. So, my files currently are on S3, but not directly from Nextcloud, but with the s3ql layer inbetween.

Allusion? https://github.com/allusion-app/Allusion

You can only block a web worker thread; blocking in the main thread is not allowed by browser vendors. If you want to synchronize two web workers, you can use the std primitives like Mutex and compile with atomics. If you want to synchronize the main thread and a web worker, you need to build this yourself. I have implemented this in one of my code bases (https://github.com/allusion-app/Allusion/blob/master/wasm/masonry/src/sync.rs) but the code is GPL licensed. Note this particular code only works in browsers that support Atomics.waitAsync. An alternative is to wrap a worker.onmessage callback in a Promise and await that. Also statics are used because I don't want the overhead of calling receive from JavaScript back to Rust in the web worker, not that they are required.

One idea that could work out is to move state management to a web worker and state changes are just messages between the main thread and web worker (JS example with Redux + React + Comlink. The Redux and Comlink would be reimplemented in Rust (requires atomics, WASM intrinsics and however Redux works). However, using atomics is not so nice. Atomic.waitAsync has so far been only stabilized in Chrome last time I used it and the Rust std library has no equivalent, so you still have to call that from Rust. I've implemented something similar to a channel/spinlock but with statics (github source).

The final implementation: Masonry algorithm in Rust, Webworker, Masonry renderer which makes use of the Virtualized renderer