Added test for being able to read various variants of zstd #12030
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rincebrain
force-pushed
the
12022_zts
branch
3 times, most recently
from
67f21a6
to
b99c9d2
Compare
13 tasks
|
Well, the improbable existence of the third byte layout kept bothering me, so I tried to reproduce it with vanilla(...plus the trivial patch for sparc64) git, and found that Linux/sparc64, Linux/ppc64, and FBSD/ppc64 wrote identical encodings, so I'm forced to conclude I accidentally generated the Linux/sparc64 dataset with one of my WIP patchsets that encoded things wrong. So I've dropped it from the test pool; I can put it back if people feel like having a deliberately mangled dataset that couldn't naturally arise through any known method short of patching would be good. |
|
Well, #12022 got merged, so... |
|
Thanks for the reminder, this should be good but can you rebase it on master so we can get a fresh CI run. |
behlendorf
approved these changes
Sep 17, 2021
behlendorf
added
Component: Test Suite
As detailed in openzfs#12022 and openzfs#12008, it turns out the current zstd implementation is quite nonportable, and results in various configurations of ondisk header that only each platform can read. So I've added a test which contains a dataset with a file written by Linux/x86_64 and one written by FBSD/ppc64. Signed-off-by: Rich Ercolani <[email protected]>
rincebrain
force-pushed
the
12022_zts
branch
from
a088053
to
d57bf69
Compare
|
Sure, off it goes. |
jwk404
approved these changes
Sep 20, 2021
rincebrain
added a commit
to rincebrain/zfs
that referenced
this pull request
Sep 22, 2021
As detailed in openzfs#12022 and openzfs#12008, it turns out the current zstd implementation is quite nonportable, and results in various configurations of ondisk header that only each platform can read. So I've added a test which contains a dataset with a file written by Linux/x86_64 and one written by FBSD/ppc64. Reviewed-by: Brian Behlendorf <[email protected]> Reviewed-by: John Kennedy <[email protected]> Signed-off-by: Rich Ercolani <[email protected]> Closes openzfs#12030
rincebrain
added a commit
to rincebrain/zfs
that referenced
this pull request
Oct 2, 2021
As detailed in openzfs#12022 and openzfs#12008, it turns out the current zstd implementation is quite nonportable, and results in various configurations of ondisk header that only each platform can read. So I've added a test which contains a dataset with a file written by Linux/x86_64 and one written by FBSD/ppc64. Reviewed-by: Brian Behlendorf <[email protected]> Reviewed-by: John Kennedy <[email protected]> Signed-off-by: Rich Ercolani <[email protected]> Closes openzfs#12030
tonyhutter
pushed a commit
that referenced
this pull request
Nov 1, 2021
As detailed in #12022 and #12008, it turns out the current zstd implementation is quite nonportable, and results in various configurations of ondisk header that only each platform can read. So I've added a test which contains a dataset with a file written by Linux/x86_64 and one written by FBSD/ppc64. Reviewed-by: Brian Behlendorf <[email protected]> Reviewed-by: John Kennedy <[email protected]> Signed-off-by: Rich Ercolani <[email protected]> Closes #12030
tonyhutter
pushed a commit
to tonyhutter/zfs
that referenced
this pull request
Nov 13, 2021
As detailed in openzfs#12022 and openzfs#12008, it turns out the current zstd implementation is quite nonportable, and results in various configurations of ondisk header that only each platform can read. So I've added a test which contains a dataset with a file written by Linux/x86_64 and one written by FBSD/ppc64. Reviewed-by: Brian Behlendorf <[email protected]> Reviewed-by: John Kennedy <[email protected]> Signed-off-by: Rich Ercolani <[email protected]> Closes openzfs#12030
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As detailed in #12022 and #12008, it turns out the current zstd implementation
is quite nonportable, and results in various configurations of ondisk header
that only each platform can read.
So I've added a test which contains a dataset with a file written by
Linux/x86_64, and one written by FBSD/ppc64.
(Note that for obvious reasons, this PR will currently always fail the testbots if I implemented it correctly.)Nah, #12022 landed.Motivation and Context
#12022
Description
Added a test, compression/compress_zstd_bswap, which untars a premade sparse pool file containing 2 datasets, with different "variants" of zstd encoding used on the single file on each.
It then tries copying the files off of each dataset and dies if any of them error out.
I also added it to the "sanity" runfile.
How Has This Been Tested?
I ran it on an otherwise unmodified git master-running system, verified that it successfully copied the x86_64 file and failed the test when it EIOed on the ppc64_fbsd file.
Types of changes
Checklist:
Signed-off-by.