File system operation method and device, computer device and storage medium

By storing file system metadata in the operating system's memory and keeping it unchanged, the problems of low storage space utilization and performance impact in general file systems are solved, achieving efficient video data storage and read/write performance.

CN118820191BActive Publication Date: 2026-08-25JINAN INSPUR DATA TECH CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202410839775.1
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2024-06-26
Publication Date
2026-08-25
Estimated Expiration
2044-06-26

AI Technical Summary

Technical Problem

When storing video data, general file systems suffer from low physical storage space utilization and performance degradation due to real-time updates of file system metadata and frequent read/write operations.

Method used

The physical storage space of the file system is divided into a first storage space and a second storage space. The file system metadata is stored in the operating system memory and remains unchanged. The video data is stored in block files in the second storage space. The block file addresses are contiguous and the attributes are the same. The metadata is updated only in memory.

Benefits of technology

It improved the utilization rate of physical storage space to nearly 100%, reduced metadata read and write operations, improved the performance and data recovery characteristics of the file system, and avoided the problem of inconsistent metadata updates.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN118820191B_ABST
    Figure CN118820191B_ABST
Patent Text Reader

Abstract

Embodiments of the present disclosure relate to a file system running method and device, computer equipment and a storage medium. The file system is used for managing video data, and a physical storage space corresponding to the file system is divided into a first storage space and a second storage space. The main steps of the foregoing method include: writing head information of the file system into the first storage space, generating file system metadata according to the head information, storing and retaining the file system metadata in an operating system memory, so that the file system metadata remains unchanged during file system running, and storing target video data into a target block file of the second storage space in response to a target video data write instruction. The file system metadata is used for mapping the second storage space into a plurality of block files that are continuous in space addresses and have the same capacity and attribute information. The foregoing method can improve the space utilization of the physical storage space of the file system and improve the running performance of the file system.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This disclosure relates to the field of computer system technology, and in particular to a method, apparatus, computer device, and storage medium for operating a file system. Background Technology

[0002] With the rapid development of security technology, security monitoring is gradually evolving towards digitalization, networking, and intelligence. Currently, general file systems such as ext4 (one of the most commonly used file systems in the Linux operating system) and XFS (a high-performance journaling file system) are mainly used to store video data generated by security monitoring.

[0003] However, during operation, the general file system needs to update the file system metadata in real time according to the video data writing situation, and reserve a certain amount of space in the physical storage space for storing the file system metadata. This results in low space utilization of the physical storage space. Furthermore, when performing data read and write operations, the general file system not only needs to read and write the actual data, but also needs to read and write the file system metadata, which affects the performance of the file system operation. Summary of the Invention

[0004] Therefore, it is necessary to provide a method, apparatus, computer device, and storage medium for operating a high-performance, high-space-utilization file system to address the aforementioned technical problems.

[0005] In a first aspect, embodiments of this disclosure provide a method for operating a file system for managing video data, wherein the physical storage space corresponding to the file system is divided into a first storage space and a second storage space. The method for operating the file system may include: in response to a formatting instruction, writing file system header information into the first storage space; generating file system metadata based on the header information; storing and retaining the file system metadata in operating system memory to ensure that the file system metadata remains unchanged during file system operation; and in response to a target video data write instruction, storing the target video data into a target block file in the second storage space.

[0006] The file system metadata includes superblock information, directory entry information, and inode information, which are used to map the second storage space into multiple block files with contiguous spatial addresses and identical capacity and attribute information.

[0007] In some embodiments, generating file system metadata based on header information may include: reading header information from a first storage space, initializing the superblock corresponding to the file system, filling the superblock with header information, and generating superblock information, inode information of the mounted root directory, and directory entry information of the file system.

[0008] The superblock information includes at least the file system type information, inodes, and the number of block files. The inode information includes the attribute information and file pointer information of multiple files in the root directory of the file system. The directory entry information includes the file name and inode number of all files.

[0009] In some embodiments, generating inode information may include generating attribute information for multiple files in the root directory, wherein the attribute information for each file is identical. The attribute information for multiple files in the file system root directory includes at least file permissions, file size, and file owner information.

[0010] In some embodiments, the directory structure of the file system is a single-level structure, and the inode of the file system includes only the root directory node and multiple file nodes corresponding to the number of block files.

[0011] The inode number of the root directory node is configured to a fixed value. The inode numbers of each file node in the multiple file nodes are sequentially increased starting from a preset starting number. The file names of the multiple files corresponding to the multiple file nodes are named sequentially according to a preset naming rule. There is a correspondence between the inode number of any file node and its file name.

[0012] In some embodiments, the method of running the file system may further include: responding to a read / write operation instruction of the target file, determining the target address information of the target file in the second storage space based on the inode number of the corresponding file node of the target file, a preset offset and a preset block file capacity, and performing data reading or data writing on the target file based on the target address information.

[0013] In some embodiments, the method of running the file system may further include: responding to a read / write operation instruction for the target file, determining the target address information of the target file in the second storage space based on the file name of the target file, a preset offset and a preset block file capacity, and performing data reading or data writing on the target file based on the target address information.

