- SiYuan的s3用数据库的格式可能确实如同某些评论所说的有丢失文件的风险，但是我觉得Remotely Save早就有了，最近才多了智能同步冲突。二哥别笑大哥。
- 现在的Remotely Save只能说是Obsidian初学者的玩具，因为文件一超过1000个，那个速度就慢的不行，完全没有用的必要，最后还得花时间转去ObsidianSync，Self-hosted Livesync ，Syncthing，而SiYuan的S3确实是有部分的风险，但是注意就没问题了，用起来不像Remotely Save只能是一个短期过渡插件，而是长期的
1 个赞
这个帖子没有提别提到S3，那就是说的官方同步。Siyuan的S3要比官方同步稳定很多
1 个赞
笔记数目到了5k，阿里云s3 用rs sync了快一分钟了，这是必须解决的问题呀
你好，假如你还在使用 rs 的话，可以先试试性能收集，看看是慢在哪一步： remotely-save/docs/check_performance/README.md at master · remotely-save/remotely-save · GitHub
你好，假如你还在使用 rs 的话，可以先试试性能收集，看看是慢在哪一步： remotely-save/docs/check_performance/README.md at master · remotely-save/remotely-save · GitHub 这里是开启性能收集的方法
我使用的是Onedrive，文件数量1k，时间也不算短了。用seafile插件不过两秒，最近livesync插件也更新了s3的beta模式，好像是将文件压缩然后再上传。另外想问问Onedrive插件的list是列出了所有的云端文件信息吗。
[startTime]: 2024-09-02T16:46:40+08:00
[start big sync func]: start
[finish step2 (list partial remote and check password)]: 5722.3ms
[finish step3 (list remote)]: 43661.8ms
[enter walk for local]: 1.7ms
[finish getting walk for local]: 0.6ms
[finish transforming walk for local]: 2.2ms
[finish walk for local]: 0.1ms
[finish step4 (list local)]: 0.3ms
[finish step5 (prev sync)]: 189.5ms
[ensembleMixedEnties: enter]: 1.5ms
[sizeof localEntityList]: 0.3ms, size=169932
[sizeof prevSyncEntityList]: 4.5ms, size=349092
[sizeof remoteEntityList]: 5.6ms, size=333330
[ensembleMixedEnties: finish remote]: 158.9ms
[sizeof finalMappings]: 0.3ms, size=479546
[ensembleMixedEnties: finish prevSync]: 69.9ms
[sizeof finalMappings]: 0.3ms, size=833858
[ensembleMixedEnties: finish local]: 85.4ms
[sizeof finalMappings]: 0.2ms, size=1175394
[ensembleMixedEnties: exit]: 15.2ms
[finish step6 (build partial mixedEntity)]: 0.1ms
[getSyncPlanInplace: enter]: 0ms
[getSyncPlanInplace: finish sorting]: 0.8ms
[sizeof sortedKeys]: 0.1ms, size=69624
[sizeof sortedKeys in the beginning of i=0]: 0.1ms, size=1175394
[sizeof sortedKeys in the beginning of i=100]: 13.5ms, size=1177594
[sizeof sortedKeys in the beginning of i=200]: 12.2ms, size=1179794
[sizeof sortedKeys in the beginning of i=300]: 11.8ms, size=1181994
[sizeof sortedKeys in the beginning of i=400]: 11.9ms, size=1184194
[sizeof sortedKeys in the beginning of i=500]: 11.7ms, size=1186394
[sizeof sortedKeys in the beginning of i=600]: 11.7ms, size=1188594
[sizeof sortedKeys in the beginning of i=700]: 12.9ms, size=1190794
[sizeof sortedKeys in the beginning of i=800]: 13ms, size=1193054
[sizeof sortedKeys in the beginning of i=900]: 12.6ms, size=1195254
[sizeof sortedKeys in the beginning of i=1000]: 12.6ms, size=1201036
[getSyncPlanInplace: finish looping]: 13.9ms
[getSyncPlanInplace: exit]: 13.3ms
[sizeof mixedEntityMappings in the end of getSyncPlanInplace]: 0.1ms, size=1201722
[finish building full sync plan]: 12.7ms
[finish writing sync plan]: 77.7ms
[finish step6 (make plan)]: 0.3ms
[doActualSync: enter]: 2.3ms
[doActualSync: finish splitting steps]: 5.9ms
[doActualSync: sizeof onlyMarkSyncedOps]: 0.1ms, size=1191340
[doActualSync: sizeof folderCreationOps]: 19.6ms, size=0
[doActualSync: sizeof realTotalCount]: 0ms, size=1980
[doActualSync: step 0 start]: 0.1ms
[doActualSync: step 0 end]: 39.4ms
[doActualSync: step 1 start]: 0.2ms
[doActualSync: step 1 end]: 0.2ms
[doActualSync: step 2 start]: 0.1ms
[doActualSync: step 2 end]: 26.5ms
[doActualSync: step 3 start]: 0.2ms
[doActualSync: step 3 end]: 4086.2ms
[doActualSync: exit]: 0.4ms
[finish step7 (actual sync)]: 0.1ms
[finish syncRun]: 0.1ms
是的，你这里列出耗费了50多秒。
livesync 用了另一种模式。
要不要考虑下s3这样的需要列出所有文件状态的存储改成livesync的模式，压缩成几个主要的块然后对比块的状态来同步，否则md文件过多同步实在太慢，至于附件则直接同步。如果是Onedrive或者dropbox这样的在库文件夹层次可以获取最新更改状态的网盘则直接获取修改了文件信息而不用直接列出所有文件，这样能兼顾效率和可修改性。
作者你好！最近更新后remotely save插件遇到几个问题：设置的双向同步，我同步的时候出现设备A删除文件夹，然后同步，设备B同步（文件夹未删除），设备A再同步，出现删除的文件又恢复的现象，这个怎么解决？还有我移动了文件到文件夹之后，同步会出现重复文件
老哥你的Remotely Save +OneDrive如果换成S3应该会快很多，不管是RS还是Liveysnc。
你有时间的话可以试试 是Remotely Save的S3快还是self-hosted Livesync的S3快。
我目前没什么时间，目前还是用Livesync的CouchDB。
livesync的s3我弄不明白那玩意，没办法用阿里云的oss，但是可以用aws、r2、b2的s3，所以不太好拿国内的测试，毕竟才刚刚beta版本
有需要官方同步的可以站内私信我，合租的一年大概60-80左右，最好是能使用tg交流。
Obsidian用remotely save同步5000个文件，同步成功后你用的这个星期也是几秒同步完成的。
但是，用着用着，文件修改时间和云端不再统一。然后同步会分成两步，验证文件时间不一致，下载到缓存进行内容判断，发现文件一致，跳过此文件（然后此文件时间还是不一致）。
造成需要下载的文件越来越多。
一年前吧，也是这种情况，而且对象存储同步没有统一的版本节点，没法整体回滚，后来就用Git了。速度不错，每次同步可以添加描述，方便回滚，就是免费容量小，不过我的用法十年八年的没啥问题
如果内容没有修改的话，为什么文件时间会发生变化呢？按道理，“下载后判断缓存”应该会更新文件时间的缓存，下次会直接判断相等。