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

Clarify the type and number of Cloud Storage Operations performed by gcsfuse #853

Open
steve-marmalade opened this issue Nov 23, 2022 · 3 comments
Assignees
Labels
Eng-Backlog feature request Feature request: request to add new features or functionality p1 P1

Comments

@steve-marmalade
Copy link

Hi there,

I am trying debug a larger than expected number of Cloud Storage Class A operations, and I'm wondering if my usage of gcsfuse may explain it.

Concretely, if I mount a bucket via gcsfuse --implicit-dirs my-bucket /my-bucket and then attempt to read a file in a somewhat deeply nested directory /my-bucket/directory1/directory2/directory3/file, how many Class A Operations would you expect this to make?

I expected the answer to be 0 (just a single storage.objects.get, which is a Class B operation), but from re-reading the --implicit-dirs semantics, it looks like there will be at least one storage.objects.list.

Thanks for your help and for this useful utility.

@Tulsishah
Copy link
Collaborator

Tulsishah commented Nov 24, 2022

It is four in this case.
The number of calls is equal to the numbers of directories in the path + one for file name as mentioned here --implicit-dirs semantics

@steve-marmalade
Copy link
Author

steve-marmalade commented Nov 28, 2022

@Tulsishah , thank you very much for the response.

When I initially read the docs, I did not appreciate:

  • That list requests would be made even when I am attempting to load a specific file (as opposed to listing the contents of a directory)
    • By extension, that there would be a list request for each directory in addition to the file.
  • That storage.objects.list requests are billed differently from storage.objects.get requests (the former are more expensive)

To summarize, I did not expect there to be significant billing implications to consider when using gcsfuse, but there clearly are. This might be worth highlighting more prominently in the documentation (I certainly would have appreciated it).

@sethiay sethiay added the feature request Feature request: request to add new features or functionality label Mar 17, 2023
@sethiay sethiay added the p1 P1 label Jun 6, 2023
@ahmedetefy
Copy link

ahmedetefy commented Feb 13, 2024

I completely agree with @steve-marmalade 's sentiment on this. We also had significant billing implications with using gcsfuse because the list operations are billed as class A operations which are significantly more costly than class B operations.

This might be worth highlighting more prominently in the documentation (I certainly would have appreciated it).

+1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Eng-Backlog feature request Feature request: request to add new features or functionality p1 P1
Projects
None yet
Development

No branches or pull requests

6 participants