[0014] In some embodiments, the capacity of a block file corresponds to the number of fixed disk units per block file included in the header information, and the number of block files in the second storage space corresponds to the number of block files included in the header information.

[0015] In some embodiments, the number of block files is determined by the capacity of the second storage space and the number of fixed disk units per block file.

[0016] In some embodiments, writing the header information of the file system into the first storage space may include: writing the header information into the first storage space and performing redundant backups in the first storage space.

[0017] In some embodiments, the video data is streaming media data. Storing the target video data in the target block file of the second storage space may include: when all block files in the second storage space are in a full state, writing the target video data sequentially from the first block file in the second storage space into each block file, and sequentially overwriting the historical video data of each block file.

[0018] In a second aspect, embodiments of this disclosure provide an apparatus for running a file system used to manage video data, wherein the physical storage space corresponding to the file system is divided into a first storage space and a second storage space. The apparatus for running this file system may include: a formatting module, a metadata generation module, a metadata storage module, and an operation instruction processing module.

[0019] The formatting module is used to write the file system header information into the first storage space in response to formatting instructions.

[0020] The metadata generation module is used to generate file system metadata based on header information.

[0021] The metadata storage module stores and retains file system metadata in the operating system's memory, ensuring that the file system metadata remains unchanged during file system operation. File system metadata includes superblock information, directory entry information, and inode information, used to map the secondary storage space into multiple block files with contiguous spatial addresses and identical capacity and attribute information.

[0022] The operation instruction processing module is used to respond to the target video data write instruction and store the target video data into the target block file in the second storage space.

[0023] In a third aspect, embodiments of this disclosure provide a computer device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the file system operation method in any embodiment of the first aspect of this disclosure.

[0024] In a fourth aspect, embodiments of this disclosure provide a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the file system operation method in any embodiment of the first aspect of this disclosure.

[0025] In the aforementioned methods, apparatuses, computer devices, and storage media related to the file system operation, the file system metadata is calculated and generated based on the file system header information and stored in the operating system memory. This file system metadata remains unchanged during file system operation, without updates or read / write operations, thus occupying minimal space and remaining in memory without requiring additional physical storage. The physical storage space corresponding to the file system only stores header information and video data. The header information storage space is typically measured in KB (kilobytes). For physical storage space measured in TB (terabytes), the file system's space utilization is high, approaching 100%. Multiple block file spaces in the second storage space have contiguous addresses, providing high read / write performance for video data storage. During video data read / write operations, there is no need to read / write or update the file system metadata, further improving the file system's performance.

[0026] Furthermore, after the file system completes formatting and mounting, the second storage space creates block files based on the file system metadata according to fixed rules. Each block file has identical attributes, resulting in good data recovery capabilities. Also, since the physical storage space does not store file system metadata, there is no metadata inconsistency issue when a data write failure occurs, and there is no need to write logs or perform metadata rollback. Attached Figure Description

[0027] Figure 1 This is a schematic diagram of the system architecture for file system operation in some embodiments;

[0028] Figure 2 This is a flowchart illustrating the file system operation method in some embodiments;

[0029] Figure 3 This is a schematic diagram of the physical storage space structure in some embodiments;

[0030] Figure 4 This is a structural block diagram of a device running a file system in some embodiments;

[0031] Figure 5 This is a diagram showing the internal structure of a computer device in some embodiments. Detailed Implementation

[0032] To make the technical solutions and advantages of this disclosure clearer, the embodiments and related technical content of this disclosure will be further described in detail below with reference to the accompanying drawings and text description. It should be understood that the embodiments described below are merely used to explain the technical solutions of the embodiments of this disclosure and are not intended to limit more possible implementations of this disclosure.

[0033] It should be noted that relational terms such as "first" and "second" appearing in this document are used only to distinguish things, states, or actions, and do not necessarily indicate or imply relative importance or order. The terms "including," "comprising," or any other variations thereof are used to indicate non-exclusive inclusion, and the included objects may not be limited to those listed in this document. The terms "multiple" or other variations are used to indicate that the number of objects is two or more.

[0034] The following explains some of the terms used in the embodiments of this application. It should be noted that these explanations are for the convenience of those skilled in the art and do not constitute a limitation on the scope of protection claimed in this application.

[0035] VFS: Virtual File Systems, is an interface layer between file systems and services on a physical device. It abstracts all the details of each file system in Linux, so that different file systems appear the same to other processes running in the Linux system.

[0036] File system type: file_system_type. Linux supports multiple file systems, each corresponding to a file system type structure. File system types need to be registered with VFS. If a file system type is no longer used, it must be deregistered from VFS.

[0037] The superblock (super_block) is a container for the entire file system's metadata. It's one of the core data structures of the file system, storing its metadata and configuration information. Whenever a file system is mounted onto the system, a corresponding super_block object is created to describe the characteristics and state of that file system.

[0038] An inode (index node) stores metadata information about a file or directory. Each file or directory has a unique inode in the file system, which contains information such as the file or directory's attributes and pointers to data blocks.

