Skip to content

Stop creating lock files in the filestore for each read operation #1372

Closed

Description

@timbl

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 .

Activity

  1. jaxoncreed commented on Dec 9, 2019

    @jaxoncreed
    Contributor

    I think I like the in-memory JS variable the best

  2. timbl commented on Jan 27, 2020

    @timbl
    ContributorAuthor

    Me too.
    See also by the way #1397

  3. timbl commented on Jan 27, 2020

    @timbl
    ContributorAuthor

    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.

  4. timbl commented on Jan 27, 2020

    @timbl
    ContributorAuthor

    So the current issue is a bug that files cannot be accessed by multiple clients at the same time.

  5. jaxoncreed commented on Jan 28, 2020

    @jaxoncreed
    Contributor

    Okay, I believe this can be re-labeled.

  6. timbl commented on Jan 30, 2020

    @timbl
    ContributorAuthor

    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. )

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions