Re: [PATCH 3/7] xfs: repair inode records

[Christoph Hellwig <hch@infradead.org>]

On Tue, Nov 28, 2023 at 03:08:48PM -0800, Darrick J. Wong wrote:
> > 
> > We set the reflink flag by default, because a later stage will clear
> > it if there aren't any shared blocks, right?  Maybe add a comment to
> > avoid any future confusion.
> 
> 	/*
> 	 * For regular files on a reflink filesystem, set the REFLINK flag to
> 	 * protect shared extents.  A later stage will actually check those
> 	 * extents and clear the flag if possible.
> 	 */

Sounds good.

> > Hmm, changing a symlink to actually point somewhere seems very
> > surprising, but making it point to the current directory almost begs
> > for userspace code to run in loops.
> 
> How about '🤷'?  That's only four bytes.
> 
> Or maybe a question mark.

Heh.  I guess question marks seems a bit better, but the general idea
of having new names / different pointing locations show up in the
name space scare me a little.  I wonder if something like the classic
lost+found directory might be the right thing for anything we're not
sure about as people know about it.

> > > +	if (xfs_has_reflink(sc->mp)) {
> > > +		; /* data fork blockcount can exceed physical storage */
> > 
> > ... because we would be reflinking the same blocks into the same inode
> > at different offsets over and over again ... ?
> 
> Yes.  That's not a terribly functional file, but users can do such
> things if they want to pay for the cpu/metadata.

Yeah.  But maybe expand the comment a bit - having spent a fair amout
of time with the reflink code this was obvious to me, but for someone
new the above might be a bit too cryptic.

> > > +
> > > +	if (i_uid_read(VFS_I(sc->ip)) == -1U) {
> > 
> > What is invalid about all-F uid/gid/projid?
> 
> I thought those were invalid, though apparently they're not now?
> uidgid.h says:
> 
> static inline bool uid_valid(kuid_t uid)
> {
> 	return __kuid_val(uid) != (uid_t) -1;
> }
> 
> Which is why I thought that it's not possible to have a uid of -1 on a
> file.  Trying to set that uid on a file causes the kernel to reject the
> value, but OTOH I can apparently create inodes with a -1 UID via
> idmapping shenanigans.

Heh.  Just wanted an explanation for the check.  So a commnt is fine,
or finding a way to use the uid_valid and co helpers to make it
self-explanatory.