-
Notifications
You must be signed in to change notification settings - Fork 50
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
usage of write-file-atomic #183
Comments
Agreed. I believe this write-file-atomic got in for all operations because users were reporting doing multiple sequential ipfs.add and ipfs.get and although the first one succeeded, the second one failed because the files didn't have the chance to get flushed to disk. An alternative to this that will also improve perf is to have a warm in memory cache of all the recent writes so that nextTick reads hit the cache rather then having to go all the way down to the disk. |
That's interesting - it'd be good to see if this is still a problem with the latest codebase without Did a quick search of |
We need:
|
Writing file atomically is quite important for lock files and things things like that, however it should hardly be needed for all files operation. In the datastore-fs implementation, all files are written using the
write-file-atomic
module. As you can see in its source code, it does quite a few file system operations.See https://github.com/ipfs/js-datastore-fs/blob/a6fc16ab4bd4c0b5d4189591057ae45e0d239908/src/index.js#L13 where write-file-atomic is used.
I think the best goal here is to add an option to
store.put()
to note that if file should be locked or not before usage. The flag could be ignored in other storage systems.The text was updated successfully, but these errors were encountered: