From:   Andreas Dilger <adilger@dilger.ca>
Message-Id: <69820EE9-1239-46A1-8887-ECAAA8C8C680@dilger.ca>
Content-Type: multipart/signed;
 boundary="Apple-Mail=_7153DB3F-ADE5-46CD-822B-D157EC7D4049";
 protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: NFSv4 i_blocks=0 immediately after creating a file (Was:
 inode_add/set_bytes and i_blocks, dangerous for small files?)
Date:   Sun, 3 Feb 2019 16:30:31 -0700
In-Reply-To: <20190201142830.GA2177@nautica>
Cc:     linux-nfs@vger.kernel.org, linux-fsdevel@vger.kernel.org
To:     Dominique Martinet <asmadeus@codewreck.org>
References: <20190125140229.GA5119@nautica> <20190201142830.GA2177@nautica>
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk


--Apple-Mail=_7153DB3F-ADE5-46CD-822B-D157EC7D4049
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Feb 1, 2019, at 7:28 AM, Dominique Martinet <asmadeus@codewreck.org> =
wrote:
>=20
> Following up on this for NFS as I made a sneaky bug report hard to
> notice, this might be worth having a look:
>=20
> Dominique Martinet wrote on Fri, Jan 25, 2019:
>> [...] There is a small, few seconds window
>> where I can reproduce a similar issue on nfs:
>> $ echo foo > bar; stat -c %b bar; sleep 3; stat -c %b bar
>> 0
>> 8
>> with a 4.14.87 knfsd and 4.19.15-300.fc29 client, nfs 4.2, both =
x86_64,
>> no export option or explicit client option.
>=20
> In other words, the file's i_blocks isn't updated for a short while on
> nfs v4 which might lead to data loss (see previous email for example
> e.g. tar), just create a file and immediately stat to notice.
>=20
>=20
> nfs v3 doesn't exhibit the problem.
>=20
> I also wasn't able to reproduce on the 4.14.87 machine as a and nfs v4
> client so it's likely a semi-recent regression, I could probably =
bissect
> it if really required but I'm sure someone here has some dedicated
> hardware for this better than my laptop :)
>=20
> Feel free to ask if you cannot reproduce and I'll try updating to =
master
> on both client and server just in case.

The "i_blocks =3D=3D 0" causes problems with some software that thinks =
the file
has no data and treats it as sparse.  We work around this in ext4 and =
Lustre
by always reporting i_blocks > 0 for files that have data in them (e.g.
unwritten dirty pages or inline data), see comments nin =
ext4_file_getattr():

        /*
         * If there is inline data in the inode, the inode will normally =
not
         * have data blocks allocated (it may have an external xattr =
block).
         * Report at least one sector for such files, so tools like tar, =
rsync,
         * others don't incorrectly think the file is completely sparse.
         */
        if (unlikely(ext4_has_inline_data(inode)))
                stat->blocks +=3D (stat->size + 511) >> 9;

Cheers, Andreas


--Apple-Mail=_7153DB3F-ADE5-46CD-822B-D157EC7D4049
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIzBAEBCAAdFiEEDb73u6ZejP5ZMprvcqXauRfMH+AFAlxXeZcACgkQcqXauRfM
H+CVEQ/+JMJAQBPStJIkZUWG2rFCDW5ikQB6B264SJwkI9KaAGi2HuOnBKf7UJip
C5AMEduPqnirhVQwg4xYCX9W8XXup2mzPXm+/65yCsE5XQ0NQwpZ/i++nLh9zKDB
fR5j9pGS0Kp4+JSDyz0Awbk4Qtu+dsg1ZfRNsnyJCSM1veYaUZtybRm7wOAcvz15
kZW05tYNMRfKuzwemjRz2+tfJXjoqELO8TH4sWBwaxnIdJTZB/z/+aQTlBuXVfUP
MWbCy4lj7Zo9sf6Yaq9UQlmWtj8fcwT5VK0fPQniKRbKzgUFSHZK2wBWrXYzJgOz
KkOis0FQKAem9Hd/PcpUHffUWftYB6PmlGYWtUJeJX95hSuqpv8mFq+ocxORfQCR
gFS5bkgE0Y2SqT7CDYDATMF61ZBBmB9IRnUITMkGTxtjOAeSSUD/Y1u6TaHUalaA
bSuGU/GUuoHGkyE/eW2mrnpE5dHkWYWDaSr60h+c7Yvykd1w1YG9bwlfxAjTFtbe
kRUT6dG73wTB8SWIePkFwgy7eMtwTX9+YH4fKnWWOSAKXU8BV0RjkkM7mbzCOXlG
p/skTIYocj/oWdaaGAsw0LDtZ39j35Z1xYRrv3NH0TiZA6su/9YSUefXxo0Uby5A
ib30gGEQsgYq87qOTMHcB3of2XJtC6r+Nq92SB47kpwRVLIJ05s=
=6LKd
-----END PGP SIGNATURE-----

--Apple-Mail=_7153DB3F-ADE5-46CD-822B-D157EC7D4049--