Re: test program for copy_file_range(2)

Alan Somers wrote:
>On Fri, Jul 5, 2019 at 9:11 AM Rick Macklem <rmacklem_at_uoguelph.ca> wrote:
>>
>> Alan Somers wrote:
>> >On Thu, Jul 4, 2019 at 6:38 PM Rick Macklem <rmacklem_at_uoguelph.ca> wrote:
>> >>
>> >> I have a little program for testing the copy_file_range(2) syscall I've been
>> >> working on. (The current version is attached, in case anyone is interested.)
>> >>
>> >> It take a few minutes to run on a slow system and uses about 6Gbytes of disk
>> >> space for the file system the output file is on. (It creates 2 files to use for testing.
>> >> The first one is sparse and the second is copied from it, but grows as different byte
>> >> ranges get copied, since "punching holes" is done via writes of 0 bytes.)
>> >>
>> >> My question is..
>> >> What needs to be done to include this in FreeBSD?
>> >> I see some stuff under head/tests. I could probably figure out
>> >> what the macros in those files are, but I can only see tests to see if
>> >> arguments are valid and similar. As such, I'm not sure if this is the correct
>> >> place for a test like this?
>> >>
>> >> Thanks for any help with this, rick
>> >
>> >head/tests is for complete automated tests, mostly in ATF format.
>> >Your program sounds more like the kind of helper program that might be
>> >more suitable for head/tools/regression.  Those programs all require
>> >some operator interaction.  If you can automate your program then we
>> >should add it to head/tests/sys.  Does it really need 6GB to get
>> >decent test coverage?
>> Well, I wanted the input file to exceed 4Gb and to have a > 4Gb hole in it, to catch
>> 32bit bugs (I test on i386). This did catch some problems during testing.
>>
>> Then, the program copies (random) ranges of the file to a second file. If the random
>> copy is done over the "big hole" for the case where it hasn't truncated the output
>> file (every second iteration), then it writes a "lot of 0s", growing the output file
>> up to 6Gb of data.
>>
>> I could limit the "random" ranges to not copy the "big hole", but that would avoid
>> testing that case.
>>
>> rick
>
>random ranges are another problem.  Automated tests shouldn't use
>random behavior, because then failures won't be reproducible.  It's
>best to test a set of hand selected edge cases.  If you're going to
>test random ranges too, then the program should use a user-selectable
>random seed (perhaps seeding from the timer if the user doesn't
>specify a seed, and printing the seed that was chosen).
Good points. Now, I'm about as far from an expert on testing as they come, but
the problem in this case is that I have already written the code to handle the
edge cases I recognized. (Ideally the guy who writes the test program isn't the
guy who wrote the code, but...)

By doing the "random" stuff, I am hoping to catch cases that I hadn't anticipated.
(I put the "random" in quotes, since I use random(3) without seeding it, so I
 actually get the same reproducible results.)
I crank the # of cycles up so that it runs for hours/days/weeks.

I do agree I should add some specific edge cases (which I have already checked)
to the test program.

rick