First lock information is not part of the file?
Next, will the power outage automatically disappear or will never be released (because the process of setting up the lock no longer exists)?
Reply content:
First lock information is not part of the file? Next, will the power outage automatically disappear or will never be released (because the process of setting up the lock no longer exists)?
File lock under Linux
There are two different file lock mechanisms under Linux, one is to flock lock the entire file through system calls, and the other is to fcntl complete a finer-grained record lock (one interval in a locked file) through a system call
Open System call
Linux, when a file is initially opened, it eventually falls to open the system call.
Open system Calls (@./fs/open.c) do a lot of things, and the file lock is mainly about assigning an struct file object, and assigning values to the object's struct inode *inode and struct file_operations *f_op members.
Where the inode is assigned to the file system (for example, the Ext4 file system's allocation function is fs/ext4/inode.c ext4_iget ), it also contains a member of a struct file_operations * type i_fop , which is a collection of function pointers for the file system file operation.
The above mentioned two-time struct file_operations object contains flock and lock two function pointers, respectively, for the two different locking mechanisms mentioned above.
In memory, the kernel assigns only one object to a file, and struct inode when different processes open the same file, an object is assigned individually and points to the struct filefile->inode Inode object that corresponds to the file. Which file->f_op is actually in the open system call process, from inode->i_fop the copy came. (Vfs_open, Do_dentry_open, Do_last, Path_openat, Do_filp_open, Do_sys_open, open-- f->f_op = fops_get(inode->i_fop) )
Flock Plus Lock
The kernel first locates the object in the kernel according to the first parameter FD, struct file determines file->f_op->flock if the pointer is valid, if it is valid (indicating that the file system specifies a lock mechanism, such as the fs/fuse/file.c specified in the fuse_file_flock function, and EXT2/3/4 is not specified), Performs a lock operation on the function that the pointer points to, or @ FS/LOCKS.C if it does not exist flock_lock_file_waitflock_lock_inode .
If the file system does not specify the lock mechanism, then flock_lock_inode will try to the file corresponding to the Inode plus file lock (lock mechanism is trivial, I did not see too thin, roughly to get inode->i_flctx->flc_lock this spinlock, and then add and delete to check inode->i_flctx->flc_flock this list, but can see all memory operations).
If the file system specifies the locking mechanism, then it is necessary to investigate whether the corresponding lock mechanism is persisted on the disk, but from the requirements of the lock itself to investigate, in most cases should be expected to quickly complete, in addition to special circumstances, can be considered only in memory operation, and not persisted to the disk.
Fcntl plus Lock
and flock Similar, the difference is that the judgment of the function pointer is file->f_op->lock , if it does not exist, then call posix_lock_file to try to add record lock on the inode, but also in the inode->i_flctx above Daoteng, but with inode->i_flctx->flc_lock this list, the specific operation is more complex, but also to consider the intersection of record lock interval and other issues 。
Conclusion
Depending on whether the file system uses the specified locking mechanism, if any, it should be analyzed separately.
If not, all locks are maintained in memory, and if the power is lost, the lock is automatically invalidated. This is also more in line with the usual understanding.
In addition, the locking behavior of the file is generally performed by the process, and when the process exits (including an unexpected exit), the exit system call invokes the exit_files function to clean up all files opened by the process.
The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion;
products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the
content of the page makes you feel confusing, please write us an email, we will handle the problem
within 5 days after receiving your email.
If you find any instances of plagiarism from the community, please send an email to:
info-contact@alibabacloud.com
and provide relevant evidence. A staff member will contact you within 5 working days.