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: polishing tmp fs and s3 fs #444

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

fix: polishing tmp fs and s3 fs #444

wants to merge 36 commits into from

Conversation

nyannyacha
Copy link
Collaborator

@nyannyacha nyannyacha commented Nov 18, 2024

What kind of change does this PR introduce?

Enhancement

Description

This PR is a follow-up to previous #429, finalizing the s3fs implementation and adding integration tests and testing in CI.

@@ -534,6 +541,9 @@ globalThis.bootstrapSBEdge = (opts, extraCtx) => {
'writeTextFile': true,
'readFile': true,
'readTextFile': true,
'mkdir': true,
'makeTempDir': true,
Copy link
Contributor

Choose a reason for hiding this comment

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

hmm..how would makeTempDir works? Does it end up reusing the /tmp configured for the worker? and what if tmpFs is disabled?

Copy link
Collaborator Author

@nyannyacha nyannyacha Nov 19, 2024

Choose a reason for hiding this comment

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

hmm..how would makeTempDir works?

This is tied to the current context: if the path in the actual file system of tmpfs is /tmp/.xmeow, then the result of makeTempDir must be /tmp/.xmeow/.xmeowmeow.

and what if tmpFs is disabled?

Currently, tmpfs is unconditionally set to be enabled, but if it is not, FsError::Unsupported will be returned by prefixfs.

Copy link
Contributor

Choose a reason for hiding this comment

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

so I assume the dir option in makeTempDir has no effect? But users can provide prefix and suffix? https://docs.deno.com/api/deno/~/Deno.MakeTempOptions

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I'll show you how this works with a screencast shortly.

arg!(--"request-buffer-size" <BYTES>)
.help("The buffer size of the stream that is used to forward a request to the worker")
.value_parser(value_parser!(u64))
.default_value("16384"),
Copy link
Contributor

Choose a reason for hiding this comment

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

I noticed when the flag isn't set, server defaults to 1KiB. Should that be changed to 16KiB as well?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I noticed when the flag isn't set, server defaults to 1KiB. Should that be changed to 16KiB as well?

I don't think there is a good default value for this, all I can tell you is that making it too small will increase the amount of wasted user worker CPU time because the buffer will have to be emptied from time to time if the request is too large.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Prior to this PR, this value was fixed at 1024 bytes, and I suspect that the amount of CPU time lost when requests with very large payloads were sent was not small.

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

Successfully merging this pull request may close these issues.

2 participants