inode of anonymity file

Grissiom chaos.proton at
Wed Sep 11 23:38:18 EDT 2013

On Thu, Sep 12, 2013 at 1:28 AM, <Valdis.Kletnieks at> wrote:
> On Wed, 11 Sep 2013 18:30:31 +0800, Grissiom said:
> > I found that `anon_inode_getfd` and `anon_inode_getfile` could create
> > anonymity files that I could implement my own read/write etc without both
> > writing "drivers" nor expose the structure into the file system.
> I suspect that your understanding of why anonymous files exist is a bit murky..
> > But when I dig into the source code, I fount all the files created by them
> > will share the same inode. Will it causing problems? Will other anon files
> > interfere with my own anon files? If one anon file get deleted or closed,
> > will I lost the inode of my own anon file?
> Hint:  Anonymous files basically exist only to make sure that functions that
> demand a pointer to an inode don't oops. Examples are epoll and signalfd and
> friends.
> You can't actually use an anonymous inode to reference anything on a filesystem.

Yes. I'm award of that. I've see the source code of fs/timerfd.c and
got a basic idea
of anonymous inodes. So I should re-state my question: what is the relationship
between inode and "struct file" and file descriptors?

inode and fd should be one-to-many, but how about inode and "strut file"?

And which operation on fd will affect inode? It seems read(2)/write(2)
have nothing
to do with the inode associated with the fd?

> There's also the concept of an "unlinked file", which is somewhat different.
> That's a file that is no longer listed in any directory, but still exists
> because a program still has an open file descriptor.  The unlink() system call
> removes the name/inode pair from the directory, but does not actually reap the
> inode itself until the reference count drops to zero  (because the alternative
> is ripping the file out from under the program that still has an open file
> descriptor is a lot harder than it looks).
> And of course, unlinked files don't have much long-term use either - if you
> don't use the linkat() system call to reconnect it, it's going to go bye-bye
> when your program exits....

One question about the unlinked file: if I write a lot of data into a
unlinked file, where
will the data be? On the disk or in the RAM? If the data will be on
the disk, where is it?


More information about the Kernelnewbies mailing list