On Apr 10, 2019, at 12:08 PM, Peng Yu <pengyu...@gmail.com> wrote:
>
> https://softwarerecs.stackexchange.com/questions/45010/transparent-file-compression-apps-for-macos
>
> I work on Mac. Would this be worthwhile to try?
The first link didn’t work here because it didn’t like the APFS drive I tried
it on. (Symptom: “Expecting f_type of 17, 23 or 24. f_type is 26.”)
I then tried the so-called “Github mirror”, which is no such thing: it’s
considerably advanced beyond the last version published at the first link, and
one of the improvements is APFS awareness.
Using that improved version, simple tests then worked, but then attempting to
use it on a SQLite DB file uncompressed it and left it uncompressed. I believe
this is because this OS feature relies on the old resource fork feature, which
means it only works with apps using the Apple-proprietary programming
interfaces, not POSIX interfaces, as SQLite does.
> Does the transparent
> compression work at the file system level or at the directory level?
Neither: it works at the file level.
You can point afsctool at a directory and it will compress the files in that
directory, but if you then drop another file in that directory, it won’t
automatically be compressed.
The tool will also skip over files it considers “already compressed” unless you
give it the -L flag, so giving it a directory name isn’t guaranteed to result
in all files in that directory being compressed.
> Would
> it have a slight chance to corrupt the existent files on the disk (e.g.,
> power outrage during compression)?
Between the resource forks issue and the fact that we’re having to use a third
party tool to enable it, I wouldn’t put much trust in this feature.
If you want to put your trust in a third-party OS add-on, O3X is worth much
more of your attention than afsctool:
https://openzfsonosx.org/
If you don’t have a spare disk to feed to it, you can create a pool using raw
disk images:
https://openzfsonosx.org/wiki/FAQ#Q.29_Can_I_set_up_a_test_pool_using_files_instead_of_disks.3F
ZFS’s abilities to a) add vdevs to a pool; and b) replace smaller vdevs with
larger ones together mean you can safely set the initial pool size to just
barely larger than the initial DB file plus any ancillary space needed. (WAL,
slack pages between VACUUM calls, etc.) You can then grow the pool
occasionally to keep ahead of the growth of the DB without sacrificing too much
on filesystem overhead. It’d be easy to write an on-demand 20% pool size
growth script, for instance; it’d be maybe half a dozen lines of Bash.
Lest you go off on an unfortunate tangent from this idea, note that the
“compressed disk image” feature of Disk Utility won’t help you here. Those are
read-only.
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
