On Tue, Nov 28, 2023 at 10:02:42PM -0800, Christoph Hellwig wrote:
> 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.
Hmm. I suppose a problem with "?" is that question-mark is a valid
filename, which means that our zapped symlink could now suddenly point
to a different file that a user created. "/lost+found" isn't different
in that respect, but societal convention might at least provide for
raised eyebrows. That said, mkfs.xfs doesn't create one for us like
mke2fs does, so maybe a broken symlink to the orphanage is... well, now
I'm bikeshedding my own creation.
May I try to make a case for "🚽"? ;)
> > > > + 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.
/*
* data fork blockcount can exceed physical storage if a
* user reflinks the same block over and over again.
*/
> > > > +
> > > > + 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.
Yeah, I think this converts easily to:
if (!uid_valid(VFS_I(sc->ip)->i_uid)) {
/* zap it */
}
--D
