RFC: patch to make d_fileno 64bits

[Rick Macklem]

Gleb Kurtsou wrote:
> On (21/11/2014 10:25), John Baldwin wrote:
> > On Thursday, November 20, 2014 10:19:14 PM Rick Macklem wrote:
> > > The attached patch covers the basics of a way to
> > > convert the d_fileno field of "struct dirent" to
> > > 64bits. This patch is incomplete and won't even
> > > build, but I thought I'd post it in case anyone
> > > wanted to take a look and comment on the approach
> > > it uses.
> > > 
> > > - renames the old/current one "struct dirent32"
> > > - changes d_fileno to 64bits and adds a 64bit
> > >   d_off field for the offset of the underlying
> > >   file system
> > > - defines a new VOP_READDIR() that will return
> > >   the new "struct dirent" that is used as the
> > >   default one for a new getdirentries(2).
> > > - the old/current getdirentries(2) uses the old
> > >   VOP_READDIR32() by default.
> > > 
> > > For the case of a file system that supports both
> > > the new and old VOP_READDIR(), they are used by
> > > the corresponding new and old getdirentries(2)
> > > syscalls.
> > > 
> > > For a file system that only supports one of
> > > the VOP_READDIR()s, the "struct dirent32"
> > > is copied to "struct dirent" (or vice versa).
> > > 
> > > At this point, all file systems would support
> > > the old VOP_READDIR() and I think the new
> > > VOP_READDIR() can easily be added for NFS,
> > > ZFS. (OpenBSD already has UFS code for
> > > essentially a new struct dirent and hopefully
> > > that code could be ported easily, too.)
> > > 
> > > Anyhow, any comments on this approach? rick
> > 
> > I think this is already done (along with several other changes)
> > more fully in
> > the projects/ino64 branch in svn?
> 
> projects/ino64 was created by mdf for merging GSoC commits, and it
> didn't even get half way through.
> 
> I'm currently working on merging the code to CURRENT. It's been more
> than 2 years, so there is quite some work in there. I intend to
> update
> the branch as soon as code is ready for review.
> 
Btw, I just took a quick look and I didn't find any changes to "struct dirent"
in projects/ino64, so I think my original assumption that this piece of the
puzzle hadn't yet been solved, is correct. (Gleb, if you had changes to
"struct dirent" and related fs changes, please let me know.)

Oh, and thanks to some comments, the new struct dirent has already changed to:

struct dirent {
   __uint64_t  d_cookie; /* dir cookie for next dir entry */
   __uint64_t  d_fileno;
   __uint16_t  d_reclen;
   __uint8_t   d_type;
   __uint8_t   d_namlen;
   __uint8_t   d_pad[4]; /* align d_name to 8 byte boundary */
   __uint8_t   d_name[MAXNAMLEN + 1];
};

It was pointed out that C would pad the structure to a multiple of 8 bytes
for some arches and without d_pad that would imply d_name wasn't at the end
of the structure. (Apparently code somewhere find d_name by subtracting MAXNAMLEN + 1
from sizeof(struct dirent) and this fails if d_name isn't at the end. Yuck,
but the above fixes it.)

However, the size of d_namlen could become uint16_t, if anyone thinks MAXNAMLEN
might want to be greater than 255 someday (long away, since that's another ABI change).

rick

> Besides branch also changes dev_t to 64-bit, bumps MNAMELEN to 1024
> and
> has complete ABI compatibility shims (probably except openaudit which
> had
> issues).
> 
> 
> _______________________________________________
> freebsd-fs at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"
>