From:   Andreas Dilger <adilger@dilger.ca>
Message-Id: <A5DD4B7A-A3AE-4A00-943A-A35D98204764@dilger.ca>
Content-Type: multipart/signed;
 boundary="Apple-Mail=_373B4ECC-B75A-4064-9573-2ADA909BD5DF";
 protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: [PATCH] ext4: compare inode's i_projid with EXT4_DEF_PROJID
 rather than check EXT4_INODE_PROJINHERIT flag
Date:   Thu, 16 Dec 2021 17:17:28 -0700
In-Reply-To: <20211214050636.GE279368@dread.disaster.area>
Cc:     Roman Anufriev <dotdot@yandex-team.ru>,
        "Theodore Y. Ts'o" <tytso@mit.edu>,
        linux-ext4 <linux-ext4@vger.kernel.org>, Jan Kara <jack@suse.cz>,
        wshilong@ddn.com, Dmitry Monakhov <dmtrmonakhov@yandex-team.ru>,
        "Darrick J. Wong" <darrick.wong@oracle.com>
To:     Dave Chinner <david@fromorbit.com>
References: <1638883122-8953-1-git-send-email-dotdot@yandex-team.ru>
 <alpine.OSX.2.23.453.2112071702150.70498@dotdot-osx>
 <Ya+3L3gBFCeWZki7@mit.edu>
 <alpine.OSX.2.23.453.2112102232440.94559@dotdot-osx>
 <20211214050636.GE279368@dread.disaster.area>
Precedence: bulk


--Apple-Mail=_373B4ECC-B75A-4064-9573-2ADA909BD5DF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Dec 13, 2021, at 10:06 PM, Dave Chinner <david@fromorbit.com> wrote:
> On Fri, Dec 10, 2021 at 10:55:10PM +0300, Roman Anufriev wrote:
>>=20
>> On Tue, 7 Dec 2021, Theodore Y. Ts'o wrote:
>>=20
>>> On Tue, Dec 07, 2021 at 05:05:19PM +0300, Roman Anufriev wrote:
>>>>> Commit 7ddf79a10395 ("ext4: only set project inherit bit for =
directory")
>>>>> removes EXT4_INODE_PROJINHERIT flag from regular files. This makes
>>>>> ext4_statfs() output incorrect (function does not apply quota =
limits
>>>>> on used/available space, etc) when called on dentry of regular =
file
>>>>> with project quota enabled.
>>>=20
>>> Under what circumstance is userspace trying to call statfs on a file
>>> descriptor?
>>>=20
>>> Removing the test for EXT4_INODE_PROJINHERIT will cause
>>> incorrect/misleading results being returned in the case where we =
have
>>> a directory where a directory hierarchy is using project id's, but
>>> which is *not* using PROJINHERIT.
>>=20
>> I'm not sure I quite understood what will be wrong in that case, =
because
>> as Dave mentioned:
>>=20
>>> PROJINHERIT just indicates the default projid that an inode is
>>> created with; ...
>=20
> Directory inodes can have a project ID set without PROJINHERIT, it
> just means they are accounted to that specific project and have no
> special behaviour w.r.t. newly created children in the directory.
> i.e. without PROJINHERIT, all children will be created with a
> proj ID of zero rather than the projid of the parent directory.
>=20
> i.e. I can do `xfs_io -c "chproj -R 42" /mnt/test` and it will set
> all filesystem and directories to have a projid =3D 42, but
> PROJINHERIT is not set on any directory. The tree gets accounted to
> project 42, but it isn't a directory tree quota - it's just a user
> controlled aggregation of random files associated with the same
> project ID.
>=20
> Hence the statfs behaviour of "report project quota limits for
> directory tree" should only be triggered if PROJINHERIT is set on
> the directory, because that's the only viable indicator that
> directory tree quotas *may* be in use on the filesystem.

Sure, I think the question is if statfs() is called on a regular
file in a parent directory with PROJINHERIT set (which is easily
checked) should it return the project limits in the same way as
if statfs() is called on the directory itself?

It seems inconsistent for that statfs("/home/adilger/file") returns
full-filesystem information, but statfs("/home/adilger") and
statfs("/home/adilger/dir") would return project information, if
PROJINHERIT are set on "adilger/" and "dir/".  It kind of ruins
the "tree" aspect, especially for processes that are in a container
that has limits on the subdirectory it is mounting.

Cheers, Andreas


--Apple-Mail=_373B4ECC-B75A-4064-9573-2ADA909BD5DF
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

iQIyBAEBCAAdFiEEDb73u6ZejP5ZMprvcqXauRfMH+AFAmG71xgACgkQcqXauRfM
H+DAwA/4ndb0wtMjoRty4GP3UNmL/IAAmdt5cOpHbbgJ7kbVczo6fZ7T06GProjD
TGjA40UXjepVEIvEjd8fCPnu4YvWaNWmMbtGHZQBkQrf5aTLb91+Pmv7nQy+CV9l
gd85rbCrtpXwQkiUgwRiQYzIQA+6Vnc5oKtYIOi3ZdKSi4KreFdmUT1y904XVA8b
Fr902hWPz89tuODZY+ABRL8jS6ybOpLYbJSxxeaqPeXZBxDje1xXrIzg/5GMpGhE
8taYmp7RGjx64jbNGIN8XEqTBmWI/GFoMRMGuJkbkEgQdy/PzvLoTSJuZC2FTaoB
Xlm2mCpQXwfRNoMN/Tr1SftoxLedqh/Ijd51oyizOlZagFbfOD1dtQJbItR9nvTC
kPdSgdu1oXkvHCA23+vYvBCBVFQYCqg7408TERWkB2jZpp1we9XPcljgUFi1YYlv
sTpXZUaO1WqSdBEpJk3J1atCDhaxcIpJ3autGegTxM16xP+Ol7X+ZZQfEI4tSfMD
Vn/e5jWOKH2Enz468+7QEeXDzmtndYwNSQ7tGuLzuHK9rhqb8Sr/by0nGb6yFRcK
qtTM4xN2LyNZ3n1xlRclBa6gmMAOJh64RUF3UAdvAUF1cIZfokpf7XsgY+nl+PFS
bfgOOILBUjFNce1Tl/kd90pqjWgzNeBdqpHn9qKu0k3EupWhkg==
=hBxc
-----END PGP SIGNATURE-----

--Apple-Mail=_373B4ECC-B75A-4064-9573-2ADA909BD5DF--