Re: test program for copy_file_range(2)

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).
-Alan