Readers Speak Out: Letters to the editor

Inside Solaris: "Fiddling around with files, part one" by Jim Mauro

http://www.sunworld.com/sunworldonline/swol-02-1998/swol-02-insidesolaris.html

What's really happening inside solaris?

Jim,

I loved your column in last month's issue, but I still have some questions about the internal structure of file tables.

1. In the article, we know the kernel keeps a file table. Each entry contains offset and a pointer to vnode. As I understand it, separate processes can open the same file with a different offset (for example, execute two vis for the same file), so the entry in the kernel file table doesn't seem to be shared between different processes.

   If this is true, there should be one-to-one mapping between the entry in the kernel file table and the entry in u_flist which is maintained by the process table. Following this logic, why don't we get rid of u_flist and allow the process table to have a pointer to a kernel file table entry? In the kernel file table entry we can maintain a pointer for a linked list, as one process can open multiple files.

2. An entry in a kernel file table is not shared between processes, so what is the difference between the f_count in struct file and uf_refcnt in uf_entry?

I'm curious about what is really happening inside Solaris, and am looking forward to your answers.

Liang Li

Liang,

Hello Liang,

Under certain conditions, a particular file may or may not have multiple file structures associated with it. In situations where a process forks, the child process inherits the parent's open files, and thus the file structure associated with the file is shared between the parent and child process. Any file I/O done by either process manipulates the same offset field (f_offset in the file structure). This also applies to processes that issue dup(2) or dup2(2) system calls to duplicate the file descriptor. The duped file descriptor will reference the same file structure.

The same holds true for multithreaded processes. Multiple threads in the same process all share the same file structure, so the file pointer for the same file as seen by all threads changes when one thread does a read or write.

However, different processes that open the same file will each have their own file structure. It is possible for the same file to have multiple file structures describing it. In this situation, reads or writes to the file by one process will not affect the offset as seen by other processes that have the same file opened. The level of sharing is at the file's vnode. Every file will have one and only one vnode in the kernel.

Your point above about doing away with the u_flist per-process open file list and simply linking directly to the processe's process structure is an interesting one. Maintaining a per-process open file list allows for per-process file flags. For example, a file opened by one process may require the file to have the close-on-exec flag to be set (true). Other processes with the same file opened may or may not want the close-on-exec behavior. If we did not maintain per-process files lists, we would not have this flexibility. There are probably other good reasons as well, I just can't think of any right now.

Jim Mauro

More from Liang Li:

Jim,

I still have one more question about the file table entry. In struct file_t, there's a field called f_offset. If this entry is shared by all processes that open the file, how can different processes read a file with different offsets? Don't we need to move f_offset to struct uf_entry, which is specific to each process?

Liang Li

Jim Mauro's reply:

Liang,

See above. Since the file structure maintains a file offset field (f_offset), it is important to be aware of the level at which the file structure is shared, so you know when a read or write by a process or thread effects the character pointer to the file (f_offset), as it is seen by other processes and/or threads.

Thank you for your kind words about the column, and your most interesting questions. The issue you've raised is an important one, and I'll be addressing it in this month's column.

Jim Mauro

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-03-1998/swol-03-letters.html
Last modified: