I meant reflinks not extents. I should go to bed ;) Wout.
On Thu, Feb 28, 2019 at 11:57 PM Wout Mertens <wout.mert...@gmail.com> wrote: > One option, if you are on a filesystem supporting extents (macOS's apfs > and Linux's btrfs only, currently, with xfs and bcachefs support on the > horizon): do a copy with reflinks (cp -c on macOS, cp --reflink=auto > elsewhere). That should be super fast since all it does is point to > existing data and duplicate the metadata. > > Then, you can do an operation that collapses the WAL log like `sqlite3 > copiedfile.sqlite3 .schema` and that should normally fail if the WAL log > was copied at an inopportune time; in that case just try again. > > This way you can make space-efficient copies of the db on the same disk, > and you can copy them to a safe location at your leisure. Keep a few copies > around and you have pretty granular snapshots. > > Wout. > > > On Wed, Feb 27, 2019 at 6:03 PM Simon Slavin <slav...@bigfraud.org> wrote: > >> On 27 Feb 2019, at 4:16pm, Richard Hipp <d...@sqlite.org> wrote: >> >> > On 2/27/19, Stephen Chrzanowski <pontia...@gmail.com> wrote: >> >> Does write blocking still come into play when using "vaccum into", >> > >> > The VACUUM INTO command is a reader. So (in WAL mode) some other >> > process can continue writing while the VACUUM INTO is running. >> >> The advantage is that a write from another thread doesn't force a restart >> in VACUUM. So the VACUUM process may cause a short delay in the writing >> process, but the VACUUM process completes in one operation and then the >> database is free until the next backup. >> >> WAL mode seems to be the right mode for you, unless you have limited disk >> space for the journal file. >> >> Which is best for you depends on the frequency of your reads, writes and >> backups, and on how fast your storage medium is. It's not something which >> can be usefully predicted for 'average use on average hardware'. >> >> Simon. >> _______________________________________________ >> sqlite-users mailing list >> sqlite-users@mailinglists.sqlite.org >> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >> > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
