In the meantime I found this discussion from 2011 about sqlite on CIFS: http://sqlite.1065341.n5.nabble.com/How-to-make-SQLite-run-safely-on-CIFS-mounted-file-system-tt37415.html#none
Basically using any networked filesystem as a backing store for sqlite is madness? I imagine not much about that changed in the last 7 years. Using the per-host-file-messaging as a communication channel to a single master that also exports the NFS doesn't seem that outlandish any more. On Tue, Aug 14, 2018 at 3:07 PM Wout Mertens <wout.mert...@gmail.com> wrote: > Idle musing again, I'm pretty bad at dropping thoughts that are not > immediately applicable to me, sorry. > > I know that multi-writer sqlite and NFS don't play well with each other. > > However, I wonder if some constraints could be added that would make this > situation safe. > > My problem space is that of a shared NixOS package store between VMs, > which holds metadata about the available packages: > > - many writers need access to the same db > - their only communication channel is the POSIX filesystem that holds > the db > - they only write "seldomly", every few seconds at the fastest > - they do read all the time > - it is ok if read data is a little bit stale (10s is acceptable) > - it is ok if write transactions fail and can be retried > - it is ok if writes are slow > - it is never ok for data to be corrupt > > Is there a way to use safely sqlite in this situation, perhaps by using > extra lock files or some other additional mechanism? > > One solution I can think of involves sending all writes through a single > master, via files describing changes and lots of polling, but that seems > really outlandish. > > Wout. > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
