On Fri, Jul 5, 2019 at 9:11 AM Rick Macklem <rmack...@uoguelph.ca> wrote: > > Alan Somers wrote: > >On Thu, Jul 4, 2019 at 6:38 PM Rick Macklem <rmack...@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 _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
