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

vfs: Fix multiple oversized downloaders when mounting with --vfs-read… #7719

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Dragooon
Copy link

@Dragooon Dragooon commented Apr 3, 2024

What is the purpose of this change?

I was trying to mount my remote server using rclone and wanted to use --vfs-read-ahead to smooth out files with variable bitrates. They typically average 60mb/s but can hit peaks of 120-150mb/s. However I observed having a large --vfs-read-ahead value (say 4G or 8G) would often kill performance, especially when starting the stream from middle.

When mounting with --vfs-read-ahead option, if a file is accessed at multiple offsets (for example, by a video player like Plex to read audio and video tracks) then each corresponding downloader would have the ReadAhead added to its offset, killing performance.

This fix would shrink old downloaders and only keep the latest one with enhanced offset.

Was the change discussed in an issue or in the forum before?

I posted about the issue I was facing here: https://forum.rclone.org/t/plex-seeking-slow-until-it-reads-till-vfs-read-ahead/45346 but it gained no traction.

Checklist

  • I have read the contribution guidelines.
  • I have added tests for all changes in this PR if appropriate.
  • I have added documentation for the changes if appropriate.
  • All commit messages are in house style.
  • I'm done, this Pull Request is ready for review :-)

…-ahead

When mounting with --vfs-read-ahead option, if a file is accessed at multiple offsets (for example, by a video player like Plex to read audio and video tracks) then each corresponding downloader would have the ReadAhead added to its offset, killing performance.

This fix would shrink old downloaders and only keep the latest one with enhanced offset.
@Dragooon
Copy link
Author

Dragooon commented Apr 3, 2024

I wanted to present if this fix makes any sense or if I am on the path to blow things up, if it does then I'll be happy to add any corresponding test and finish this PR.

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

Successfully merging this pull request may close these issues.

None yet

2 participants