[0039] The directory entry, dentry, reflects the location of a file system object within the global file system.

[0040] In Linux systems, all I / O operations are performed through files. File operation tables are used to open, close, read, and write files.

[0041] Address space, also known as page buffer, is used to manage the pages of a file mapped into memory. Each file has such an address space structure, which binds the data corresponding to the file in the file system to the memory corresponding to the file. Correspondingly, the page buffer operation table is used to operate on the pages of the file mapped into memory, such as writing modifications in memory back to the file, reading data from the file into the page buffer, etc.

[0042] In a first aspect, embodiments of this disclosure provide a method for operating a file system. This file system is accessed by the Linux operating system kernel through a Virtual File System (VFS) interface. The file system can be implemented using a file system type (file_system_type), a superblock operation table (super_operations), an inode operation table (inode_operations), a file operation table (file_operations), and a page buffer operation table (address_space_operations). The file system type describes the file system, including its name, type flags, and mount information, and is used to register the file system during installation. The superblock operation table includes multiple operation functions related to the superblock, enabling operations such as creating or releasing inodes. The inode operation table includes multiple functions for implementing inode operations, such as creation, searching, and attribute setting. The file operation table enables interaction between the file system and the user, including user interfaces for reading and writing files, opening, closing, and mapping files. The page buffer operation table manages page buffer operations, including functions such as readpage() and writepage(), responsible for reading and writing pages in the page buffer.

[0043] The system architecture on which this file system runs can be as follows: Figure 1 As shown, it includes a virtual file system 110 and a file system 120. The file system 120 includes a formatter 121 and a driver 122. The driver 122 may include a file system type 101, a superblock operation table 102, an inode operation table 103, a file operation table 104, and address space operations 105. The virtual file system 110 provides a general interface abstraction, creating an exchange layer between the user and the file system, allowing the user to use the file system mounted in the operating system. The formatter 121 implements the file system formatting operations and the generation and storage of file system header information. The driver 122 performs file system registration and deregistration, and defines and manipulates data structures such as the superblock, inode, directory structure, file structure, and page cache.

[0044] In some embodiments, the file system provided in this disclosure is used to manage video data, and the physical storage space corresponding to the file system is divided into a first storage space and a second storage space, such as... Figure 2 As shown, the method for running the file system may include steps S201 to S204. The following is a detailed description of each step.

[0045] Step S201: In response to the formatting command, write the file system header information into the first storage space.

[0046] The file system header information refers to the basic information of the file system, which is the information foundation for constructing data structures such as the superblock, inodes, directory entries, files, and page cache. The header information can include multiple formatted fields, such as: magic (starting magic number), version (version number), label (label), uuid (globally unique identifier), format_timestamp (formatting time), chunk_startno (starting number of data block file names), chunk_startoff (starting offset of the data block on disk), chunk_count (number of block files), chunk_blks (number of fixed disk units per block file), chunk_permission (permissions of block files), chunk_uid (user ID of the block file), chunk_gid (group ID of the block file), crc_code (metadata checksum), and magic2 (ending magic number), etc.

[0047] The values ​​of the above-mentioned formatted fields can be set by system default or user-defined. In some specific embodiments, the value of the magic field is a fixed value composed of "(((UINT64)MAKEFOURCC('I','N','S','P'))<<32)|MAKEFOURCC('A','B','F','S')", the value of the version field is the current fixed value 1, the value of the label field is an empty string by default, the value of the uuid field is a fixed value by default: "00000000-0000-0000-0000-00000000000", the value of the format_timestamp field is generated according to the actual situation, and the value of chunk_star The default value of the tno field is 0. The value of the chunk_startoff field is a fixed value of 64, which means that the starting offset of the data block from the disk is 64 * 4K = 256K. The values ​​of the chunk_count and chunk_blks fields can be customized by the user. The value of the chunk_permission field is a fixed value of 0644. The value of the chunk_uid field is a fixed value of 0, which means root. The value of the chunk_gid field is a fixed value of 0, which means root. The value of the crc_code field is the XOR result of all u64 field values ​​except itself, which is used to check whether the basic information is correct. The field values ​​of magic2 are the same as magic.

[0048] The physical storage space corresponding to the file system can be disk space, which is used to store file system-related data. Formatting commands can be initiated by formatting program 121. Accordingly, in some specific examples, the file system of this embodiment can be named: Pre-allocated blockfile system (PABFS), and the formatting command can be: ". / mkfs.pabfs format_paramdisk_path", where format_param is the formatting parameter, which can be input via command line. When executing the formatting command, the detailed definition of each formatting parameter can include:

[0049] -h prints help information;

[0050] -n is the starting number of the block file;

[0051] -c Number of block files;

[0052] -s is the number of fixed disk units (4K) per block file;

[0053] -l File system label, if not entered, will be an empty string;

[0054] -U file system UUID, if not entered, is 00000000-0000-0000-0000-00000000000;

[0055] `disk_path` represents a disk partition and can only correspond to one disk partition. To format a file system for a specific partition on the disk, execute a command such as: `. / mkfs.pabfs -n 1 -c 1000 / dev / sdb1`. The block file starting number can start from 1, and the number of block files can be calculated based on the disk space size. The default size of each block file is 1GB.

[0056] Specifically, in response to a formatting command, the file system header information is written to the first storage space. In some specific examples, the first storage space may be a region located at the beginning of the physical storage space, and the second storage space may be a region located from the end of the first storage space to the end of the physical storage space. In some specific examples, the header information occupies 64K of storage space, including a certain amount of reserved space.

[0057] In some specific embodiments, step S201 may include: writing the header information into a first storage space and performing a redundant backup in the first storage space. Specifically, the number of redundant backups may be three or four copies, and there is no specific limitation.

[0058] Accordingly, taking the redundant backup of the header information to three copies as an example, during the formatting operation, four copies of the header information are continuously stored in the front area of ​​the physical storage space, occupying a storage space of 256K, that is, the first storage space size is 256K. Figure 3 As shown, the physical storage space 300 includes a first storage space 310 and a second storage space 320. The first storage space 310 includes four spaces—a first space 311, a second space 312, a third space 313, and a fourth space 314—that sequentially store four copies of header information. The second storage space 320 includes four block files—321, 322, 323, and 324—that are address-contiguous and of equal capacity. (This example uses four block files; in practical applications, there could be more.)

[0059] Step S202: Generate file system metadata based on header information.

[0060] File system metadata includes superblock information, directory entry information, and inode information, used to map the second storage space into multiple block files with contiguous spatial addresses and identical capacity and attribute information. A block file is a logical block corresponding to a portion of the storage space.

[0061] When the file system starts running, the second storage space can be mapped into multiple block files based on the file system metadata. Each block file has the same size, the same attribute information, and contiguous space addresses.

[0062] In some embodiments, step S202 may include the following steps: reading header information from the first storage space, initializing the superblock corresponding to the file system, filling the superblock with header information, and generating the superblock information, inode information, and directory entry information of the file system.

[0063] Superblock information refers to the global information of the file system recorded in the superblock. Superblock information includes at least the file system type information, inodes, and number of block files. Superblock information may also include: file system size, status, block file usage, and other file system format or attribute information.

[0064] Inode information refers to the file-related information recorded in the inode. Typically, one file in a file system occupies one inode. Inode information can include attribute information and file pointer information for multiple files in the file system's root directory. File attribute information may include: file size, device identifier, user identifier, group identifier, file permissions, and timestamps for file read or modification. File pointer information refers to pointers from individual files to other files, used to locate and access the file's actual data content within the file system.

[0065] Directory entry information refers to the information recorded in a directory entry related to a file or directory, which can include the filenames and inode numbers of all files. The filename is a string used to uniquely identify and reference the file or directory, and can contain characters, numbers, and extensions. Each file or directory has a unique inode number used to locate the corresponding inode number in the file system.

[0066] In some specific embodiments, in response to the mount command, header information is read from the first storage space, the superblock of the file system is constructed, the formatting parameters in the header information are assigned to the s_fs_info field of the superblock, the inode information of the mount root directory is generated, and the root directory is generated by the d_make_root function according to the inode of the root directory and assigned to the s_root field of the superblock.

[0067] Step S203: Store and retain the file system metadata in the operating system memory so that the file system metadata remains unchanged during the operation of the file system.

[0068] In some specific examples, file system metadata is stored and retained in the operating system's memory. When the file system is unmounted, the space occupied by the file system metadata stored in the operating system's memory is released. The second storage space is divided into multiple block files based on the file system metadata. Correspondingly, the usable size of the complete physical storage space corresponding to the file system is set to 0, meaning that no additional block files can be created. Therefore, when formatting is complete, the physical storage space will be fully occupied.

[0069] In some specific examples, the file system metadata defines file permissions to only allow opening in overwrite mode for data reading and writing, and disallows deletion, creation, or modification of file attributes. This enables the file system to have good data security.

[0070] Step S204: In response to the target video data write instruction, store the target video data into the target block file in the second storage space.

[0071] In some specific embodiments, the video data is streaming media data. Streaming media data is stored with append-only write and continuous read capabilities.

[0072] Storing the target video data into the target block file of the second storage space may include: when all block files in the second storage space are in a full state, writing the target video data sequentially into each block file starting from the first block file in the second storage space, and overwriting the historical video data of each block file sequentially.

[0073] The first block file can be either the first block file at the beginning of the second storage space or the first block file at the end of the second storage space. All block files are used in a cyclical manner, overwriting each other.

[0074] In the above-described file system operation method, the file system metadata is calculated and generated based on the file system header information and stored in the operating system memory. This metadata remains unchanged during file system operation, without updates or read / write operations, resulting in a small space footprint. It can remain in memory indefinitely, requiring no additional physical storage space. The physical storage space corresponding to the file system only stores header information and video data. Header information storage space is typically measured in KB (kilobytes). For physical storage space measured in TB (terabytes), the file system's space utilization is high, approaching 100%. The multiple block file space addresses in the second storage space are contiguous, providing high read / write performance for video data storage. During video data read / write operations, there is no need to read / write or update the file system metadata, further improving the file system's performance.

