You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Stop creating lock files in the filestore for each read operation #1372
The server currently, to read a file, creates a lock file (like /favicon.ico.lock directory) reads the file,(like /favicon.ico) and then delets the lock file.
This is a bad idea for more than reason.
The server won't run on a read-only file system.
Files can't be read if the server user isn't allowed access to the the directory above them ( eg read access to say /favicon.ico needs write access to / )
The file system, depending on its technology, may wear down the device, reduce its life.
Much the speedup one gets from layers of caching is pointless as the server has to do the round tripe s with the file system itself.
Suggested fixes: Both:
Switch the file-based lock to an in-memory JS variable lock.
Check the access of a file, and if no write access is allowed by anyone, then assume file will not change. In that case, remove the lock completely on read, so many threads can stream in parallel .
Note that if processes are reading it at the same time that is fine. They can be concurrent but must block out writers. Writers can only be one at a time. ((bosons and fermions?))
Handling a case of multiple users streaming the same file at the same time is actually a use case, if for example they are synchronized audio playback channels.
Activity
jaxoncreed commentedon Dec 9, 2019
I think I like the in-memory JS variable the best
timbl commentedon Jan 27, 2020
Me too.
See also by the way #1397
timbl commentedon Jan 27, 2020
Note that if processes are reading it at the same time that is fine. They can be concurrent but must block out writers. Writers can only be one at a time. ((bosons and fermions?))
Handling a case of multiple users streaming the same file at the same time is actually a use case, if for example they are synchronized audio playback channels.
timbl commentedon Jan 27, 2020
So the current issue is a bug that files cannot be accessed by multiple clients at the same time.
jaxoncreed commentedon Jan 28, 2020
Okay, I believe this can be re-labeled.
timbl commentedon Jan 30, 2020
Yes, it is a bug in the logic as well as causing undue wear on the disk. (The latter is also relevant -- see eg https://www.cnet.com/how-to/how-ssds-solid-state-drives-work-increase-lifespan/ ... the number of times you can write to an SSD is limited more than the number of times you can read. )