File Objects

A file object describes how a process interacts with a file it has opened. The object is created when the file is opened and consists of a file structure, whose fields are described in Table 12-4. Notice that file objects have no corresponding image on disk, and hence no "dirty" field is included in the file structure to specify that the file object has been modified.

Table 12-4. The fields of the file object

Type

Field

Description

struct list head

f_list

Pointers for generic file object list

struct dentry *

f dentry

dentry object associated with the file

struct vfsmount *

f vfsmnt

Mounted filesystem containing the file

struct file operations *

f op

Pointer to file operation table

atomic t

f count

File object's usage counter

unsigned int

f flags

Flags specified when opening the file

mode t

f mode

Process access mode

loff_t

f pos

Current file offset (file pointer)

unsigned long

f reada

Read-ahead flag

unsigned long

f ramax

Maximum number of pages to be read-ahead

unsigned long

f raend

File pointer after last read-ahead

unsigned long

f ralen

Number of read-ahead bytes

unsigned long

f rawin

Number of read-ahead pages

struct fown struct

f owner

Data for asynchronous I/O via signals

unsigned int

f uid

User's UID

unsigned int

f gid

User's GID

int

f error

Error code for network write operation

unsigned long

f version

Version number, automatically incremented after each use

void *

private data

Needed for tty driver

struct kiobuf *

f iobuf

Descriptor for direct access buffer (see Section 15.2)

long

f iobuf lock

Lock for direct I/O transfer

The main information stored in a file object is the file pointer—the current position in the file from which the next operation will take place. Since several processes may access the same file concurrently, the file pointer cannot be kept in the inode object. Each file object is always included in one of the following circular doubly linked lists:

• The list of "unused" file objects. This list acts both as a memory cache for the file objects and as a reserve for the superuser; it allows the superuser to open a file even if the dynamic memory in the system is exhausted. Since the objects are unused, their f_count fields are 0. The first element of the list is a dummy and it is stored in the free_list variable. The kernel makes sure that the list always contains at least nr_reserved_files objects, usually 10.

• The list of "in use" file objects not yet assigned to a superblock. The f_count field of each element in this list is set to 1. The first element of the list is a dummy and it is stored in the anon_list variable.

• Several lists of "in use" file objects already assigned to superblocks. Each superblock object stores in the s_files field the dummy first element of a list of file objects; thus, file objects of files belonging to different filesystems are included in different lists. The f_count field of each element in such a list is set to 1 plus the number of processes that are using the file object.

Regardless of which list a file object is in at the moment, the pointers of the next and previous elements in the list are stored in the f_list field of the file object. The files_lock semaphore protects the lists against concurrent accesses in multiprocessor systems.

The size of the list of "unused" file objects is stored in the nr_free_files field of the files_stat variable. The get_empty_filp( ) function is invoked when the VFS must allocate a new file object. The function checks whether the "unused" list has more than nr_reserved_files items, in which case one can be used for the newly opened file.

Otherwise, it falls back to normal memory allocation.

The files_stat variable also includes the nr_files field (which stores the number of file objects included in all lists) and the max_files field (which is the maximum number of allocatable file objects—i.e., the maximum number of files that can be accessed at the same time in the system). £5]

Was this article helpful?

0 0

Post a comment