3 years and change ago, I decided to setup a FreeNAS box with a ZFS mirror to store long term data. The OS changed to Debian when I decided to run a few web apps, but I kept using ZFS for the mirror. The main point of ZFS is that it checks the data periodically and can repair as needed. After over 3 years of running it found its first data error with a few checksums being wrong. This wasn't surprising since the drive had uncorrectable sectors for the last year. At the same time as the ZFS checksum errors, the first reallocated sectors showed up. I went ahead and ordered a new drive since Backblaze and Google correlate reallocated sectors to a failing drive.
I'm a big fan of keeping it simple so I reevaluated whether ZFS is the right choice vs the standard mdadm+lvm+ext4 setup. My use case is a mirror(RAID 1) that's used as a media server and backup of my desktop ssd. ZFS's checksum protection did nothing for me since SMART data already told me the drive should be monitored closely and replaced when reallocated sectors happened or uncorrectlable sectors became worrying. ZFS's snapshots were turned on and I used them once to recover a file I had accidently deleted. This feature was unsettling to use since it rollsback the entire filesystem to a previous date in time. You have to be sure that you get back to a state where the data you want is correct and the rest of the filesystem is acceptable. This gets a bit sketchy when you have thousands of files on a 4TB drive. It's also not a free feature as many people portray it. Each snapshot withholds changed blocks as long as the snapshot exists. This meant I had a few hundred GBs being used on top of the current data. Compression is currently sitting at 0% since the majority of files aren't compressible. A minor pain point on Linux is that every ZFS update means recompiling the ZFS modules so updates take a good deal longer and will need a couple cores dedicated to that.
In the end, I'm not convinced a user without some serious hardware should use ZFS. It's got shiny features, but they don't seem to come into play unless you have a targeted use case or by some very, extremely, ridiculously unlikely event, manage to get an error that isn't caught by ECC, SMART etc, but is caught by ZFS. You might say those features seem like they could be nice, why not use ZFS in case I want them later? ZFS lags behind common file systems in one critical area, performance. In the end, you'd be giving up daily performance for that possibility. If I were to do it again, I would go with mdadm+lvm+ext4.
I finished moving the site from NearlyFreeSpeech over to a Debian VPS at DigitalOcean today. I wanted a low maintenance OS so Debain with unattended upgrades installed to automatically handle security updates was the obvious choice.The stack is still python with apache, but I switched the database to Postgresql and mod_wsgi is running python instead of gunicorn. Postgresql is what I've been using in other projects so standardizing on it made sense. All my database interactions were written using the Django ORM so switching over was just changing couple of settings in Django to point to postgresql. Mod_wsgi is easier to properly setup than gunicorn, the logging integrates with apache and it has great performance out of the box. Certbot takes care of keeping the Lets Encrypt cert up to date. 
Building maps for Maps.Me requires the same data as my previous posts with OSMAnd. See those posts for processing the initial data. For Maps.Me the process is more complicated since it uses C++ and adds its own data to the OSM data. The instructions are pretty good so I'll summarize the issues I had. Lessons learned:
After you add your first county things become easier since you probably only need to change the translation file to grab the column names that the county used. I've been doing some manual quality assurance(QA) by opening the osm file generated by ogr2osm using Josm and Nano to spot check that the translation works as expected. Then you'll add the new osm file to your osmium merge command. QA the output of that using osmium diff -qs newfile.osm.pbf oldfile.osm.pbf. This will show the number of objects that are different from the last time you performed your merge, the left number should roughly correspond to the number of addresses you've added, right 0 since you're not deleting. My WA file is currenly up to 1.33 million addresses added from 6 counties. Osmand map creator took 44min on a 2C/4T 3.7Ghz cpu with a max of 6.3GB ram allowed. You can check out the files I'm generating for WA at WA Map Releases
Lessons Learned:
More Investigation Needed:
One of the biggest pains when using OSMAND for navigation is the lack of addresses in many areas. Through some research for an OpenStreetMap(osm) import, I've learned there is open address data for the counties around me that hasn't been imported due to the amount of work it takes. As a stopgap measure, I decided to find a way to load that open address data into OSMAND. The process was a bit of a pain to figure out due to OSMAND not having documentation on using non OSM extract data to create an obf file(OSMAND's map format)
The end result is full address coverage for King Co. with the minor inconviences of some duplicate addresses and addresses with a 0 housenumber since I didn't do a full clean of the data.
Lessons Learned:
Links: