Hi all, 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. 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? Is seems that none of these bad things happened, but why? -- Cheers, Grissiom
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. 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....
On Thu, Sep 12, 2013 at 1:28 AM, <Valdis.Kletnieks@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
On Thu, 12 Sep 2013 11:38:18 +0800, Grissiom said:
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?
Maybe on disk, maybe in RAM, same as any other file data. Depends if the disk writeback has gotten around to flushing it yet, if anybody has done a sync() or fsync(), etc etc. It behaves exactly the same way as any other inode, except it's not in a directory. You keep writing to it, the file system will keep allocating blocks just like if it was linked, because blocks are allocated to inodes, not directory entries (and it's incredibly painful to check where (or even if) a file is linked if your file system has hundreds of millions of files on it). So basically everything that uses an inode or file descriptor will work just the same (even stuff like fchmod() even though it's sort of meaningless) - it's just things that use a pathname that no longer work for an unlinked file.
Are you talking about an orphaned inode? In that case the e2fsck utility should be able to repair your file system to remove the orphaned inode in case your file system is a standard one like ext3 / ext4 etc. If its a custom file system written by you, you may have to write a similar utility. Regards, Binoy Jayan WIPRO TECHNOLOGIES | Electronic City 5 | Bangalore | Mob: +91-9742870916, +91-9745783048 ________________________________________ From: kernelnewbies-bounces@kernelnewbies.org [kernelnewbies-bounces@kernelnewbies.org] on behalf of Valdis.Kletnieks@vt.edu [Valdis.Kletnieks@vt.edu] Sent: Thursday, September 12, 2013 9:34 AM To: Grissiom Cc: kernelnewbies@kernelnewbies.org Subject: Re: inode of anonymity file On Thu, 12 Sep 2013 11:38:18 +0800, Grissiom said:
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?
Maybe on disk, maybe in RAM, same as any other file data. Depends if the disk writeback has gotten around to flushing it yet, if anybody has done a sync() or fsync(), etc etc. It behaves exactly the same way as any other inode, except it's not in a directory. You keep writing to it, the file system will keep allocating blocks just like if it was linked, because blocks are allocated to inodes, not directory entries (and it's incredibly painful to check where (or even if) a file is linked if your file system has hundreds of millions of files on it). So basically everything that uses an inode or file descriptor will work just the same (even stuff like fchmod() even though it's sort of meaningless) - it's just things that use a pathname that no longer work for an unlinked file. Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com
On Thu, 12 Sep 2013 05:08:24 -0000, binoy.jayan@wipro.com said:
Are you talking about an orphaned inode?
No - orphaned is the state the inode ends up in if the file was open but unlinked when the system is rebooted. At that point, the inode is still there (since it was never reclaimed before the reboot) but not listed in any directory, so its reference count has indeed become zero. An unlinked inode still has a non-zero reference count (due to the open file descriptor onthe file).
participants (3)
-
binoy.jayan＠wipro.com -
Grissiom -
Valdis.Kletnieks＠vt.edu