syncthing on filesystem that is "eventually-read-written"

Hello. Unfortunately I don’t know how to express my question better and it is simply because I’m not an expert in linux and/or filesystems.

My usecase is as following. I would like to install syncthing on a orange pi zero SBC. The challenge, however is that I’d like to be able to turn off the board by simply unplugging it from the power socket without damaging the SD card. I’ve already been able to utilitize overlayfs, so that the system starts up in read-only mode, however in order for syncthing to function, it requires a read-writable filesystem. I’ve thought of two solutions:

  • to have some sort of a hook that would trigger whenever syncthing would know that it has to modify a directory - then I could remount the filesystem in r+w mode, and remount it in ro mode when files are transferred. However, from what I can understand, such functionality (of the hooks) is not exposed by syncthing (I found a github issue though)

  • to continue to have the system running from the SD card, but have an external partition with a journaled filesystem on USB flashdrive. if I understand it correctly, it would mean that if synching would not modify the files, I could still unplug the power cable and not damage the flash drive ? (because the only process writing to the filesystem would be syncthing) or if any partition is mounted in r+w mode, then any other shutdown other than… well initiating shutdown command will result in the USB drive error and there’s no way around that ?

kind regards,

I don’t know about your workarounds, but is it possible that you are overthinking things? With a modern filesystem I would expect things to work fine despite yanking power now and then.

well, on every forum post I could find people would always say that you need to “properly” unmount the SD card (by issuing a shutdown command) or you might damage it (by just unplugging power from the socket) so I reckoned that a USB drive would have the same limitations. Maybe using journaled filesystem would be enough, I just don’t want to damage hardware and thought I’d ask people that are smarter than me :smiley:

The users who are warning about properly unmounting a mounted filesystem to avoid “damaging” it are referring to the filesystem and not the underlying hardware.

Whether it’s a SD card, USB flash drive, SSD or HDD, cutting power will damage the filesystem but won’t damage the hardware (although powering it back up will cause a tiny amount of extra wear and tear).

In terms of safety, it’s better to first use the power switch rather than simply pull the plug from the socket. The latter runs the risk of arcing depending on the amount of current and humidity in the surrounding air (on a related note, definitely don’t do it when there’s a decent concentration of dust and/or flammable vapors).

A journaling filesystem will definitely help protect against data corruption. It however doesn’t prevent the filesystem from being damaged – the filesystem journal and rollback features are used for the repairs. And it also doesn’t prevent loss of data that hasn’t been fully committed yet.

There are some SSDs and NVMe drives that use onboard tantalum capacitors as a pseudo-BBU (Battery Backup Unit). The capacitor holds enough charge to allow the SSD/NVMe to finish flushing its RAM buffer.

As for dedicating a partition or drive to Syncthing, depending on the chosen filesystem type, Syncthing might not be the only process writing to the filesystem.

wow, thank you so much for the response. so am I right that theoretically the better solution would be the one with remounting ? meaning - remounting the filesystem in r+w mode before the transfer and then mounting it back in ro mode after transfer is done [most likely preceeded with a call to sync command (yes, I am aware that it’s impossible to do with syncthing)]. Of course I am aware of the fact that the best thing to do is to ssh into the SBC, then issue shutdown command and then remove power after I would be certain that system has been turned of, however that’s the luxury I don’t have :frowning: Second issue I am obviously aware of is that even with remounting, if the power is shut during the transfer itself then there’s still data corruption and there’s no way around that. Just for the sake of argument, I’ve chosen not to include this scenario. I think the most surprising outcome for me (from your reply) is the fact that even if I dedicate a whole partition to syncthing, it might not be the only thing using it.

thanks again,

Not sure, 5 bucks that leveldb will not like being yanked half way through a write and end up with corruption.

Syncthing’s config file and database needs to be accounted for…

  • Placing them on or under an overlay filesystem will cause problems.
  • Placing them on secondary storage that’s remounted between read-write and read-only will also be problematic.

You’d mentioned an electrical outlet, so I’m guessing your Orange Pi Zero rig isn’t going to be mobile unless it’s being plugged into a AC/DC power inverter.

Instead of SSH, how about a simple button on one of the GPIO pins or a USB input device? There are plenty of programmable keypads such as this one: https://amazon.com/iKKEGOL-1-8Meter-User-Defined-Keyboard-Hospital/dp/B00UWDZYQK/. Just have Linux call /sbin/shutdown whenever the button is pressed.

Right now there are too many missing details about the particular use case to really suggest a possible solution.

ZFS, btrfs, XFS and some other filesystems have housekeeping processes.