inode of anonymity file
chaos.proton at gmail.com
Wed Sep 11 23:38:18 EDT 2013
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
> 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)
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