----- Original Message -----
> From: "Dave Chinner" <david@xxxxxxxxxxxxx>
> At one point during development of this patch set I started writing
> an xfstest to validate that mkfs did all the right input validation
> things and set parameters appropriately so that we didn't
> inadvertently change behaviour. I never really finished it off (like
> the patch set), but I've attached it below to give an idea of where
> I was going with it. It was based on validating the input and CLI
> parameters for the new code, so is guaranteed to fail on an existing
> mkfs binary.
I'm using and extending it, but I'm not sure about some tests, whether it is a
change from current behaviour, or if it is rather an issue in the test.
> +
> +# basic "should fail" options
> +# logarithm based options are no longer valid
> +do_mkfs_fail -s log=9 $SCRATCH_DEV
There are some changes in logarithm input (mkfs: validate logarithmic
parameters sanely), but it is still supported in the patches. Is there some
issue, why to remove them?
Otherwise, it should rather test for (in)valid input for log=xxx, right?
> +rm -f $fsimg
> +$XFS_IO_PROG -f -c "truncate $fssize" $fsimg
> +do_mkfs_pass -d file $fsimg
> +do_mkfs_pass -d file,name=$fsimg
> +rm -f $fsimg
> +do_mkfs_pass -d size=$fssize,file $fsimg
> +rm -f $fsimg
> +do_mkfs_pass -d size=$fssize,file,name=$fsimg
> +do_mkfs_pass -d file,name=$fsimg
Should all these inputs really pass? What is the expected behaviour for example
on -d file,name=$fsimg if the file exists, and what if there is no such file?
Cheers,
Jan
--
Jan Tulak
jtulak@xxxxxxxxxx
|