[0075] Furthermore, after the file system completes formatting and mounting, the second storage space creates block files based on the file system metadata according to fixed rules. Each block file has identical attributes, resulting in good data recovery capabilities. Also, since the physical storage space does not store file system metadata, there is no metadata inconsistency issue when a data write failure occurs, and there is no need to write logs or perform metadata rollback.

[0076] In some embodiments, the attribute information of multiple files in the root directory of the file system includes at least file permissions, file size, and file owner information. Accordingly, generating inode information may include the following steps: generating attribute information for multiple files in the root directory, wherein the attribute information of each file is identical.

[0077] The attribute information of each file remains consistent, which ensures that the file system metadata will not be updated while the file system is running.

[0078] In some embodiments, the directory structure of the file system is a single-level structure, and the inode of the file system includes only the root directory node and multiple file nodes corresponding to the number of block files.

[0079] The inode number of the root directory node is configured to a fixed value. The inode numbers of each file node in the multiple file nodes are sequentially increased starting from a preset starting number. The file names of the multiple files corresponding to the multiple file nodes are named sequentially according to a preset naming rule. There is a correspondence between the inode number of any file node and its file name.

[0080] Each block file corresponds to a file node, and each file node corresponds to a file.

[0081] In some specific examples, the root directory's inode number can be configured to a fixed value of 0. The inode numbers of each file node can start from 1 and increment sequentially. In the case where the second storage space is divided into N blocks of files, the inode numbers of each file node will be 1 through N, where N is a positive integer greater than 1. The default naming convention for filenames can be "file node inode number.filesystem abbreviation". For example, if the filesystem abbreviation is "pab", the filenames of the N files could be: 1.pab, 2.pab, 3.pab...N.pab.

[0082] The file system uses a single-level directory structure, which avoids the need for multi-level searches during file reading and writing, as required by multi-level indexes, thus shortening file reading and writing time and improving efficiency. Furthermore, there is a one-to-one correspondence between block files and file nodes. The root directory node's inode number is configured with a fixed value, and the file node inode numbers increment sequentially from a preset starting number. There is a corresponding relationship between filenames and file node inode numbers. The inode numbers throughout the entire file system are consecutive, and this correspondence between inode numbers and filenames shortens the time required to find a file from a filename, improving file system performance. During file system operation, files with the same filename share the same physical storage space, allowing for rapid data recovery in the event of data loss.

[0083] In some embodiments, the address information of any file in the file system corresponds to the capacity of the block file and the inode number of the file node corresponding to the file.

[0084] Since all block files in the second storage space have the same size, and each block file corresponds to a file system file node, there is a correspondence between the file name and the inode number of the file node. The address information of each file in the physical storage space can be sequentially mapped according to the inode number of the file node (i.e., the block file node) and the size of the block file. Taking the starting position of the second storage space as 256k and the block file size as 1G as an example... Figure 3 Each block file (block file 321, block file 322, block file 323, and block file 324) corresponds to a specific file. Specifically, file "1.pab" is stored in block file 321, file "2.pab" in block file 322, file "3.pab" in block file 323, and file "4.pab" in block file 324. Since each block file has a capacity of 1GB and the starting position (i.e., starting offset) of the second storage space is 256KB, the address space of block file 321 is "256KB~1048832KB", the address space of block file 322 is "1048832KB~2097408KB", the address space of block file 323 is "2097408KB~3145984KB", and the address space of block file 324 is "3145984KB~4194560KB". The address space of each file block is the address information of each file.

[0085] Accordingly, the file system operation method may also include the following steps: in response to the read / write operation command of the target file, determining the target address information of the target file in the second storage space according to the inode number of the corresponding file node of the target file, the preset offset and the preset block file capacity, and performing data reading or data writing on the target file according to the target address information.

[0086] The default offset of the file system is defined in the file system header information as "chunk_startoff (the starting offset of the data block on the disk)". The default block file size can be determined according to the "chunk_blks (the number of fixed disk units per block file)" defined in the file system header information.

[0087] In some specific embodiments, the starting position of the address range corresponding to the target file in the second storage space is the position corresponding to "preset offset + (index node number of the file node corresponding to the target file - 1) * block file capacity", and the ending position can be the position corresponding to "preset offset + index node number of the file node corresponding to the target file * block file capacity".

[0088] Taking a preset offset of 256K and a preset block file size of 1G as an example, in some specific examples, the target file is the file "2.pab", the inode number of the file node corresponding to the file "2.pab" is 2, the starting position of the address range corresponding to the target file in the second storage space is the position corresponding to 256K+1G, and the ending position can be the position corresponding to 256K+2G, that is, 1048832K~2097408K. If the target file is the file "3.pab", the inode number of the file node corresponding to the file "3.pab" is 3, the starting position of the address range corresponding to the target file in the second storage space is the position corresponding to 256K+2G, and the ending position can be the position corresponding to 256K+3G, that is, 2097408K~3145984K. Similarly, if the target file is "N.pab" and the corresponding file node's index number is N, then the starting position of the address range corresponding to the target file in the second storage space is the position corresponding to 256K+(N-1)*1G, and the ending position can be the position corresponding to 256K+N*1G.

