All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: linux-nvdimm@lists.01.org
Subject: Re: [ndctl PATCH] ndctl, test: kill usage of fallocate in firmware-update.sh
Date: Fri, 23 Feb 2018 14:56:22 -0700	[thread overview]
Message-ID: <20180223215622.GA3413@linux.intel.com> (raw)
In-Reply-To: <CAPcyv4izYKJ4=qxg5rGx4KOnpyb+8TakJK-ZfoEPnNV37GBF9w@mail.gmail.com>

On Fri, Feb 23, 2018 at 01:45:40PM -0800, Dan Williams wrote:
> On Fri, Feb 23, 2018 at 12:58 PM, Ross Zwisler
> <ross.zwisler@linux.intel.com> 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 <dave.jiang@intel.com>
> >> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> >> ---
> >>  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 <ross.zwisler@linux.intel.com>
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

      reply	other threads:[~2018-02-23 21:50 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-23  6:59 [ndctl PATCH] ndctl, test: kill usage of fallocate in firmware-update.sh Dan Williams
2018-02-23 20:58 ` Ross Zwisler
2018-02-23 21:45   ` Dan Williams
2018-02-23 21:56     ` Ross Zwisler [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180223215622.GA3413@linux.intel.com \
    --to=ross.zwisler@linux.intel.com \
    --cc=dan.j.williams@intel.com \
    --cc=linux-nvdimm@lists.01.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.