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

Fix "illegal operation on a directory, realpath" on RAM Disk #229

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

duykhang53
Copy link

The native method of fs.realpath() cause error on RAM Disk created by imDisk.

Angular developers might get this error when running ng s on RAM Disk when they using scss in their project

From tracing in postcss-import, I got EISDIR: illegal operation on a directory, realpath 'R:\angular-project'.
image

For the fix, fs.realpath.native() will fallback to fs.realpath() if errno is illegal operation(-4068).

Copy link
Member

@ljharb ljharb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we need this complexity, let's please add a regression test.

Comment on lines +10 to +16
fs.realpath.native(path, function (realpathErr, realPath) {
if (realpathErr && realpathErr.errno === -4068) {
fs.realpath(path, callback);
} else {
return callback(realpathErr, realPath);
}
});
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this means we pay a performance cost every time. is this necessary, or on a given system where it fails, will it always fail?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This code is designated for the postcss-import on RAM Disk. This means the I/O speed is significantly improved. The production build of my Angular project takes 60-120 secs with fs.realpath.native() on my 2TB Seagate FireCuda SSHD but it only takes ~60 secs on RAM Disk mounted by imDisk with fs.realpath() (where fs.realpath.native() is illegal operation). So in general, no performance costs are paid.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure how that's possible - this is always calling realpath.native, and when it errors, is adding the cost of calling realpath.

(to be clear, I have no idea what imDisk is, and the last time I heard anything about RAM Disks was in the late 1990s)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

imDisk is a software to create a virtual disk using RAM on Windows: https://imdisk.en.lo4d.com/windows

The cost of calling is the trade-off for I/O speed and it only adding the call on illegal operation error.

You can clone this repository using Windows on both RAM Disk created by imDisk and your HDD/SSHD/SSD https://github.com/scttcper/ngx-toastr. After the clone, run npm i && npm start. On RAM Disk, the server will fail and you will get
image

The cause is from postcss-import using this repository to resolve the imported files from node_modules in src/style.scss. So if you alter ./node_modules/resolve/lib/async.js, the error is gone.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm concerned about:

  1. adding a fix without a regression test, because there's no protection from breaking it again
  2. adding a complicated fix that might slow down the majority case to service a very niche edge case

@SimenB
Copy link
Contributor

SimenB commented Oct 3, 2020

I wonder if node can do something to improve the native realpath. The promise api uses the native implementation under the hood (https://nodejs.org/api/fs.html#fs_fspromises_realpath_path_options), so it'll probably become more prevalent

@duykhang53
Copy link
Author

@SimenB promise APIs don't do the trick, EISDIR still occurred

image

@SimenB
Copy link
Contributor

SimenB commented Oct 4, 2020

@duykhang53 that makes sense - it's the same API. My point was that it shouldn't be up to consumers to deal with these issues, it should be fixed upstream in Node itself.

@duykhang53
Copy link
Author

This issue occurred since node v6 and now it's v14.
nodejs/node#6861

I think it's better to apply a fallback rather than wait for nodejs to fix it.

Cost of calling just slightly affected the performance but that would be better to make the code run instead of throwing errors.

@ljharb
Copy link
Member

ljharb commented Oct 5, 2020

@duykhang53 the last comment in that issue, nodejs/node#6861 (comment), suggests that the proper solution is to abandom imdisk in favor of aim_ll.

@last-Programmer
Copy link

you can use osfmount and mount as physical drive and it works out of the box.

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

Successfully merging this pull request may close these issues.

4 participants