This article introduces a so-called "patron saint of Linux File System", which refers to a program module that can observe the changes of Linux File System in real time. Being able to observe changes in the file system in real time and make appropriate responses in a timely manner is very interesting and important for using Linux as a desktop computer system. This article also introduces the asynchronous I/O Extension for Linux file systems. Similarly, this is critical for Linux desktop applications.
1. Patron Saint of the Linux File System
The traditional Linux File System presents the user program interface very cleanly. A user program can open a file, write data linearly to the file, read data linearly from a certain position of the file, close a file, delete a file, and create a file, and so on. Please note that there are only a few simple operation primitives, but they can provide so many rich applications. However, we note that these operation primitives used to access the Linux file system do not provide very complex locking and unlocking functions. This is a wonderful thing. What if requests from different user programs conflict?
Let's take a closer look and take a closer look at how a file is deleted. If a user program is accessing a file and another user program is about to delete the file, what will happen? We know that the Linux file system is based on the so-called inode, and each file is accompanied by an inode. Some system information about the file is recorded in inode, such as the file owner, some permission records related to the file, and several timestamps of the file. Inode in the memory also maintains a usage count for itself. Every time an inode represents a file being opened, this inode will add one to its own use count. Every time the inode indicates that the file is closed, the inode will subtract one of its usage count. When a user program deletes a file, the relevant system call will soon return to the user program, telling it that the corresponding file has been deleted. However, the corresponding inode is retained in the system. inode must first check its usage count. If the usage count is zero, the Linux Kernel can delete the file. If the count is greater than zero, that is, other user programs are accessing this file, then Linux Kernel needs to wait until these other user programs access this file one by one. That is to say, you can delete this file only when the inode usage count drops to zero.
We can imagine that if an MP3 player is playing an MP3 music, we will find the file on the hard disk and rm it. At this time, the MP3 playing program is not affected. You can continue playing this MP3 music, although this MP3 music file cannot be found by using ls on the file system at this time. In fact, it is always necessary for the MP3 player program to stop playing this MP3 music, and then the Linux File System will actually Delete this MP3 file from the hard disk. This experience is very different from what we encounter on Windows platforms.
On the Windows platform, when we try to right-click a folder window and choose the menu to delete an MP3 music playing by Winamp, a dialog box is displayed in the Windows system, this file is in use and cannot be deleted. In Windows, such an explanation about file deletion may cause a funny problem if the file is improperly used. We can imagine that a user's P2P file sharing program provides an MP3 file for others to download. It happens that This MP3 music file is very popular and people are constantly downloading it, the user finally decided to save the bandwidth and wanted to delete the MP3 music file, but the Windows system did not allow the user to do so, because this P2P file sharing program is always using this MP3 file. To delete this file, you have to stop the P2P file sharing program first! Haha.
However, the operating primitives of Linux file systems also have their own problems. We know that, on a Linux Shell Command Line, first rm and then ls are very clean, and rm files are lost and deleted. However, we can imagine a graphical file management program. When you drop a file from the Shell command line, the file manager in this graphic interface does not receive any messages from anyone. It thinks nothing happens and the deleted files are still there. This is really U. G. L.Y.
To solve this problem, an obvious but very bad solution is to let a background process Daemon check the directory on the file system at every short interval, see if any changes have occurred. The disadvantage of this method is really obvious. Not only is the system performance affected, but its response is not real-time.
If we need the user program to be able to understand the changes of a directory in the file system in real time, from the real-time perspective, it is clear that we need an interrupt mechanism. We all know that hardware interruptions can reflect the situation of a certain part of the system to the central processor in real time. Similarly, to reflect the situation of the file system located in the system kernel to the user program in real time, we also need a software interrupt mechanism from the operating system kernel to the user process. Readers who are familiar with Linux programming will immediately think that this interrupt mechanism has long been available in Linux, Which is signal for signal transmission.
After finding a mechanism to interrupt user processes such as signal transmission, everything seems to be ready. It seems that we can implement the patron saint of such a Linux File System to monitor changes in the file system in real time, and the message is promptly notified to the user program. But it's not slow. Let's search for Linux Kernel to see if other people are doing the same job. Haha, sure enough. It turns out that such a mechanism for real-time file system monitoring has already been implemented in the Linux kernel. The following is a small routine from the Linux Kernel document, which describes the usage of the dnotify function in Linux Kernel. Dnotify refers to directory notification, which monitors the situation in a directory on the file system.
# Define _ GNU_SOURCE/* needed to get the defines */
# Include <fcntl. h>/* in glibc 2.2 this has the needed
Values defined */
# Include <signal. h>
# Include <stdio. h>
# Include <unistd. h>
Static volatile int event_fd;
// Signal Processing Routine
Static void handler (int sig, siginfo_t * si, void * data)
{
Event_fd = si-> si_fd;
}
Int main (void)
{
Struct sigaction act;
Int fd;
// Register the signal processing routine
Act. sa_sigaction = handler;
Sigemptyset (& act. sa_mask );
Act. sa_flags = SA_SIGINFO;
Sigaction (SIGRTMIN, & act, NULL );
// You need to know the current directory "."
Fd = open (".", O_RDONLY );
Fcntl (fd, F_SETSIG, SIGRTMIN );
Fcntl (fd, F_NOTIFY, DN_MODIFY | DN_CREATE | DN_MULTISHOT );
/* We will now be notified if any of the files
In "." is modified or new files are created */
While (1 ){
// After receiving the signal, the signal processing routine is executed.
// And pause () is over.
Pause ();
Printf ("Got event on fd = % d \ n", event_fd );
}
}
The above short routine is easy to understand for readers who are familiar with Linux programming. The program first registers a signal processing routine and then notifies the Kernel. I want to observe the DN_MODIFY and DN_CREATE and DN_MULTISHOT events on fd. (For detailed definitions of these events, please refer to the references listed below .) After receiving the request, Linux Kernel marks the inode of the fd, and then the Linux Kernel and the user application process their own tasks. When a corresponding event occurs on the inode, the Linux Kernel sends the signal to the user process, and then runs the signal processing routine, the user program can promptly respond to changes in the file system. In this process, the normal operation of the system and user programs is basically not affected by performance. It should be noted that dnotify does not complete its function by adding a new system call, but does the task through fcntl. Adding a system call is a relatively large operation, and the scars will remain there if they are improperly designed and not well handled, this is something that developers of Linux Kernel are reluctant to comment on.
2. asynchronous I/O Extension for Linux File Systems
It is also critical for a desktop computer system to quickly respond to user requests. In other words, when a user moves the mouse, the system immediately stops whatever big, important, sacred, and non-disruptive work the system is performing, in addition, the mouse must be moved smoothly on the computer screen. For readers and friends who are used to working on traditional Linux Command lines, the mouse can go around the computer screen at any time, being regarded as the most important system task is unacceptable. However, when you move from a Linux Command Line to a GUI user environment such as GNOME or KDE, the mouse will be locked, and it will make you irrational. So let's accept this reality and see how we can increase the system response speed.
In terms of file systems, especially network file systems, the response speed may be quite slow. After you select an operation on a file in the file management program, the file system may take a long time to complete this operation. If the file management program must wait for the file system to complete this operation before it can continue, this will obviously bring a very unpleasant experience to the users of the file management program. The solution to this problem is to implement asynchronous file system I/O.
In the Linux Gnome desktop environment, GnomeVFS wraps the real Linux File System I/O and implements an asynchronous file system I/O interface API. The following example shows how to use GnomeVFS to open a file.
Enum _ GnomeVFSOpenMode {
GNOME_VFS_OPEN_NONE = 0,
GNOME_VFS_OPEN_READ = 1 <0,
GNOME_VFS_OPEN_WRITE = 1 <1,
GNOME_VFS_OPEN_RANDOM = 1 <2
};
Typedef enum _ GnomeVFSOpenMode;
Typedef void (* GnomeVFSAsyncOpenCallback)
(GnomeVFSAsyncHandle * handle,
GnomeVFSResult result,
Gpointer callback_data );
GnomeVFSResult gnome_vfs_async_open
(GnomeVFSAsyncHandle ** handle_return,
Const gchar * text_uri,
GnomeVFSOpenMode open_mode,
GnomeVFSAsyncOpenCallback callback,
Gpointer callback_data );
In the code snippet above, the user program registers a call back routine with GnomeVFS to open a file. After registering this call back routine, the function call will immediately return to the user program, and the user program will be able to process its own tasks, such as further responding to the user's ?? Too many? Magpie 6? Cover? Why are we looking for a low reward? Thumb? The Zookeeper nomeVFS will call the previously registered call back routine to notify the user that the file has been opened.
3. Summary
We learned about dnotify in Linux Kernel in this article, which can help us monitor changes in the directory tree of the file system in real time; I also learned about the GnomeVFS asynchronous file system I/O Extension in The Gnome desktop environment, which helps your programs not to be blocked by file system requests. These two functions are important for Linux applications on the desktop.
