4 ms·
if it happens during the sync you could be arbitrirly broken.
by spullara 10y ago
if it happens during the sync you could be arbitrirly broken.
- deleted 10y ago[deleted]
- avar 10y agoOnly if the sync is the equivalent of: rsync [...] /dev/shm/.browser ~/.browser Instead of: rsync [...] /dev/shm/.browser ~/.browser.new && ln -sf ~/.browser.new ~/browser Or some such equivalent, i.e. doing the full sync and then atomically juggling a symlink around.
- wolf550e 10y agothat creates many more writes to the ssd.
- waterhouse 10y agoDoes it? Consider this scheme: maintain two physical directories, one of which is current (and is named by a symlink) and the other of which is old. When doing a sync, you rsync the newest data into the old directory, then update the symlink. It'll probably result in somewhere between 1x and 2x the writes as the non-atomic single-directory scheme, depending on how well adjacent diffs combine. It will also result in twice the space used (barring some very clever filesystem).
- rovr138 10y agoHe should have used --link-dest= on his rsync. PREVIOUS_BACKUP=$(cat ./prev_backup) NEW_BACKUP=$(date +%F_%T) rsync --link-dest=$PREVIOUS_BACKUP /path/source /path/dest/$NEW_BACKUP echo $NEW_BACKUP > ./prev_backup This will copy /path/source to /path/dest/$NEW_BACKUP (which is a time stamped folder). But it will take into account the previous backup. If a file hasn't changed, it will create a hard link. If it changed, it will then copy the whole file. And that's it. Since it's the name is a time stamp. When you need to restore, just read ./prev_backup or just list the directory content, sort it and read the last entry.
- derefr 10y agoThis isn't really the sync daemon's fault; it's Linux's (or rather, ext4's, and the Linux VFS ABI's) for not supporting multi-inode filesystem transactions. NTFS has them; APFS will have them. Linux should add them too.