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.
