Adjust CacheFileTests.testCacheFileCreatedAsSparseFile for encryption at rest#81527
Conversation
|
Pinging @elastic/es-distributed (Team:Distributed) |
| assertThat( | ||
| "Non default block size only used in test executed with encryption at rest", | ||
| file.toAbsolutePath().toString(), | ||
| startsWithIgnoringCase("/mnt/secret") |
There was a problem hiding this comment.
This is not great but I can't figure a better way to check that encryption at rest is used.
See
|
@elasticmachine run elasticsearch-ci/part-1 (because of #81533) |
| + cacheFile.getLength() | ||
| + ')', | ||
| sizeOnDisk.getAsLong(), | ||
| allOf(greaterThanOrEqualTo(expectedSize), lessThanOrEqualTo(expectedSize + fourKb)) |
There was a problem hiding this comment.
I wonder if we're being too prescriptive here. We don't really care how big the file is on disk (we've already checked that it's no longer too small). It's kind of nice that you can often compute the size on disk by rounding up the actual size to the next multiple of blockSize but maybe we don't even need this assertion?
There was a problem hiding this comment.
Thinking about it this morning, I do agree. Being able to round up to the next 4KB is just a consequence of generating files of 1MB max. I removed the whole assertion and just kept the /mnt/secret - with an additionnal comment.
|
Thanks David |
This test fails sometimes on CI when it is executed on encrypted filesystems: the test tries to detect the block size by writing a single byte at the end of a larger file, which should result in a single block allocated, but on encrypted filesystems it can result in more than a single block being reserved.
This commit adjusts the test so that it assumes that a default block size of 4KB is always used on Linux, and if the default block size is different then it assumes that the test is executed on an encrypted filesystem and that the allocated size stays within an upper bound.
Relates #81362 (comment)
Closes #81362