Linux under lock processing data file. Assuming a sudden power outage, does this lock ever exist on this file after a reboot?

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 file file->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_wait flock_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.