[0089] In some embodiments, the address information of any file in the file system corresponds to the capacity and file name of the block file. The operation method of the file system may further include the following steps: in response to the read / write operation instruction of the target file, determining the target address information of the target file in the second storage space according to the file name, preset offset and preset block file capacity of the target file; and reading or writing data to the target file according to the target address information.

[0090] Since there is a correspondence between filenames and inode numbers in a file system, when a read / write operation instruction for a target file is received, the inode number of the corresponding file node can be determined based on the filename. Furthermore, by combining a preset offset and a preset block file size, the target address information of the target file in the second storage space can be determined, thereby enabling data reading or writing of the target file. The related concepts and explanations in this embodiment are the same as or similar to those in the above embodiments, and will not be repeated here.

[0091] The read and write operations on the target file can be initiated by the target process. Typically, a file data structure represents a file opened within a process. Different processes opening the same file will each have a file object, corresponding to the process's file handle. Reading file content is accomplished using the `read()` system call, which ultimately calls the `sys_read()` kernel function. The `sys_read()` kernel function first calls the `fget()` function to convert the file descriptor into a file structure, and then calls the `read()` method of the file structure to read the file content. Writing data to the file is achieved by calling the `write()` system call, which ultimately calls the `sys_write()` kernel function. The implementation of `sys_write()` is similar to `sys_read()`; it first calls the `fget()` function to convert the file descriptor into a file structure, and then calls the `write()` method of the file structure to write the content to the file.

[0092] In a file system, each file corresponds to an address space. The address space and offset are used to determine the pages in the page cache or swap cache. When addressing specific data, the corresponding page can be found based on the given file and the data's offset within the file.

[0093] Since the address information of a file corresponds to its filename (or the inode number of the file node) and the capacity of the block file, when performing read and write operations on the target file, the target address information corresponding to the target file can be quickly determined based on the target file's filename (or the inode number of the file node), the preset offset, and the preset block file capacity. The address information determination method is simple and efficient, which can improve the efficiency of file system operations and improve system performance.

[0094] In some embodiments, the size of a block file corresponds to the number of fixed disk units per block file included in the header information.

[0095] The header information pre-determines the number of fixed disk units per unit block file. In some examples, the fixed disk unit is 4K. The block file capacity can be calculated based on the number of fixed disk units per unit block file. For example, if the number of fixed disk units per unit block file is X, then the block file capacity is X*4K.

[0096] The number of block files in the second storage space corresponds to the number of block files included in the header information. When the header information includes a preset number of block files (i.e., chunk_count), the number of block files in the second storage space is equal to the preset number of block files in the header information.

[0097] The number of block files is determined by the capacity of the second storage space and the number of fixed disk units per block file. When the header information does not include a preset number of block files (i.e., chunk_count), the number of block files in the second storage space can be determined based on the capacity of the second storage space and the number of fixed disk units per block file. Specifically, the block file capacity can be calculated based on the number of fixed disk units per block file, and the number of block files can be determined by dividing the capacity of the second storage space by the block file capacity. In some cases, if after the second storage space is divided into several block files, there is still space remaining that does not meet the capacity of a single block file, this remaining space is discarded from the storage space and not used to store video data.

[0098] In some embodiments, the file system can be named a pre-allocated block file system, or pabfs for short. This file system runs in the Linux kernel mode and can perform block file operations through the POSIX interface (Portable Operating System Interface).

[0099] In some specific embodiments, the method of operating the file system may also include file system registration or unregistration.

[0100] To enable the Linux kernel to discover file systems, the `register_filesystem()` function can be used to register them. Specifically, a file system type is created to describe the file system to be registered. This file system type includes the file system name, type flags, and mount operations. Registering a pre-allocated block file system involves filling in the file system type structure. In some examples, the file system type of a pre-allocated block file system can be defined as:

[0101] struct file_system_type pabfs_type={

[0102] .owner = THIS_MODULE,

[0103] .name = "pabfs",

[0104] .pabfs_fstype_mount = pabfs_mount, / / Mounting file directories

[0105] .kill_sb = kill_block_super,

[0106] .fs_flags = FS_REQUIRES_DEV / / The file system must be on the physical device

[0107] }

[0108] Specifically, when the file system is loaded using the insmod pabfs.ko command, the register_filesystem(&pabfs_type) command is called to register the file system. When the file system is unloaded using rmmod pabfs.ko, the unregister_filesystem(&pabfs_type) command is called to unregister the file system.

[0109] In some specific embodiments, the superblock operation table of the pre-allocated block file system can be defined as:

[0110] struct super_operations pabfs_sops={

[0111] .alloc_inode=pabfs_alloc_inode,

[0112] .destroy_inode=pabfs_destroy_inode,

[0113] .statfs = pabfs_statfs,

[0114] .show_options=pabfs_show_options

[0115] }

