----- 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 _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
