Vitaly Shukela

Is ZboxFS supposed to be used in async/Tokio context? (where thread may be unpredictable). Does it rely on thread-local storage? Can transactions be untied from threads? There can be explicit...

Similar panic happens in `sqlite://` mode (with a "database is full" error instead). In that case however storage can be opened again (if I grow tmpfs a little bit). Unfinished...

> If writing doesn't call finish(), the transaction doesn't commit and all uncommitted data will be lost. After a crash with unfinished writes, storage is still full in megabytes. Are...

With `mem://` storage, running out of space is even nastier: `memory allocation of 8192 bytes failed`, then just plain abort. ----- I think ZboxFS should actively mind available room (in...

> That could be hard as some storage are not able to retrieve free space at run time, even through it can be retrieved the cost to constantly monitor it...

> Yes, those files are still secured but they are inaccessible. Secured with the same key as the rest of files or secured with some session key that is supposed...

> Accurately pre-allocate space is impossible because it has no idea how much data user will write in. The file writing is like streaming, until transaction was committed there is...

> When writing data to file, it firstly writes data to a staging area. How do I recover data from that staging area if transaction was neither cleanly finished nor...

High-level setup is outlined in the opening comment. Here is example code. `src/main.rs`: ```rust fn main() -> Result { env_logger::init(); zbox::init_env(); let mut r = zbox::RepoOpener::new().create(true).force(true).open("file:///tmp/limit/q", "123asd")?; use std::io::Write; let...

> Heuristically estimate the wal file size in advance is impossible Either this is not true (I suppose it should be something like a logarithm of file size being written)...