Test of using BTRFS

[rtgoodwin]

Take a look at this @cimryan please.

Changes:

• backingfiles is created as btrfs (and tools are installed)
• vfat disks are mounted at the start of the loop instead of in the loop. My thinking is that the normal pattern of the Pi being shut down and restarted with the car is basically a given. So fix them once each "boot". I don't think this should be needed during the archive mount and copy
• snapshot is created/mounted/deleted during archiving, files are copied from there, and drives are never removed from the host. To see how stability is improved/isn't.

Problems:

• Since it's a snapshot, files are copied not moved. If we go down this path, we can figure out how to deal with that. Some people want them copied not moved anyway, so a purge algorithm might be better anyway.
• I reverted to using your partitioning logic; parted doesn't seem to be loving the way I was doing it, or I ended up creating a bug. I'll figure this out separately as I like the simpler logic
• I'm missing something basic but campercent less than 100 ends up causing the music disk to be created too big. Again probably some basic thing I missed

It's a proof of concept, but I like it, if it tests stably (and better than using a simultaneous ro mount which is another option to explore). btrfs is used in production pretty heavily so I don't feel too worried about it...yet.

[cimryan]

When a snapshot is taken of the filesystem holding the cam backingfile there's no guarantee that the contents of the backing file represent a valid file system, is there? I.e. the kernel could be writing metadata into the virtual file system, which could be partially committed to the backing file at the instant the snapshot is captured. It seems that an fsck should be performed on the FS contained within the snap before its contents are accessed.

[rtgoodwin]

That's fine except the snap is read-only; I've done some simultaneous reading/writing and it seems to hold up. We could definitely add in fsck w/o repair and see how often there's a problem. Thoughts?

[cimryan]

Using btrfs as a means of copying the cam files while the drive is still being used is clever.

Moving saved clips off the drive will require disconnecting the virtual drive from the Tesla. It seems reasonable to disconnect the drive just before archiving.

Copying the ephemeral cam files seems like it would be another set of steps in archiveloop.

[rtgoodwin]

Moving saved clips off the drive will require disconnecting the virtual drive from the Tesla. It seems reasonable to disconnect the drive just before archiving.

Copying the ephemeral cam files seems like it would be another set of steps in archiveloop.

I have a few thoughts here; for example, we could have pre-mount actions that move off existing files, and/or a configurable prune routine (by space, by date, etc.).

All things being equal, I don't love disconnecting the drive, but I can't empirically prove that it's not the best way to do things. :) It just seems cleaner to say "once the drive is online, it has one goal: stay online and stable", since its purpose is to be as available as possible in case the footage is needed.

[rtgoodwin]

Updated commit to remove the flagged items.

We can wait to merge this until we decide on how to handle moves/archiving, or to user branch now; it's not terribly unclean as is.

I'd love to hear your thoughts on stability if you get a chance to test it.