-
Notifications
You must be signed in to change notification settings - Fork 55
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
Allow specifying integrity metadata reservation on pool creation #3733
Allow specifying integrity metadata reservation on pool creation #3733
Conversation
Congratulations! One of the builds has completed. 🍾 You can install the built RPMs by following these steps:
Please note that the RPMs should be used only in a testing environment. |
cb519dd
to
18b1495
Compare
Help text for integrity size spec for file size predictor is:
stratis-cli would do the same. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just one comment.
) -> Sectors { | ||
Bytes(4096).sectors() | ||
+ journal_size | ||
+ Bytes::from(((*total_space.bytes() / *block_size) * *tag_size + 4095) & !4095).sectors() | ||
+ Bytes::from( | ||
(((((total_space.bytes() / block_size) * u128::from(tag_size.as_bits())) / 8 + 7) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm struggling to understand the logic of rounding up to the nearest byte if we're representing this as bits. This seems to defeat the purpose of representing it as bits in the first place. Could you explain a little bit more what you're trying to do here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The 4095 in the expression '+4095 & !4095' is implicitly in units of bytes. If I don't round up, then the value for the tag space may underestimate by 7 the number of bits required. If, by a weird chance, that underestimate is also divisible by 4096, then the total allocation for integrity metadata is nicely aligned but up to 7 bits short of what might be required.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is another reason why the units would make more sense in bytes. The best case scenario is that we end up overestimating in a way that rounds to Mo8 hash sizes no matter what so this does not seem like we are getting anything from representing it as bits.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would be happy to change the order of operations. Instead of multiplying the number of blocks by the bits value and then rounding up to the nearest byte, rounding the bits value up to the nearest byte and multiplying it by the number of blocks. Of course, that has no effect at this point on the computation's result.
What I think would be shortsighted at this point is limiting our D-Bus API and our pool-level metadata to allow only units of bytes.
I'll make the proposed change.
743c737
to
2714a96
Compare
Pool metadata snippet, accepting all defaults:
|
4b876fb
to
9437326
Compare
New metadata snippet:
|
If
I think that is acceptable as regards the format of the integrity meta spec, but the |
Better metadata snippet on
|
stratis-printmetadata snippet:
|
Sample error:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just one comment. Other than that, I'm okay with the changes.
// b: true if the superblock reservation is supposed to be done | ||
// | ||
// Rust representation: (bool, bool) | ||
.in_arg(("allocate_superblock", "(bb)")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you explain a bit more why you chose to have an optional boolean data type? I feel like this would be better handled by just a boolean type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Per our discussion in stand up, I'm okay with allowing an option to specify using a default for D-Bus users.
f565c58
to
c3b486c
Compare
Specify default integrity journal size in parser as string value. Signed-off-by: mulhern <[email protected]>
Define an enum to represent the tag size. Store the IntegrityTagSpec value in the pool-level metadata. Nothing is gained by turning the enum into bits before storing it in the pool-level metadata. Have the string representation in the pool metadata match that for D-Bus API. Compute using the bytes value that is at least as large as the number of bits the tag spec represents. Use tag_spec instead of tag_size for the name of the field in the CreatePool method. Signed-off-by: mulhern <[email protected]>
Combine both current specs in the struct. The default of both fields is None. Signed-off-by: mulhern <[email protected]>
Use ValidatedIntegritySpec for serialization and to pass to methods invoked by engine's create_pool method. Signed-off-by: mulhern <[email protected]>
This is an option in the D-Bus, the predict script and the pool-level metadata. Signed-off-by: mulhern <[email protected]>
Signed-off-by: mulhern <[email protected]>
Signed-off-by: mulhern <[email protected]>
The error will print out its own description of itself as an error, so this extra error text is redundant. Signed-off-by: mulhern <[email protected]>
c3b486c
to
eec882a
Compare
rebased, some minor squashing |
Related stratis-storage/project#746