-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
Add Windows native method to retrieve the number of allocated bytes on disk for file #79698
Changes from 1 commit
d13a95b
f4c5d77
8f95d7b
806f501
f109191
0ef20a0
39adb83
15abf62
d1c4f77
2af8a5a
2540f7e
ee5ab76
2d9275c
6773071
1cc458f
c6ba764
e5a0e2c
9258da1
e1aff78
c00295f
853a9de
5928b39
3357e8f
f77c0e0
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -405,10 +405,13 @@ public void testCacheFileCreatedAsSparseFile() throws Exception { | |
Long sizeOnDisk = Natives.allocatedSizeInBytes(file); | ||
assertThat(sizeOnDisk, equalTo(0L)); | ||
|
||
// write 1 byte at the last position in the cache file. | ||
// For non sparse files, Windows would allocate the full file on disk in order to write a single byte at the end, | ||
// making the next assertion fails. | ||
fill(cacheFile.getChannel(), Math.toIntExact(cacheFile.getLength() - 1L), Math.toIntExact(cacheFile.getLength())); | ||
|
||
sizeOnDisk = Natives.allocatedSizeInBytes(file); | ||
assertThat(sizeOnDisk, not(equalTo(1048576L))); | ||
assertThat("Cache file should be sparse and not fully allocated on disk", sizeOnDisk, not(equalTo(1048576L))); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should we be asserting its size is <1MiB rather than ≠1MiB? I worry that some funny rounding (e.g. counting the size of the directory entry) could pass this assertion even for non-sparse files. After we make this assertion could we fill the file with genuine data and assert that its size on disk is now ≥1MiB? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yes it is more appropriate (I think I did it and then reverted it somehow 🤔 )
Yes too. I pushed f109191 |
||
} finally { | ||
cacheFile.release(listener); | ||
} | ||
|
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.
Should we define this in
test/framework
rather thanserver
since it's not used in prod code today? Or are we planning to use it in prod later on (e.g. expose sparse sizes in stats)?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.
Personally I'd like this to be returned as part of searchable snapshot's Cache Stats API, so that we have information about the shared cache and cold cache that sit altogether. What do you think?
I can try to make it work in the test framework; it should be OK as long as the static instance is created before the security manager is installed.
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.
Also: I'd like to have assertion in
CacheFile
itself that would retrieve the allocated size on disk and compares it with the completed ranges of a cache file, and verify if size vs ranges is not completly out of bounds.That would also require the method to be in
server
. I tried to make it work in the plugin itself but for JNA kernel32 library it's very difficult given all the permissions it requires (createClassLoader, setSecurityManager etc). Linux is OK though.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.
👍 having these stats in future seems like a good plan, so I'm ok to leave the method where it is.