Re: libc bump subproject
:>
:> * Bump ino_t (and thus stat.st_ino and dirent.d_fileno and
:> others) to 64 bits. This has been needed for a very long
:> time. (If I thought I could get away with making it 128
:> bits I would).
:
:Please bump dev_t to 64 bits while you are at it. This may seem
:excessive for most situations, but it makes sense for some kinds
:of distributed filesystems, such as OpenAFS. I'm still hoping to
:do that for FreeBSD (for 6.0-release?), although I haven't made
:any noises about it recently.
dev_t (well, __dev_t and udev_t from the kernel's point of view)
is a bit harder to handle, we might actually have to rename a few
system calls to do that safely (e.g. mknod() -> mknod64()). It has
the same problem that off_t had when it went from 32 to 64 bits
(many years ago).
:> * Bump nlink_t (and thus stat.st_nlink) to 32 bits.
:>
:> * Bump stat.st_gen to 64 bits. This has also been needed for
:> a very long time.
:
:Hmm. What does this field keep track of? (I see that the include
:file says "file generation number", but what does that mean in a
:practical sense?) I don't think I have ever seen it used.
Its the generation number for the inode... it allows you to tell
if the inode has been reused for another purpose (e.g. you remove
a file and sometime later create a new file that reuses that inode).
-Matt
Matthew Dillon
<dillon@backplane.com>
討論串 (同標題文章)
完整討論串 (本文為第 5 之 14 篇)：