[0116] In some specific implementations, since directory entries do not have corresponding data structures in the physical storage space, directory traversal is performed by calling the `readdir()` function, and each traversed file or subdirectory is populated with information using the `filldir()` function. Specifically, this can be implemented using the following code definition:

[0117] struct file_operations pabfs_dir_operations={

[0118] .llseek=generic_file_llseek,

[0119] .read = generic_read_dir,

[0120] .readdir = pabfs_readdir,

[0121] }

[0122] In some specific embodiments, the inode operation table of the pre-allocated block file system can be defined as:

[0123] struct inode_operations pabfs_dir_inode_operations={

[0124] .create = pabfs_create,

[0125] .lookup = pabfs_lookup,

[0126] .setattr = pabfs_setattr

[0127] }

[0128] In some specific embodiments, the file operation table implementation of the pre-allocated block file system can be defined as:

[0129] struct file_operations pabfs_file_operations={

[0130] .llseek =generic_file_llseek,

[0131] .read = do_sync_read,

[0132] .write = do_sync_write,

[0133] .mmap = generic_file_mmap,

[0134] .open = generic_file_open,

[0135] .fsync = generic_file_fsync,

[0136] }

[0137] In some specific embodiments, the page cache operation table of the pre-allocated block file system can be defined as:

[0138] struct address_space_operations pabfs_aops={

[0139] .readpage = pabfs_readpage,

[0140] .readpages = pabfs_readpages,

[0141] .writepage = pabfs_writepage,

[0142] .writepages=pabfs_writepages,

[0143] .pabfs_aop_write_begin=pabfs_write_begin,

[0144] .pabfs_aop_write_end=pabfs_generic_write_end,

[0145] .bmap = pabfs_bmap

[0146] }

[0147] It should be understood that, although Figure 2 The steps in the flowchart are shown sequentially according to the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Figure 2 Unless otherwise expressly stated herein, the steps illustrated and other steps involved in the embodiments are not subject to strict order restrictions and may be performed in other orders. Furthermore, at least some steps in the foregoing embodiments may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but may be performed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but may be performed alternately or in turn with other steps or at least a portion of the sub-steps or stages of other steps.

[0148] In a second aspect, embodiments of this disclosure provide an apparatus for running a file system, the file system being used to manage video data, wherein the physical storage space corresponding to the file system is divided into a first storage space and a second storage space. For example... Figure 4As shown, the device 400 that runs a file system includes: a formatting module 410, a metadata generation module 420, a metadata storage module 430, and an operation instruction processing module 440.

[0149] The formatting module 410 is used to write the file system header information into the first storage space in response to a formatting command;

[0150] Metadata generation module 420 is used to generate file system metadata based on header information;

[0151] Metadata storage module 430 is used to store and retain file system metadata in the operating system memory so that the file system metadata remains unchanged during the operation of the file system. The file system metadata includes superblock information, directory entry information and inode information, and is used to map the second storage space into multiple block files with contiguous space addresses and the same capacity and attribute information.

[0152] The operation instruction processing module 440 is used to store the target video data into the target block file in the second storage space in response to the target video data write instruction.

[0153] In some embodiments, the metadata generation module 420 may include a header information acquisition unit and an information generation unit. The header information acquisition unit is used to read header information from the first storage space and initialize the superblock corresponding to the file system. The information generation unit is used to fill the header information into the superblock and generate the superblock information, inode information of the mounted root directory, and directory entry information of the file system. The superblock information includes at least the file system type information, inode, and number of block files; the inode information includes attribute information and file pointer information of multiple files under the file system root directory; and the directory entry information includes the filenames and inode numbers of all files.

[0154] In some embodiments, the metadata generation module 420 may further include an inode information generation unit for generating attribute information for multiple files in the root directory, wherein the attribute information of each file is identical. The attribute information of the multiple files in the file system root directory includes at least file permissions, file size, and file owner information.

[0155] In some embodiments, the apparatus running the file system may further include a file read / write module, configured to, in response to read / write operation instructions for a target file, determine the target address information of the target file in the second storage space based on the inode number of the corresponding file node of the target file, a preset offset, and a preset block file size, and then perform data reading or data writing on the target file according to the target address information. Here, the address information of any file in the file system corresponds to the filename and the block file size.

[0156] The file read / write module can also be used to respond to read / write operation commands for a target file. It determines the target address information of the target file in the second storage space based on the target file's filename, preset offset, and preset block file size, and then reads or writes data to the target file according to the target address information. In the file system, the address information of any file corresponds to the inode number of the corresponding file node and the block file size.

[0157] In some embodiments, the formatting module 410 can also be used to write header information into the first storage space and perform redundant backups in the first storage space.

