The final `fsync` makes it 16 times slower

Open
#155 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
25/100
Issue type
Bug
Clarity
Needs clarification
Activity status
Stale
Tech stack
javascript
Domain
backend

Research direction

Start by tracing the writeFile path when fsync is enabled and compare it with the fsync: false path described in the report. Confirm the performance difference on macOS with a workload of more than 1,000 files, then establish and document the expected safety and performance behavior for the final fsync.

Written by the indexing model from the issue text.

Description

Bug Needs Triage
Is there an existing issue for this?
  • I have searched the existing issues
Current Behavior

I'm writing 6,700 files.
If I pass fsync: false to the options, it takes 9 seconds.
If I don't, it defaults to true, and it takes 152 seconds (!).

From the docs I see this:

If the fsync option is false, writeFile will skip the final fsync call.

Could you explain how important this final fsync call is? I'm considering to disable it.

Expected Behavior

I wish to have it faster, or understand whether it's safe to cancel the fsync.

Steps To Reproduce

try to write lots of files ( > 1000) to see the issue clearly.

Environment
  • npm: 8.1.2
  • Node: v16.13.2
  • OS: Mac OS 12.6
  • platform: Mac
Dominant language
JavaScript
Stars
256
Forks
51
PR merge metrics
No merged PRs in 30d

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from npm/write-file-atomic

All issues in npm/write-file-atomic

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.