Linux file system desktop applications _unix Linux

This article introduces a so-called "patron saint of Linux file Systems", which is a program module that can observe the changes in the Linux file system in real time. It is very interesting and important to be able to observe the changes of the file system in real time and make a timely and appropriate response to the application of Linux as a desktop computer system. This article also describes the extension of asynchronous I/O to the Linux file system. Again, this is critical for the desktop applications of Linux systems. 1, Linux file system Guardian God the traditional Linux file system presented to the user program interface, is really neat. The user program can open a file, write data to the file linearly, start at a certain location in the file, read the data linearly, close a file, delete a file, create a file, and so on. Please see, there are only so many simple operational primitives, but they can provide so much rich application. However, we note that these operational primitives for accessing Linux's file systems do not provide very complex lock unlocking capabilities. This is a fascinating thing to do if a request from a different user program has a conflict. We might as well go a little closer and take a closer look at how to delete a file. What happens if you already have a user program that accesses a file, and another user program just deletes the file? We know that the Linux file system is based on the so-called inode, each file is accompanied by an inode. Some system information about the file is recorded in the inode, such as the owner of the file, some permissions records related to the file, several timestamps about the file, and so on. The Inode in memory also maintains a count of its usage. Whenever an inode represents a file that is opened once, the Inode adds a count of its own usage. Whenever the file represented by this inode is closed, the Inode cuts its usage count by one. When the user program deletes a file, the associated system call is quickly returned to the user program, telling it that the corresponding file has been deleted. But the corresponding inode is still in the system, the inode first check its own use count, if the use of the count is zero, then the Linux Kernel can really delete this file. If the use count is greater than 0, that is, there are other user programs accessing this file, then Linux Kernel need to wait for the other user program to complete the access to this file. In other words, to wait until the usage count of this inode falls to zero, you can really delete this file. We can imagine that if there is a MP3 Playback program in the play a MP3 music, we think it is not good to hear, on the hard disk to find this file, the RM dropped it. At this point, the MP3 playback program is not affected, or can continue to play the first MP3 music, although this time on the file system with LS has not found this MP3 music file. In fact, until the MP3 player stops playing the MP3 music, the Linux file system actually deletes the MP3 file from the hard drive. This experience is quite different from what we encountered on the Windows platform. On the Windows platform, when we try to remove Winamp's MP3 music by clicking the right-click menu in the folder window, the Windows System uses a pop-up dialog box to tell us that the file is being used and cannot be removed. The Windows system's explanation of how to delete a file, if used incorrectly, can bring a funny question. We can imagine that the user's a Peer-to-peer file sharing program to provide a MP3 file for others to download, happened to this MP3 music file is very popular, and constantly someone to download, the user finally decided to save bandwidth, want to take this MP3 music file deleted, but Windows The system does not allow users to do so because this Peer-to-peer file-sharing program is always using this MP3 file. The user wants to delete this file, had to first the Peer-to-peer file sharing program to stop! Oh. But the operational primitives of Linux's file system also have its own problems. We know that on a Linux Shell command line, first RM, and then LS, very clean, the RM file is not, was deleted. But we can imagine a file management program with a graphical interface, when the user rm off a file from the Shell's command line, the graphical interface's file management program does not receive any messages from anyone, and it thinks nothing has happened and the deleted file is still there. It's really u.g.l.y. So to solve this problem, an obvious but very bad way is to let a background process Daemon every very short interval, check the file system on this directory, to see if there has been any changes. The disadvantage of this approach is really obvious, not only the performance of the system is affected, but also its response is not real-time. If we need a user program to be able to see the changes in a directory on the filesystem in real time, from a real-time point of view, obviously we need to have an interrupt mechanism. As we all know, hardware interrupts can reflect the situation of one part of the system to the CPU in real time,Like, to the system in the kernel of the file system in real-time to reflect the situation to the user program, we also need an operating system kernel to reach the user process software interrupt mechanism. Reader friends who are familiar with Linux system programming immediately think that this interrupt mechanism is already in the Linux system, this is the signal transmission signal. Found the signal delivery of such an interrupt user process mechanism, everything seems to be ready, it seems to be able to implement such a Linux file system Guardian God, to real-time monitoring of file system changes, and timely message to the user program. But wait a minute, let's search the Linux Kernel to see if anyone else is doing the same job. Haha, sure enough, the original such a real-time monitoring of file system situation is already implemented in the Linux kernel. The following section is a small routine taken from the Linux Kernel document, illustrating the use of the Dnotify feature in Linux Kernel. Dnotify refers to the directory notification, which monitors the situation in the previous directory on the file system. #define _gnu_source    /* needed to get the defines * *
#include <fcntl.h>/* 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 routines
static void Handler (int sig, siginfo_t *si, void *data)
{
EVENT_FD = si->si_fd;
}

