Code Review - CR# 7030573 insufficient disk space for large file test
The LargeFileAvailable regression test had intermittent failures when there was not sufficient space available to create a 7G temp file. This webrev presents a simple check to see if the available usable space is less than 7G and scales the test back accordingly. The original bug report suggests that the test be switched to use the current working directory rather than a temp file. I think that could be the wrong choice for an embedded system that might have the tests mounted from a remote file system. In that scenario, using the local temp file space provides a better solution for what this test is designed to check. http://cr.openjdk.java.net/~gadams/7030573/
On 23/12/2011 16:19, Gary Adams wrote:
The LargeFileAvailable regression test had intermittent failures when there was not sufficient space available to create a 7G temp file. This webrev presents a simple check to see if the available usable space is less than 7G and scales the test back accordingly.
The original bug report suggests that the test be switched to use the current working directory rather than a temp file. I think that could be the wrong choice for an embedded system that might have the tests mounted from a remote file system. In that scenario, using the local temp file space provides a better solution for what this test is designed to check.
http://cr.openjdk.java.net/~gadams/7030573/ The only thing is that when the test is scaled back too much then it no longer tests the original issue. This test will create a sparse file on file systems that support it and I suspect the reason it fails on Solaris is that tmp is backed by swap. It might be better if we changed the test to create the file in the current directory (or a sub-directory of). It will be removed by jtreg if the test doesn't delete it.
-Alan
On 01/ 5/12 08:30 AM, Alan Bateman wrote:
On 23/12/2011 16:19, Gary Adams wrote:
The LargeFileAvailable regression test had intermittent failures when there was not sufficient space available to create a 7G temp file. This webrev presents a simple check to see if the available usable space is less than 7G and scales the test back accordingly.
The original bug report suggests that the test be switched to use the current working directory rather than a temp file. I think that could be the wrong choice for an embedded system that might have the tests mounted from a remote file system. In that scenario, using the local temp file space provides a better solution for what this test is designed to check.
http://cr.openjdk.java.net/~gadams/7030573/ The only thing is that when the test is scaled back too much then it no longer tests the original issue. This test will create a sparse file on file systems that support it and I suspect the reason it fails on Solaris is that tmp is backed by swap. It might be better if we changed the test to create the file in the current directory (or a sub-directory of). It will be removed by jtreg if the test doesn't delete it.
-Alan
I've updated the webrev with the temp file created in the current directory. I'm not sure what to do about the case if there is only a little space available only a small file will be used. Should the test fail and force the test operator to create a new test environment where 7G space is available? I lean toward allowing the test to pass using the space that is available.
On 06/01/2012 19:47, Gary Adams wrote:
I've updated the webrev with the temp file created in the current directory.
I'm not sure what to do about the case if there is only a little space available only a small file will be used. Should the test fail and force the test operator to create a new test environment where 7G space is available?
I lean toward allowing the test to pass using the space that is available.
I looked briefly at the updated webrev and I see it checks the usable space on the file system/volume where the current directory is but creates the file in the temporary directory, easily done :-) I think you're right that the best we can do when there is insufficient space is just to run with the small file. It doesn't test the original issue but we don't want this test failing when there isn't sufficient space. Rather than creating largefile, deleting it, and then creating it again (twice) then how about: File file = File.createTempFile("largefile", null, new File(".")); long usableSpace = largefile.getUsableSpace(); if (usuableSpace == 0L) throw new RuntimeException(...); long size = Math.min(usableSpace, 7405576182L); recreateAsLargeFile(file, size); -Alan.
On 01/ 6/12 03:32 PM, Alan Bateman wrote:
On 06/01/2012 19:47, Gary Adams wrote:
I've updated the webrev with the temp file created in the current directory.
I'm not sure what to do about the case if there is only a little space available only a small file will be used. Should the test fail and force the test operator to create a new test environment where 7G space is available?
I lean toward allowing the test to pass using the space that is available.
I looked briefly at the updated webrev and I see it checks the usable space on the file system/volume where the current directory is but creates the file in the temporary directory, easily done :-)
I think you're right that the best we can do when there is insufficient space is just to run with the small file. It doesn't test the original issue but we don't want this test failing when there isn't sufficient space.
Rather than creating largefile, deleting it, and then creating it again (twice) then how about:
File file = File.createTempFile("largefile", null, new File(".")); long usableSpace = largefile.getUsableSpace(); if (usuableSpace == 0L) throw new RuntimeException(...); long size = Math.min(usableSpace, 7405576182L); recreateAsLargeFile(file, size);
A fresh webrev is available : http://cr.openjdk.java.net/~gadams/7030573/ Includes the following changes - moved temp file create into main - use Math.min for selecting 7G or space available and for skip size - added runtime exception if no space available - reformatting to wrap >80 column lines
On 09/01/2012 15:26, Gary Adams wrote:
A fresh webrev is available :
http://cr.openjdk.java.net/~gadams/7030573/
Includes the following changes - moved temp file create into main - use Math.min for selecting 7G or space available and for skip size - added runtime exception if no space available - reformatting to wrap >80 column lines This looks okay to me. I'll add the bugID to the @bug tag before pushing it for you.
-Alan.
participants (2)
-
Alan Bateman
-
Gary Adams