Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsequential questions about mounting #90

Closed
Gremious opened this issue Jul 6, 2024 · 3 comments
Closed

Inconsequential questions about mounting #90

Gremious opened this issue Jul 6, 2024 · 3 comments

Comments

@Gremious
Copy link

Gremious commented Jul 6, 2024

The rclone example command copyparty shows sets vendor=owncloud... any particular reason why? I don't think copyparty has anything to do with owncloud? They do have a WebDAV vendor which feels more accurate.

It also mentions that "rclone is much slower" than webdaw/davfs2 - is this true? I would have though rclone would be way faster, using a newer protocol and all? At least one random dude out there benchmarked it to be faster than davfs2, but idk if that's true for copyparty specifically?

@9001
Copy link
Owner

9001 commented Jul 6, 2024

the main reason for vendor=owncloud is so it enables useOCMtime in rclone, so files will retain their lastmodified timestamps after uploading, although canChunk might have been a cool feature to enable as well, to improve cloudflare support... would require some work on the server, so I'll make a note of that :>

as for the remark on the services page saying "you can use rclone instead, which is much slower", this is probably still true when you're transferring many small files (because davfs2 has the benefit of skipping some userspace/kernel round-trips), but rclone performance improved A LOT when it became possible to specify pacer_min_sleep=0.01ms in the rclone configs, so this may need to be benchmarked again, thx for the heads-up!

also that comparison doc is cool, think I'll spin off that and try some more combinations 👍

@Gremious
Copy link
Author

Gremious commented Jul 7, 2024

Thank you!

@9001
Copy link
Owner

9001 commented Jul 16, 2024

well, we can scrap the davfs2 recommendation -- rclone beats it out of the water, especially when there's a bit of latency. This is assuming you're on rclone v1.63 or later and using the pacer_min_sleep=0.01ms rclone option; if that's not the case, then you're back in the timeframe from when the docs were written and davfs2 was still the best choice heh

I'll update the docs when I have some more actual numbers, but it's looking like rclone being up to about twice as fast :>

EDIT: oh and rclone's webdav is WAY faster than ftp for small files (not surprising, given how crazy the ftp protocol is) -- ftp has a tiny advantage for big files, but it's not likely to apply in reality, so webdav's the way to go

@9001 9001 closed this as completed in ef0ecf8 Jul 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants