Bind mounting - Githubissues

ThibaultLemaire commented 7 years ago

Switching from symlinking to bind-mounting. (Updated with latest commits from master)

Pros :

The target directory never disappears from the file tree (cf. #37 )
The target directory can be a bind mount
In case asd is interrupted abruptly, the target directory is immediately usable in the state that the last sync left it
- It is even more seamless for the system as well as for the user. (which may fix #19)

Cons :

It somehow breaks the backup feature (although I did my best to preserve it). Indeed, the backup directory is now a bind mount to the original inode of the filesystem, meaning that what is getting synced is the actual directory on disk. While this allows having a ready-to-work directory in case power failure or system crash without the need to restart asd, it prevents recovering the exact state it was left in at the time of the failure, for it could have changed before asd started again (which is very likely with directories like /var for example).
It still doesn't prevent data loss between the moment the original directory is duplicated in memory, and the moment the directory in memory gets bind mounted over the original directory.

Behaviour when using overlayfs needs to be tested (this and the use in conjunction with pacman), for I cannot test it myself, and therefore cannot guarantee it will work as expected.

Original pull request that got broken with style changes in master : #45

jult commented 6 years ago

So, is Bind mounting now the default in the release, or still waiting to be? Oh, never mind, I see it still isn't. I'd prefer it to be the default.

ThibaultLemaire commented 6 years ago

No it still isn't.

I guess what happened is that @graysky2 deemed it too big of a change and wasn't ready to take the leap yet, then never had time to investigate and test thoroughly in the meantime.

As for me, I lost interest in this project when I realised the built-in I/O caching of common filesystem drivers was enough for me, and never pushed this PR any further. Though I did use this fork with bind-mounting for a few month on a Debian 8 box without any notable issue back then.

graysky2 commented 6 years ago

I didn't want to do the testing with bind mounting.... as-is, this works great on my systems. Running for years.

jult commented 6 years ago

Been using your version as is for years, on 3 systems, one Ubuntu, and 2 Debian 8. But I did experience symlink-issues mentioned under Issues with some directories, so I just cut them out of the config. If the bind mounting would solve those issues, I'm tempted to try that, since apparently, even on a new Debian 9 machine, linux is not able to sufficiently use enough of the available RAM, I/O caching still isn't capable of doing what it can. I started using your tool when I got fed up seeing "4 GB free" on some of the servers I maintained. I then moved entire webserver vhosts into RAM and the performance results were stunning, even compared to serving from enterprise SSDs.

ThibaultLemaire commented 6 years ago

As mentioned above, this needs further testing. I did rebase my fork after @jult's comment though, on March 7, so there should be no problem merging with current master. If you are interested in this change, I can only suggest to do the testing yourself.

manorit2001 commented 2 years ago

I am not sure if your fork still exists

ThibaultLemaire commented 2 years ago

Ah. Yes. I might have deleted it when cleaning up my old forks. Oops, sorry about that.

It looks like the commits are still there though, so you're welcome to make your own fork.

manorit2001 commented 2 years ago

Ah. Yes. I might have deleted it when cleaning up my old forks. Oops, sorry about that.

It looks like the commits are still there though, so you're welcome to make your own fork.

Yes, I liked the idea regarding this a lot. I will take your work as an inspiration and try doing this. Thank you for your contribution

graysky2 / anything-sync-daemon

Bind mounting #46