Date: Fri, 5 Jul 2019 15:11:25 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Alan Somers <asomers@freebsd.org> Cc: "freebsd-current@FreeBSD.org" <freebsd-current@FreeBSD.org>, "kib@freebsd.org" <kib@FreeBSD.org> Subject: Re: test program for copy_file_range(2) Message-ID: <YTXPR01MB0285DC793701FEA545B5E972DDF50@YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <CAOtMX2jXL0pOL2yTK6r2BxRT_MmCJ4ip4p2-nEEoKnBzASW1kA@mail.gmail.com> References: <YTXPR01MB02854ED77B07C7434C2F442EDDF50@YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM>, <CAOtMX2jXL0pOL2yTK6r2BxRT_MmCJ4ip4p2-nEEoKnBzASW1kA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Alan Somers wrote: >On Thu, Jul 4, 2019 at 6:38 PM Rick Macklem <rmacklem@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 interest= ed.) >> >> 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 d= ifferent 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 co= rrect >> 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 t= he 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 ou= tput file up to 6Gb of data. I could limit the "random" ranges to not copy the "big hole", but that woul= d avoid testing that case. rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YTXPR01MB0285DC793701FEA545B5E972DDF50>