int main (void)
{
struct Sigaction Act;
int FD;

Registration Signal Processing Routines
Act.sa_sigaction = handler;
Sigemptyset (&act.sa_mask);
Act.sa_flags = Sa_siginfo;
Sigaction (Sigrtmin, &act, NULL);

Need to know the current directory "." of the situation
FD = Open (".", o_rdonly);
Fcntl (FD, F_setsig, sigrtmin);
Fcntl (FD, F_notify, dn_modify| dn_create| Dn_multishot);
/* We'll now is notified if any of the files
In '. ' is modified or new files are created * *
while (1) {
When the signal is received, a signal processing routine is executed.
and pause () is over.
Pause ();
printf ("Got event on fd=%d\n", EVENT_FD);
}
The short routine above is easy to understand for readers who are familiar with Linux system programming. The program first registers a signal processing routine and then notifies Kernel that I want to observe the dn_modify and Dn_create and Dn_multishot events on FD. (For a detailed definition of these events, please refer to the resources listed below for your readers ' reference.) After the Linux Kernel receives this request, the corresponding FD's inode is marked, and then the Linux Kernel and the user application take care of their own other things. Wait until the corresponding event occurred on the inode, Linux Kernel signal to the user process, so began to perform signal processing routines, the user program on the file system changes can be timely response. And in this whole process, the system and the user program's normal operation is basically not affected by the performance. It also needs to be explained that Dnotify does not perform its function by adding new system calls, but through FCNTL to accomplish the task. Adding a system call is a relatively large operation, and if poorly designed and poorly handled, scars will remain there, something that Linux Kernel developers are very unwilling to see. 2, the Linux file system asynchronous I/O extension for desktop computer systems, can quickly respond to user requests, which is also very critical. In other words, when the user moves the mouse, no matter what the system is doing, important, sacred, and not interrupted work, it must stop immediately, and let the mouse immediately smooth on the computer screen to move perfectly. For readers who are accustomed to working on the traditional Linux command line, it is hard to accept that it is considered the most important system task to allow the mouse to be able to flee like a headless fly at any time on the computer screen. However, when you move from the Linux command line to a graphical user environment such as GNOME or KDE, the mouse is locked, and 100% of the time can make you lose your mind. So, let's accept this reality and see how we can increase the response speed of the system. From a file system perspective, especially considering the network file system, its response speed is likely to be quite slow. When a user selects an action on a file in a file management program, the file system may take a considerable amount of time to complete this operation. If the file manager has to wait for the file system to complete this operation before proceeding, it will obviously bring a very unpleasant experience to the users of the file management program. The solution to this problem is to implement the asynchronous file system/ o. In the Linux Gnome desktop environment, the real Linux file system I/O is wrapped by GNOMEVFS, and an asynchronous file system I/O interface API is implemented. We can see the following example of opening a file with Gnomevfs.

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
The typedef enum _GNOMEVFSOPENMODE 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);    We notice that in the code snippet above, the user program registers a call-back routine with the GNOMEVFS in order to open a file. After registering this call-back routine, the function calls are immediately returned to the user program, and the user program can handle its own other things, such as further response from the user. 肭 Teman to take 6 to cover raising, low punishment finish what Halo raise? The Gourmands Courtyard Teman 珿 will invoke the call back routine just registered, notifying the user that the file is open. 3. We learned about the dnotify in Linux Kernel in this article to help us monitor the changes in the file system directory tree in real time, as well as the GNOMEVFS asynchronous file system I/O extension of the Gnome desktop environment, which can help the user program not be The request block. These two features are important for Linux applications on the desktop.