On Fri, Feb 23, 2018 at 01:45:40PM -0800, Dan Williams wrote: > On Fri, Feb 23, 2018 at 12:58 PM, Ross Zwisler > <[email protected]> wrote: > > On Thu, Feb 22, 2018 at 10:59:22PM -0800, Dan Williams wrote: > >> The 'fallocate -l 196608 $image' step in the test fails when $image is > >> on an NFS mount. Use dd instead to create a sparse file. We do not need > >> to allocate anything since we are only writing zeros. > >> > >> Cc: Dave Jiang <[email protected]> > >> Signed-off-by: Dan Williams <[email protected]> > >> --- > >> test/firmware-update.sh | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/test/firmware-update.sh b/test/firmware-update.sh > >> index 0d5bcdb3cc42..173647218c28 100755 > >> --- a/test/firmware-update.sh > >> +++ b/test/firmware-update.sh > >> @@ -49,7 +49,7 @@ detect() > >> > >> do_tests() > >> { > >> - fallocate -l 196608 $image > >> + dd if=/dev/zero of=$image bs=1 count=1 skip=196607 > >> $ndctl update-firmware -d $dev -f $image > >> } > > > > Hmm, I'm not seeing this failure in my NFS based setup. Out of curiosity, > > do > > you know why it's failing? Some difference in our NFS configs? > > Probably, here are my mount options: > > root on / type nfs4 > (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.100.127,local_lock=none,addr=192.168.100.1) > > > Anyway, this seems fine, but > > > > fallocate -l 196608 $image > > > > does the same thing and seems a little simpler, IMO. > > Not simpler if it randomly fails depending on the filesystem, and > there is no need to allocate that space since we're just creating a > file full of zeros.
sorry, I meant "truncate -s 196608 $image". Anyway, this is fine with either dd or truncate. I agree that not actually reserving filesystem space is a win. Reviewed-by: Ross Zwisler <[email protected]> _______________________________________________ Linux-nvdimm mailing list [email protected] https://lists.01.org/mailman/listinfo/linux-nvdimm
