Score:0

`x-systemd.automount` + `x-systemd.idle-timeout` + `exfat` = data loss?

in flag

I've set up hourly automated backups to several exFAT formatted storage drives. Here is an example of one of the mounts as per x-systemd.automount and other goodies:

UUID=XXXX-XXXX /media/XXXX-XXXX auto noauto,nofail,nouser,uid=root,gid=users,umask=007,X-mount.mkdir,x-systemd.automount,x-systemd.device-timeout=1,x-systemd.idle-timeout=60 0 2

This has been working fine for a while, until yesterday. I have two directories in /media/XXXX-XXXX, one dedicated for backups from user a and another one from user b. Those backups can happen in parallel as there is no data overlap or corruption possible in this case. Plus, backup software obtains the lock upon a directory it dumps data to, so it's safe in this regard as well. I noticed the last successful backup for a yesterday followed by continuous failures for it afterwards (because this incremental backup software checks for metadata and the backup repository in that directory is actually setup correctly and nothing appears to be corrupted). When I looked into that directory for a, it turns out to be empty, the directory itself is there though. Also note, that b is absolutely fine, its directory is full of data and the backups continue without any problem. I checked journalctl and I see no errors related to this drive/mount. It was unmounted and remounted a few times between the last successful backup for a and the first failed one, which is normal given the mounting options above.

I've also ran

sudo fsck.exfat -r /dev/sdxX

and that succeeded but didn't restore any data. Additionally, disk health does not report any broken sectors.

Note, that other drives setup identically didn't experience that problem. They still hold both a and b and backups are running. Though I have a feeling that this is just a matter of time. My fear is that it could well be some corner-case bug somewhere down the filesystem/kernel stack that facilitates itself rarely.

My question is whether it's possible that data would disappear in such selective way (i.e. only all files inside of a particular directory) if there is no ejection (this is internal drive BTW) and is only subject to unmounts/remounts? There is a known problem of ejecting without unmounting first (which again has nothing to do with the above scenario), but that only applies to newly queued data that is still buffered to be written, i.e. even in this case, the old data should still be there.

Could it be that this is exFAT issue (it's relatively new, isn't it)? The point is, I don't know how to deal with this now and whom to ask for help (Linux kernel team? exFAT driver developers? systemd developers?) as there is nothing suspicious in logs.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.