From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: fstests@vger.kernel.org, linux-nfs@vger.kernel.org
Subject: Re: generic/495: swap on sparse file over NFS
Date: Mon, 23 Sep 2019 13:21:35 -0700 [thread overview]
Message-ID: <20190923202135.GD736475@magnolia> (raw)
In-Reply-To: <20190923200036.GA5085@fieldses.org>
On Mon, Sep 23, 2019 at 04:00:36PM -0400, J. Bruce Fields wrote:
> I'm updating to a newer xfstests and seeing:
>
> generic/495 - output mismatch (see
> /root/xfstests-dev/results//generic/495.out.bad)
> --- tests/generic/495.out 2019-09-18 17:28:00.834721480 -0400
> +++ /root/xfstests-dev/results//generic/495.out.bad 2019-09-20 13:34:01.1568
> 89741 -0400
> @@ -1,5 +1,4 @@
> QA output created by 495
> File with holes
> -swapon: Invalid argument
> Empty swap file (only swap header)
> swapon: Invalid argument
>
> If I understand correctly, it's requiring swapon to fail on a sparse
> file, which isn't going to happen on NFS, where the sparsenes of the
> file isn't really the client's concern.
It looks that way to me... :)
> Is it really correct to *require* swapon to fail in this case?
Hm. TBH I was expecting an fpunch call or something to guarantee that
we even /have/ a sparse file, since (for all we know) a filesystem could
interpret "truncate up" to imply that blocks should be speculatively
allocated all the way to the new EOF.
But no, I wouldn't expect swap-over-NFS to know or care if the file is
sparse on the server. (Based on my limited knowledge of how that even
works...)
--D
> --b.
prev parent reply other threads:[~2019-09-23 20:21 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-23 20:00 generic/495: swap on sparse file over NFS J. Bruce Fields
2019-09-23 20:21 ` Darrick J. Wong [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=20190923202135.GD736475@magnolia \
--to=darrick.wong@oracle.com \
--cc=bfields@fieldses.org \
--cc=fstests@vger.kernel.org \
--cc=linux-nfs@vger.kernel.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.