inode of anonymity file

[Grissiom]

On Thu, Sep 12, 2013 at 1:28 AM, <Valdis.Kletnieks at vt.edu> 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?

-- 
Cheers,
Grissiom