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

Christoph Hellwig
2023-11-29T06:02:42Z

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.