[0158] For further specific limitations regarding the apparatus for running the file system, please refer to the limitations on the file system operation method described above. The apparatus for running the file system can also be used to perform further steps of the file system operation method in the first aspect of this disclosure, which will not be repeated here. Each module in the above-described apparatus for running the file system can be implemented entirely or partially through software, hardware, or a combination thereof. Each module can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0159] In a third aspect, embodiments of this disclosure provide a computer device, which may be a terminal, and its internal structure diagram may be as follows. Figure 5 As shown. The computer device includes a processor, memory, and network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements the file system operation method of any embodiment of the first aspect of this disclosure.

[0160] Those skilled in the art will understand that Figure 5 The structures shown are merely block diagrams of some structures related to the embodiments of this disclosure and do not constitute a limitation on the computer devices on which the embodiments of this disclosure are applied. Specific computer devices may include more or fewer components than those shown in the figures, or combine certain components, or have different component arrangements.

[0161] In a fourth aspect, embodiments of this disclosure provide a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the file system operation method provided in any embodiment of the first aspect of this disclosure.

[0162] The computer-readable storage medium may be Figure 5 The computer-readable storage medium in the computer device shown.

[0163] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The aforementioned computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this disclosure can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0164] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this disclosure.

[0165] The above embodiments merely illustrate several implementation methods of this disclosure, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of protection of this disclosure. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this disclosure, and these all fall within the scope of protection of this disclosure. Therefore, the scope of protection of this disclosure should be determined by the appended claims.

Claims

1. A method for operating a file system, characterized in that, The file system is used to manage video data, and the physical storage space corresponding to the file system is divided into a first storage space and a second storage space; the method includes: In response to a formatting command, the header information of the file system is written into the first storage space; Based on the header information, file system metadata is generated. The file system metadata includes superblock information, directory entry information, and inode information, which is used to map the second storage space into multiple block files with contiguous spatial addresses and identical capacity and attribute information. The file system metadata is stored and retained in the operating system memory so that the file system metadata remains unchanged during the operation of the file system; In response to a target video data write command, storing the target video data into a target block file in the second storage space includes: when all block files in the second storage space are in a full state, sequentially writing the target video data into each block file starting from the first block file in the second storage space, and sequentially overwriting the historical video data of each block file.

2. The method according to claim 1, characterized in that, The step of generating file system metadata based on the header information includes: Read the header information from the first storage space and initialize the superblock corresponding to the file system; The header information is filled into the superblock to generate the superblock information, inode information of the mounted root directory, and directory entry information of the file system; The superblock information includes at least the type information, inode, and number of block files of the file system; the inode information includes the attribute information and file pointer information of multiple files in the root directory of the file system; and the directory entry information includes the filenames and inode numbers of all files.

3. The method according to claim 2, characterized in that, The attribute information of multiple files in the root directory of the file system includes at least file permissions, file size, and file owner information; Generate inode information, including: generating attribute information for multiple files in the root directory, with all files having identical attribute information.

4. The method according to claim 2, characterized in that, The directory structure of the file system is a single-level structure; the index node of the file system includes only the root directory node and multiple file nodes corresponding to the number of block files; The index node number of the root directory node is configured to a fixed value. The index node numbers of each file node in the plurality of file nodes are sequentially increased starting from a preset starting number. The file names of the plurality of files corresponding to the plurality of file nodes are named sequentially according to a preset naming rule. There is a corresponding relationship between the index node number of any file node and its file name.

5. The method according to claim 4, characterized in that, The method further includes: In response to read / write operation commands for the target file, the target address information of the target file in the second storage space is determined based on the inode number of the corresponding file node, a preset offset, and a preset block file size; data is read or written to the target file based on the target address information; or, In response to read / write operation instructions for the target file, the target address information of the target file in the second storage space is determined based on the file name, preset offset, and preset block file size of the target file; data is read or written to the target file based on the target address information.

6. The method according to claim 1, characterized in that, The capacity of the block file corresponds to the number of fixed disk units per block file included in the header information; The number of block files in the second storage space corresponds to the number of block files included in the header information; or, The number of block files is determined by the capacity of the second storage space and the number of disk fixed units per unit block file.

7. The method according to claim 1, characterized in that, The step of writing the header information of the file system into the first storage space includes: The header information is written into the first storage space and redundant backups are performed in the first storage space.

8. An apparatus for running a file system, characterized in that, The file system is used to manage video data, and the physical storage space corresponding to the file system is divided into a first storage space and a second storage space; the device includes: A formatting module is used to write the header information of the file system into the first storage space in response to a formatting command; Metadata generation module, used to generate file system metadata based on the header information; The metadata storage module is used to store and retain the file system metadata in the operating system memory so that the file system metadata remains unchanged during the operation of the file system. The file system metadata includes superblock information, directory entry information and inode information, and is used to map the second storage space into multiple block files with contiguous space addresses and the same capacity and attribute information. An operation instruction processing module is used to respond to a target video data write instruction and store the target video data into a target block file in the second storage space, including: when all block files in the second storage space are in a full storage state, writing the target video data sequentially into each block file starting from the first block file in the second storage space, and sequentially overwriting the historical video data of each block file.

9. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Citation Information

Patent Citations

  • Space allocation fixing file memory system and implementation method

    CN102902709A

  • Metadata management on a storage device

    US20180024751A1