File system, file processing method, device, medium and product

Abstract

The invention relates to a file system, a file processing method, equipment, a medium and a product. The file system comprises an interface module, a file management module, a storage management module and a bottom layer driving module, the interface module is used for receiving an operation request of a target file; the file management module is used for acquiring target metadata of a target file from the file metadata based on the operation request; the target metadata comprises the file size of the target file and the initial address of the target file; and the storage management module is used for determining a storage block of the target file based on the file size of the target file and the initial address of the target file in the storage space of the file system, and calling the bottom layer driving module to carry out target processing corresponding to the operation request on the storage block of the target file. The user can process the file data in a file operation request mode, and the method has the advantages of being simple, convenient, light and safe.

Description

Technical Field

[0001] The present application relates to the field of vehicle technology, and in particular to a file system, a file processing method, a device, a medium, and a product. Background Art

[0002] With the rapid development of the automotive industry, in-vehicle electronic systems are becoming more and more complex, and the requirements for file systems are becoming higher and higher, including data security, real-time response, storage efficiency, and system reliability. Existing file systems cannot fully meet these requirements.

[0003] At present, system operation information and logs are generally recorded through the non-volatile memory of the basic software layer, and finally written into the flash for storage. The data is exported through diagnostic software or other methods, and then the data log is parsed according to the corresponding parsing format. This causes a certain degree of inconvenience for users to restore the scene and historical records during the fault debugging process.

[0004] Therefore, it is urgent to design a lightweight, secure, convenient and practical file processing system. Summary of the invention

[0005] One of the purposes of the present application is to provide a file system, file processing method, device, medium and product, through which users can process file data by means of file operation requests, which has the characteristics of being simple, convenient, lightweight and secure.

[0006] In order to achieve the above purpose, the technical solution adopted in this application is as follows:

[0007] In a first aspect, the present application provides a file system, the file system comprising: an interface module, a file management module, a storage management module and an underlying driver module; the interface module is used to: receive an operation request for a target file; the file management module is used to: obtain target metadata of the target file in the file metadata based on the operation request; the target metadata comprises: the file size of the target file and the starting address of the target file; the storage management module is used to: determine the storage block of the target file in the storage space of the file system based on the file size of the target file and the starting address of the target file, and call the underlying driver module to perform target processing corresponding to the operation request on the storage block of the target file.

[0008] It can be seen that in this implementation, the interface module can receive various operation requests for the target file, obtain the metadata in the target file through the file management module, and then call the storage block where the target file is located through the storage management module, so as to achieve the target processing of the target file. The interface module docks operations, the file management module manages metafiles, and the storage management module manages storage blocks, and the functional areas of each module are clear.

[0009] In this way, when the user needs to perform related operations on the target file, he can directly initiate an operation request, and process the file data through the cooperation of the interface module, file management module, storage management module and underlying driver module, which is simple, convenient, lightweight and secure.

[0010] In a possible implementation, the operation request includes at least one of the following: a create operation, an open operation, a read operation, a write operation, a close operation, and a delete operation; the file management module includes at least one of the following: a file creation interface, a file deletion interface, and a metadata acquisition interface; wherein: the file creation interface corresponds to a create operation; the file creation interface is used to create a target file; the file deletion interface corresponds to a delete operation; the file deletion interface is used to delete a target file; the metadata acquisition interface corresponds to at least one of an open operation, a read operation, a write operation, and a close operation; the metadata acquisition interface is used to acquire target metadata of the target file; the storage management module includes At least one of the following: a block writing submodule, a block reading submodule, a block applying submodule and a block space releasing submodule; wherein: the block writing submodule corresponds to a writing operation; the block writing submodule is used to call the writing function of the underlying driver module to write data to the target file; the block reading submodule corresponds to a reading operation; the block reading submodule is used to call the reading function of the underlying driver module to read data from the target file; the block applying submodule corresponds to a writing operation; the block applying submodule is used to apply for a storage block for the target file in the storage space; the space releasing submodule corresponds to a deleting operation; the space releasing submodule is used to call the erasing function of the underlying driver module to delete data from the target file.

[0011] It can be seen that in this implementation, for different operation requests, the file management module distinguishes the functions of the file management modules and storage management modules required for different operations, so that clear and convenient calls can be made. The convenience of the file system is improved. When performing file operations, the relevant submodules or interfaces can be directly called to implement, which decouples the connection with other submodules or interfaces and improves the lightweightness of the file system.

[0012] In one possible implementation, when the operation request includes a create operation, the create operation is used to request the creation of a target file; the file management module is also used to implement, through a file creation interface: searching in file metadata based on an identifier of the target file in the create operation; if the search is successful, feeding back a first prompt message; the first prompt message is used to prompt that the target file already exists and the creation fails; if the search fails, adding target metadata of the target file to the file metadata to achieve the creation of the target file.

[0013] It can be seen that in this implementation, the file creation is directly implemented through the file creation interface of the file management module, which has the characteristics of simple implementation and clear logic.

[0014] In a possible implementation, when the operation request includes an open operation or a close operation, the open operation is used to request to open the target file; the close operation is used to request to close the target file; the file management module is also used to obtain a metadata interface to implement: determining target metadata in the file metadata based on an identification of the target file in the open operation or the close operation; and outputting the target metadata to open the target file; or, stopping the output of the target metadata to close the target file.

[0015] It can be seen that in this implementation, the target metadata of the target file is obtained through the metadata acquisition interface of the file management module, so as to realize the opening and closing of the target file. It has the characteristics of simple implementation and clear logic.

[0016] In a possible implementation, when the operation request includes a read operation, the read operation is used to request to read data of a target file; the file management module is further used to implement, through an acquisition metadata interface: when it is determined that the target file is open, obtaining an offset address corresponding to a read position of the target file in the target metadata based on an identifier of the target file in the read operation; the storage management module is further used to implement, through a block read submodule: calling a read function of an underlying driver module, and reading data in the target file with the offset address as a starting address based on the offset address.

[0017] It can be seen that in this implementation, the target metadata of the target file is obtained through the metadata acquisition interface of the file management module, and the reading function is called through the block reading submodule of the file storage module, thereby realizing the reading of the target file. It has the characteristics of simple implementation, clear logic and light weight.

[0018] In a possible implementation, when the operation request includes a write operation, the write operation is used to request to write data to the target file; when it is determined that the target file is open, the storage management module is further used to: apply for a storage block for the target file in the storage space through a block application submodule; call the write function of the underlying driver module through the block write submodule to write the data to the storage block of the target file; the file management module is further used to obtain a metadata interface to implement: updating the target metadata based on the data size of the storage block written to the target file.

[0019] It can be seen that in this implementation, the target metadata of the target file is obtained through the metadata acquisition interface of the file management module, and the write function is called through the block writing submodule of the file storage module, thereby realizing the writing of the target file. It has the characteristics of simple implementation, clear logic and light weight.

[0020] In a possible implementation, when the operation request includes a deletion operation, the deletion operation is used to request deletion of the target file; the file management module is also used to implement through the file deletion interface: searching in the file metadata based on the identifier of the target file in the deletion operation; if the search fails, feeding back a second prompt message; the second prompt message is used to prompt that the target file does not exist and the deletion fails; if the search is successful, obtaining the target metadata corresponding to the target file in the file metadata; and obtaining the file size of the target file and the starting address of the target file in the target metadata; the storage management module is also used to: determine the storage block of the target file based on the file size of the target file and the starting address of the target file, and call the erase function of the underlying driver module through the space release submodule to delete the data of the storage block of the target file; the file management module is also used to delete the target metadata through the file deletion interface.

[0021] It can be seen that in this implementation, the target metadata of the target file is obtained and deleted through the file deletion interface of the file management module; the erase function is called through the space release submodule of the file storage module, thereby achieving the target file deletion. It has the characteristics of simple implementation, clear logic and light weight.

[0022] In a possible implementation, the file system further includes: a service module; the service module is used to: transmit the target data to the underlying driver module, so that the underlying driver module performs file processing on the target data in the service module.

[0023] It can be seen that in this embodiment, the underlying driver module can be connected to the service module to achieve management of the data of the service module. In this way, dependence on the operating system can be avoided and portability is high.

[0024] In a possible implementation, when the service module includes an automotive open system architecture AUTOSAR module, the target data includes at least one of the following: system operation data, fault data, and debugging data of the AUTOSAR service; the storage management module is also used to: apply for storage space for the file system in the storage medium based on the total storage required by the file system.

[0025] It can be seen that in this implementation, since AUTOSAR services do not allow dynamic memory allocation, the hardware storage resources are static for the entire operation cycle, so it is necessary to estimate and apply for the storage space required by the file system in advance during the initialization phase. This embodiment can be applied to file data processing in AUTOSAR services, which increases the scope of application.

[0026] In a second aspect, the present application provides a file processing method, which is applied to a file system, and the method includes: receiving an operation request for a target file; obtaining target metadata of the target file in the file metadata based on the operation request; the target metadata includes: the file size of the target file and the starting address of the target file; in the storage space of the file system, determining the storage block of the target file based on the file size of the target file and the starting address of the target file, and calling the underlying driver module to perform target processing on the storage block of the target file corresponding to the operation request.

[0027] It can be seen that in this implementation, various operation requests for target files can be received, metadata in the target file can be obtained, and then the storage block where the target file is located can be called to achieve the target processing of the target file. In this way, when the user needs to perform relevant operations on the target file, the operation request can be directly initiated to achieve the processing of the file data, which has the characteristics of simplicity, convenience, lightness and security.

[0028] In a possible implementation, when the operation request includes a read operation or a write operation, the method further includes: before performing the read operation or the write operation, acquiring a lock for protecting the target file; after performing the read operation or the write operation, releasing the lock for protecting the target file.

[0029] It can be seen that in this implementation, reading or writing based on the lock implementation can meet the needs of multi-task concurrent access and ensure data consistency and security.

[0030] In a third aspect, the present application further provides an electronic device, comprising a memory and a processor, wherein a computer program or instructions are stored in the memory, and when the computer program or instructions are executed by the processor, the method provided in the second aspect is implemented.

[0031] In a fourth aspect, the present application further provides a storage medium having a computer program or instruction stored thereon, and the computer program or instruction, when executed by a processor, implements the method provided in the second aspect above.

[0032] In a fifth aspect, the present application further provides a computer program product, which includes a computer program or instructions. When the computer program or instructions are executed by a processor, the method provided in the second aspect is implemented.

[0033] It should be noted that the technical effects of the fourth to fifth aspects can refer to the detailed description of the second aspect above, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] Figure 1 A schematic diagram of a first optional structure of a file system provided in an embodiment of the present application;

[0035] Figure 2 A second optional structural diagram of the file system provided in the embodiment of the present application;

[0036] Figure 3 A third optional structural diagram of the file system provided in the embodiment of the present application;

[0037] Figure 4 A first optional flow chart of the file processing method provided in the embodiment of the present application;

[0038] Figure 5 A second optional flow chart of the file processing method provided in the embodiment of the present application;

[0039] Figure 6 An optional flowchart of a block space release operation provided in an embodiment of the present application;

[0040] Figure 7 An optional flowchart of block writing and block reading provided in an embodiment of the present application;

[0041] Figure 8 A schematic diagram of an optional process for obtaining file metadata provided in an embodiment of the present application;

[0042] Fig. 9 An optional flowchart of creating a file provided in an embodiment of the present application;

[0043] Fig.10 An optional structural diagram of file metadata provided in an embodiment of the present application;

[0044] Fig.11 An optional flowchart of a process for deleting a file provided in an embodiment of the present application;

[0045] Fig.12 An optional structural diagram of a file system interface provided in an embodiment of the present application;

[0046] Fig.13 An optional flowchart of the process of opening a file provided in an embodiment of the present application;

[0047] Fig.14 An optional flowchart of a process of reading a file provided in an embodiment of the present application;

[0048] Fig.15 An optional flowchart of a process of writing a file provided in an embodiment of the present application;

[0049] Fig.16An optional structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0050] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the specific technical solution of the application will be further described in detail below in conjunction with the drawings in the embodiments of the present application. The following embodiments are used to illustrate the present application, but are not used to limit the scope of the present application.

[0051] In the following description, reference is made to “some embodiments”, which describe a subset of all possible embodiments, but it will be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0052] In the following description, the terms "first\second\third" are used only as examples to distinguish different objects, and do not represent a specific order for the objects, nor do they have a limitation on the order of precedence. It is understandable that "first\second\third" can be interchanged with a specific order or order of precedence where permitted, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0053] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application.

[0054] The embodiments of the present application provide a file system, a file processing method, a device, a medium, and a product. In the following, various embodiments of the file system, the file processing method, the device, the medium, and the product provided in the embodiments of the present application are described.

[0055] In a first aspect, an embodiment of the present application provides a file system. Figure 1 As shown, the file system 10 includes an interface module 101 , a file management module 102 , a storage management module 103 and an underlying driver module 104 .

[0056] The interface module 101 is used to receive an operation request for a target file; the file management module 102 is used to obtain target metadata of the target file in the file metadata based on the operation request; the target metadata includes: the file size of the target file and the starting address of the target file; the storage management module 103 is used to determine the storage block of the target file in the storage space of the file system based on the file size of the target file and the starting address of the target file, and call the underlying driver module 104 to perform target processing corresponding to the operation request on the storage block of the target file.

[0057] The interface module 101 can provide an application programming interface (API) for file operations, manage file handles and process file operation requests. In this way, the interface module can directly interface with operation requests from the application layer.

[0058] The target file refers to the file to be processed. The target file here can be any file.

[0059] The embodiment of the present application does not specifically limit the type of operation request, and can be configured according to implementation requirements. For example, the operation request may include but is not limited to at least one of the following: create operation, open operation, read operation, write operation, close operation and delete operation.

[0060] The file management module 102 is at least used to manage file metadata. Furthermore, the file management module 102 can also maintain the file system directory structure and manage file permissions and attributes.

[0061] The file metadata includes the metadata of each file. The target metadata is the metadata of the target file. The embodiment of the present application does not limit the content of the target metadata, and can be configured according to actual needs. The target metadata at least includes: the file size of the target file and the starting address of the target file. Furthermore, the target metadata may also include: the file identification, file permissions, file attribute information, etc. Of course, the target metadata may also include other information, which will not be listed here one by one.

[0062] The file size of the target file is used to represent the amount of data stored in the target file, or it can also represent the size of the storage space of the target file.

[0063] The starting address of the target file refers to the first address in the storage space used to store the target file.

[0064] The storage management module 103 determines the storage block of the target file based on the file size of the target file and the starting address of the target file, and calls the underlying driver module 104 to perform target processing corresponding to the operation request on the storage block of the target file.

[0065] The storage management module 103 can also be used for storing and reading file data, allocating and recycling storage blocks, and verifying data integrity.

[0066] The file system has a configured storage space. The embodiment of the present application does not limit the size and location of the storage space of the file system, and can be configured according to actual needs. The storage space of the file system can be divided into multiple storage blocks, and one file corresponds to one or more storage blocks.

[0067] The storage management module 103 may determine the address of the storage block to which the target file belongs, and then call the relevant functions of the underlying driver to implement target processing corresponding to the operation request.

[0068] It can be seen that in this implementation, the interface module can receive various operation requests for the target file, obtain the metadata in the target file through the file management module, and then call the storage block where the target file is located through the storage management module, so as to achieve the target processing of the target file. The interface module docks operations, the file management module manages metafiles, and the storage management module manages storage blocks, and the functional areas of each module are clear.

[0069] In this way, when the user needs to perform related operations on the target file, he can directly initiate an operation request, and process the file data through the cooperation of the interface module, file management module, storage management module and underlying driver module, which is simple, convenient, lightweight and secure.

[0070] Next, the operation request, the file management module 102, and the storage management module 103 are described.

[0071] refer to Figure 2 As shown in the content, the operation request includes at least one of the following: a create operation, an open operation, a read operation, a write operation, a close operation, and a delete operation.

[0072] refer to Figure 2 As shown in the content, the file management module 102 includes at least one of the following: a file creation interface 1021 , a file deletion interface 1022 , and a metadata acquisition interface 1023 .

[0073] Among them: the file creation interface 1021 corresponds to the creation operation; the file creation interface 1021 is used to create a target file.

[0074] The file deletion interface 1022 corresponds to a deletion operation; the file deletion interface 1022 is used to delete a target file.

[0075] The metadata acquisition interface 1023 corresponds to at least one of an open operation, a read operation, a write operation, and a close operation; the metadata acquisition interface 1023 is used to acquire target metadata of a target file.

[0076] The file creation interface 1021, the file deletion interface 1022 and the metadata acquisition interface 1023 can all be implemented through related functions and programs, and the specific implementation process will not be repeated here.

[0077] refer to Figure 2As shown, the storage management module 103 includes at least one of the following: a block writing submodule 1031 , a block reading submodule 1032 , a block applying submodule 1033 , and a block space releasing submodule 1034 .

[0078] Wherein: the block writing submodule 1031 corresponds to the writing operation; the block writing submodule 1031 is used to call the writing function of the bottom driver module to write data to the target file.

[0079] The block reading submodule 1032 corresponds to the reading operation; the block reading submodule 1032 is used to call the reading function of the underlying driver module to read data from the target file.

[0080] The block application submodule 1033 corresponds to the write operation; the block application submodule 1033 is used to apply for a storage block for a target file in the storage space.

[0081] The space release submodule 1034 corresponds to the deletion operation; the space release submodule 1034 is used to call the erasing function of the underlying driver module to delete data from the target file.

[0082] The block writing submodule 1031, the block reading submodule 1032, the block applying submodule 1033 and the block space releasing submodule 1034 can all be implemented through related functions and programs, and the specific implementation process will not be repeated here.

[0083] It can be seen that in this implementation, for different operation requests, the file management module distinguishes the functions of the file management modules and storage management modules required for different operations, so that clear and convenient calls can be made. The convenience of the file system is improved. When performing file operations, the relevant submodules or interfaces can be directly called to implement, which decouples the connection with other submodules or interfaces and improves the lightweightness of the file system.

[0084] The following describes the processing procedures of the file management module 102 and the storage management module 103 by taking different types of operations as examples.

[0085] In some embodiments, when the operation request includes a create operation, the create operation is used to request the creation of a target file.

[0086] The file management module 102 is also used to implement, through the file creation interface 1021: searching in the file metadata based on the identification of the target file in the creation operation; if the search is successful, feeding back a first prompt message; the first prompt message is used to prompt that the target file already exists and the creation fails; if the search fails, adding the target metadata of the target file in the file metadata to achieve the creation of the target file.

[0087] The file metadata includes metadata of multiple files. The metadata of each file corresponds to the identifier of the file, so the target metadata can be found by the identifier of the target file.

[0088] If the target metadata is found, it means that the target file already exists, that is, it has been created and cannot be created again, so the first prompt information and creation failure are fed back. The embodiment of the present application does not specifically limit the prompting method of the first prompt information, and can be configured according to actual needs. For example, it can be prompted by text or by an error mark.

[0089] If the search for the target metadata fails, it means that there is no file in the created file that duplicates the identifier of the target file, and the conditions for creating the target file are met. Then, the target metadata of the target file is configured according to the actual situation, and the target metadata of the target file is added to the file metadata. The target metadata here may include: the identifier of the target file. It may also include the file size and starting address of the target file, etc.

[0090] In practice, file metadata is also stored in the storage space of the file system. A storage space is applied for in advance in the storage space of the file system to store file metadata.

[0091] It can be seen that in these embodiments, the creation of files is directly achieved through the file creation interface of the file management module, which has the characteristics of simple implementation and clear logic.

[0092] In some embodiments, when the operation request includes an open operation or a close operation, the open operation is used to request to open the target file; the close operation is used to request to close the target file.

[0093] The file management module 102 is also used to achieve, through the metadata acquisition interface 1023: determining target metadata in the file metadata based on the identification of the target file in the opening operation or closing operation; and outputting the target metadata to open the target file; or, stopping the output of the target metadata to close the target file.

[0094] The implementation of determining the target metadata may refer to the description of the above creation process, which will not be repeated here.

[0095] It can be seen that in these embodiments, the target metadata of the target file is obtained through the metadata acquisition interface of the file management module, so as to realize the opening and closing of the target file. It has the characteristics of simple implementation and clear logic.

[0096] In some embodiments, when the operation request includes a read operation, the read operation is used to request to read data of a target file.

[0097] The file management module 102 is further used to obtain the following through the metadata acquisition interface 103: when it is determined that the target file is open, based on the identifier of the target file in the read operation, obtain the offset address corresponding to the read position of the target file in the target metadata.

[0098] Generally, a file needs to be confirmed to be open before it can be read. Therefore, when the operation request includes a read operation, it is necessary to first determine whether the target file is open. If it is determined that the target file is open, then execute the subsequent specific read operation. If it is determined that the target file is not open, then first open the target file based on the processing corresponding to the open operation, and then execute the subsequent specific read operation.

[0099] First, the offset address corresponding to the read position of the target file is obtained in the target metadata through the metadata acquisition interface 103. The offset address is used to indicate the start position of the read.

[0100] The storage management module 103 is also used to implement, through the block reading submodule 1032: calling the reading function of the bottom driver module 104, and reading the data in the target file with the offset address as the starting address based on the offset address.

[0101] The offset address here can also be zero or empty. When the offset address is zero or empty, the file is read from the beginning. In practice, the offset address records the position of the last read, and the offset address can be used to continue reading from the last position.

[0102] It can be seen that in these embodiments, the target metadata of the target file is obtained through the metadata acquisition interface of the file management module, and the reading function is called through the block reading submodule of the file storage module, thereby realizing the reading of the target file. It has the characteristics of simple implementation, clear logic and light weight.

[0103] In some embodiments, when the operation request includes a write operation, the write operation is used to request to write data in the target file.

[0104] When it is determined that the target file is open, the storage management module 103 is also used to: apply for a storage block for the target file in the storage space through the block application submodule 1033; call the write function of the underlying driver module through the block writing submodule 1031 to write data to the storage block of the target file; the file management module 102 is also used to achieve through the metadata acquisition interface 1023: update the target metadata based on the data size of the storage block written to the target file.

[0105] Generally, before writing to a file, it is necessary to determine whether the file is open. Therefore, when the operation request includes a write operation, it is necessary to first determine whether the target file is open. If it is determined that the target file is open, then perform the subsequent specific write operation. If it is determined that the target file is not open, first open the target file based on the processing corresponding to the open operation, and then perform the subsequent specific write operation.

[0106] The storage management module 103 first applies for a storage block for the target file in the storage space through the block application submodule 1033, and obtains the block number of the storage block of the target file. Then, the block writing submodule 1031 calls the writing function of the underlying driver module to write the data (the content to be written) to the storage block corresponding to the block number. Then, the target metadata is updated based on the size of the written data.

[0107] It can be seen that in this implementation, the target metadata of the target file is obtained through the metadata acquisition interface of the file management module, and the write function is called through the block writing submodule of the file storage module, thereby realizing the writing of the target file. It has the characteristics of simple implementation, clear logic and light weight.

[0108] In some embodiments, when the operation request includes a delete operation, the delete operation is used to request deletion of the target file.

[0109] The file management module 102 is also used to implement, through the file deletion interface 1022: searching in the file metadata based on the identifier of the target file in the deletion operation; if the search fails, feeding back a second prompt message; the second prompt message is used to prompt that the target file does not exist and the deletion fails; if the search is successful, obtaining the target metadata corresponding to the target file in the file metadata; and obtaining the file size of the target file and the starting address of the target file in the target metadata.

[0110] The file metadata includes metadata of multiple files. The metadata of each file corresponds to the identifier of the file, so the target metadata can be found by the identifier of the target file.

[0111] If the target metadata is not found, it means that the target file does not exist, that is, it cannot be deleted, so the second prompt information is fed back and the deletion fails. The embodiment of the present application does not specifically limit the prompting method of the second prompt information, and can be configured according to actual needs. For example, it can be prompted by text or by an error mark.

[0112] If the target metadata is found, it means that the target file exists in the created file and the condition for deleting the target file is met. Then, the target metadata corresponding to the target file is obtained from the file metadata; and the file size of the target file and the starting address of the target file are obtained from the target metadata.

[0113] The storage management module 103 is also used to: determine the storage block of the target file according to the file size of the target file and the starting address of the target file, and call the erasing function of the bottom driver module 104 through the space release submodule 1034 to delete the data of the storage block of the target file;

[0114] The file management module 102 is further configured to delete target metadata through the file deletion interface 1022 .

[0115] It can be seen that in this implementation, the target metadata of the target file is obtained and deleted through the file deletion interface of the file management module; the erase function is called through the space release submodule of the file storage module, thereby achieving the target file deletion. It has the characteristics of simple implementation, clear logic and light weight.

[0116] In some embodiments, reference Figure 3 As shown in the content, the file system also includes: a service module 105.

[0117] The service module 105 is used to transmit the target data to the bottom-level driver module 104, so that the bottom-level driver module 104 performs file processing on the target data in the service module.

[0118] The target data here is the data generated by the service module 105. In short, the file system 10 can be used to manage the data generated by the service module 105, and can directly interact with the underlying driver module through the service module 105.

[0119] The embodiment of the present application does not limit the specific type of the service module 105, and can be configured according to actual needs. For example, the service module 105 can be an automotive open system architecture AUTOSAR module.

[0120] It can be seen that in this embodiment, the underlying driver module can be connected to the service module to achieve management of the data of the service module. In this way, dependence on the operating system can be avoided and portability is high.

[0121] In some embodiments, when the service module includes an AUTOSAR module, the target data includes at least one of the following: system operation data, fault data, and debugging data of the AUTOSAR service.

[0122] It can be understood that the target data may also include other data of the AUTOSAR service, which will not be listed here one by one.

[0123] The storage management module 103 is further used to apply for storage space of the file system in the storage medium based on the total storage amount required by the file system.

[0124] In the classic AUTOSAR platform, dynamic memory allocation is not allowed, and the hardware storage resources are static for the entire operation cycle, so the storage space required by the file system needs to be estimated and initialized in advance during the initialization phase. That is, the storage management module 103 is also used to apply for the storage space of the file system in the storage medium based on the total storage required by the file system.

[0125] It can be seen that in this implementation, since AUTOSAR services do not allow dynamic memory allocation, the hardware storage resources are static for the entire operation cycle, so it is necessary to estimate and apply for the storage space required by the file system in advance during the initialization phase. This embodiment can be applied to file data processing in AUTOSAR services, which increases the scope of application.

[0126] In a second aspect, an embodiment of the present application provides a file processing method, which is applied to a file system. Figure 4 The method may include but is not limited to the following S401 to S403.

[0127] S401: Receive an operation request for a target file.

[0128] The implementation process of S401 can be implemented through the interface module 101. The implementation process can refer to the detailed description of the interface module 101, which will not be described in detail here.

[0129] S402: Acquire target metadata of the target file from the file metadata based on the operation request.

[0130] The target metadata includes: the file size of the target file and the starting address of the target file.

[0131] The implementation process of S402 can be implemented through the file management module 102. The implementation process can refer to the detailed description of the file management module 102, which will not be described in detail here.

[0132] S403: In the storage space of the file system, determine the storage block of the target file based on the file size of the target file and the starting address of the target file, and call the underlying driver module to perform target processing corresponding to the operation request on the storage block of the target file.

[0133] The implementation process of S403 can be implemented by the storage management module 103. The implementation process can refer to the detailed description of the storage management module 103, which will not be described in detail here.

[0134] It can be seen that in this implementation, various operation requests for target files can be received, metadata in the target file can be obtained, and then the storage block where the target file is located can be called to achieve the target processing of the target file. In this way, when the user needs to perform relevant operations on the target file, the operation request can be directly initiated to achieve the processing of the file data, which has the characteristics of simplicity, convenience, lightness and security.

[0135] In a possible implementation manner, when the operation request includes a read operation or a write operation, reference Figure 5 The process may also include but is not limited to the following S404 and S405.

[0136] S401: Receive an operation request for a target file.

[0137] The operation request here is a read operation or a write operation.

[0138] S402: Acquire target metadata of the target file from the file metadata based on the operation request.

[0139] S404: Before performing a read operation or a write operation, obtain a lock for protecting the target file.

[0140] The lock type used to protect the target file in the embodiment of the present application is not limited and can be configured according to actual needs. For example, the lock used to protect the target file can be a mutex lock or a spin lock.

[0141] S403: In the storage space of the file system, determine the storage block of the target file based on the file size of the target file and the starting address of the target file, and call the underlying driver module to perform target processing corresponding to the operation request on the storage block of the target file.

[0142] The target processing here is data reading or data writing.

[0143] S405: After performing the read operation or the write operation, release the lock used to protect the target file.

[0144] It can be seen that in this implementation, reading or writing based on the lock implementation can meet the needs of multi-task concurrent access and ensure data consistency and security.

[0145] Below, taking AUTOSAR service as an example, the file system provided by this embodiment of the present application is described.

[0146] With the rapid development of the automotive industry, in-vehicle electronic systems are becoming more and more complex, and the requirements for file systems are becoming higher and higher, including data security, real-time response, storage efficiency, and system reliability. Existing file systems cannot fully meet these requirements.

[0147] A file management system is disclosed in the related art, including: a file storage module; and an intermediate management module, which is configured to: generate an encapsulated operation interface; receive an operation request from an application layer module via the operation interface; and perform the requested operation on the file storage module in response to the operation request. The file management system and method according to the present invention enable the upper layer application to read, write, view, and delete files / folders in the bottom layer storage module, and can automatically detect and automatically recover bad blocks in the file storage module, with strong compatibility and portability.

[0148] This solution focuses on automatic detection and recovery of bad blocks in the file storage module. Compared with traditional embedded file systems, its ease of use and randomness are not well addressed.

[0149] The related technology also discloses a log processing method based on AUTOSAR, including: adding an Android log application, calling the application interface of the automotive open system architecture adaptive platform in an inter-process communication manner to read and set the log; the automotive open system architecture adaptive platform binds the protocol stack log, and uses the log output method provided by the automotive open system architecture adaptive platform log component to store the corresponding communication management and protocol stack logs, or output them to the designated port of the Ethernet network bus; using relevant commands to control the kernel log cache, process the log, and read the log to the log component of the automotive open system architecture adaptive platform.

[0150] This solution facilitates the management and call of logs, improves the efficiency of development and debugging, and is conducive to analyzing abnormal conditions of the operating system. This solution can achieve relatively high freedom of file logging based on the AUTOSAR adaptive platform, but it is highly dependent on the software platform and cannot be used without the Android system and the AUTOSAR adaptive platform. It cannot be used on the AUTOSAR classic platform and has certain limitations.

[0151] In the AUTOSAR classic platform, task and resource allocation follows the static principle. During the code writing and compilation stages, software and hardware resources have been allocated according to corresponding rules, especially memory resources, which cannot be dynamically adjusted in real time during system operation.

[0152] Based on this, the currently known system operation information and logs are generally recorded through the FEE, NVM, DET, DEM and other modules of the basic software layer, and finally written to the flash for storage. The data of non-volatile memory (NVM) is exported through diagnostic software or other methods, and then the data log is parsed according to the corresponding parsing format.

[0153] In this way, it is inconvenient for users to restore the scene and historical records during the fault debugging process. If a traditional file reading and writing method can be provided, users can record fault logs and conduct later diagnosis in any data format and file random reading and writing methods.

[0154] Based on this background, it is necessary to design a lightweight, secure, convenient and practical file system.

[0155] Based on the technical problem, this embodiment provides a file system and design method for the AUTOSAR classic platform, so as to achieve the purpose of saving system operation information, fault information, debugging information, etc. through traditional file management in the software development process. The method can realize basic file operations, and the file system can be integrated and mounted on the automobile controller software platform with NVM storage medium, running based on the AUTOSAR software architecture, and interacting with the storage medium through the hardware driver interface at the bottom layer, such as flash, SD card, etc.

[0156] The AUTOSAR CP-based file system provided in this embodiment includes: a file system interface module, a file management module, a storage management module, a bottom-level driver module, and an AUTOSAR service module.

[0157] The file system interface is used to implement the file input / output (IO) interface that can be directly called by the application layer and RTE, that is, to provide an application programming interface (API) for file operations, manage file handles, and process file operation requests.

[0158] The file management module is used to manage file metadata, maintain the file system directory structure, and manage file permissions and attributes.

[0159] The storage management module is used for storing and reading file data, allocating and recycling storage blocks, and verifying data integrity.

[0160] The low-level driver module is used to interact with the AUTOSAR software architecture.

[0161] The file system has the following advantages: 1. Under the premise of meeting the design specifications and functional safety standards of OSEK, no dynamic memory allocation strategy is introduced to ensure the security and stability of the system; 2. It uses traditional directory file management and use, which is more in line with the habits of traditional file systems and is more convenient to use; 3. It has low coupling with hardware and software platforms and systems, has no dependence, and can be transplanted without platform differences; 4. It supports multi-task concurrent access, implements the lock mechanism of file operations, and ensures data consistency and security; 5. Data verification and recovery mechanism, implements data verification and recovery mechanism in the storage management module, and ensures data integrity and reliability through verification and technology; 6. Seamless integration with AUTOSAR, through the AUTOSAR service module, realizes seamless integration of the file system and the AUTOSAR basic software module, and improves the modularity and scalability of the system.

[0162] The file system in this embodiment is described below. The file system includes from top to bottom: a file system interface, a file management module, a storage management module, and a bottom-level driver module. The bottom-level driver module can be connected to the AUTOSAR service module and complies with the AUTOSAR classic platform software architecture and specifications.

[0163] The bottom layer is the bottom driver module, which is used to interact with the hardware storage device and provide the hardware storage device erasing, reading and writing operation interface; the second layer is the storage management module, which is used for the storage and reading of file data, the allocation and recovery of storage blocks, and the integrity verification of data; the third layer is the file management module, which implements the file metadata reading and writing interface, the file deletion interface and the specific implementation of the creation interface; the top layer is the file system interface module, which is used to implement the file IO interface that can be directly called by the application layer and RTE, that is, to provide the file operation API, manage the file handle and process the file operation request.

[0164] Below, the design of each module is described in detail according to the bottom-up hierarchical calling structure.

[0165] Bottom-level driver module: interacts directly with the hardware and provides erase, read, and write functions for storage devices at the lowest hardware level. This part of the driver program can be provided by the manufacturer or use the standard interface in the MCAL driver.

[0166] Storage management module: includes four interfaces: block space writing, block space reading, block space application, and block space release. The following is a detailed description of the four interfaces:

[0167] Before performing block space operations, you need to apply for block space from the storage management module through block space application. In advance, allocate a fixed-size NVM area as the area used by the file system, initialize it, clear the area, and record the address of each byte in the area for later access. Traverse all block areas, query the first free block area through the flag of whether it is used, record the block number corresponding to the area and return it to the caller, and set the corresponding area to the used state.

[0168] The block space release operation is to release the block space corresponding to the passed block area number, call the erase interface in the underlying driver module to erase the area, and set the area to an idle state. Figure 6 As shown, the block space release operation may include: block space release 601, setting the free block to a used state 602; and end.

[0169] Block space writing, by passing in the applied block space number, calling the write interface in the underlying driver module to complete the write operation, and completing the integrity and accuracy verification of the data through the CRC32 algorithm.

[0170] Block space reading, by passing in the requested block space number, calling the read interface in the underlying driver module to complete the write operation, and completing the integrity and accuracy verification of the data through the CRC32 algorithm.

[0171] In simple terms, the process of block writing and block reading can be referred to Figure 7 The content shown may include: writing to block space 701; calling the underlying driver interface to write to the hardware block 702; ending; reading from block space 703; calling the underlying driver interface to read the hardware block 704; ending.

[0172] The file management module contains three interfaces: file creation, file deletion, and obtaining file metadata. The following is a detailed description of the three interfaces:

[0173] The steps to obtain file metadata are: according to the parameter file name passed in, traverse the entire file metadata list, find the corresponding file name, and return the corresponding file metadata structure to the caller. Figure 8 As shown, the process may include but is not limited to:

[0174] S801. Obtain file metadata.

[0175] S802: traverse the file metadata list.

[0176] S803: Search for a data list corresponding to the file name.

[0177] If the search is successful, execute the following S804; if the search fails, execute the following S805.

[0178] S804: Return the metadata structure content corresponding to the file.

[0179] S805, end.

[0180] The following describes the process of creating a file. Fig. 9 As shown in the content, the process may include but is not limited to the following S901 to S907.

[0181] S901. Check whether the file name is compliant.

[0182] Compliance is determined by searching and traversing the passed file name parameter string to see if it contains illegal characters and whether the naming complies with the specifications required by the platform and software.

[0183] If compliant, execute S902 below; if not compliant, execute S907 below.

[0184] S902: Check whether the file name already exists.

[0185] Check whether the file name or directory name already exists, and determine whether the file exists by searching and finding the file list data. If it exists, end the process and return an error code, otherwise continue to the next step.

[0186] S903: Allocate file descriptors and storage blocks.

[0187] Allocate file descriptors and file storage blocks. By retrieving all existing files in the file table, assign the unallocated file descriptor IDs to the new file and update the file table. When creating a file, since the file size is uncertain, the storage block size can be temporarily set to 0, and specific space allocation will be performed in the subsequent file writing process.

[0188] S904: Initialize file metadata.

[0189] like Fig.10 As shown, the file metadata 100 includes the following contents: file name 1001, file identity document (ID) 1002, file size 1003, the starting address of file storage 1004, file access permission mask 1005, file creation time 1006, file modification time 1007. Each file corresponds to a data structure, which is retrieved and managed through the file ID.

[0190] S905: Allocate file access permissions.

[0191] Set the corresponding access permissions according to the passed parameters and write them into the metadata table corresponding to the file for saving.

[0192] S906: Write the file metadata into the file table.

[0193] After the metadata initialization is completed in step S904, a corresponding file feature data structure is formed, and the data structure is saved in a non-volatile storage device by calling a storage device driver write interface.

[0194] S907. Return status code.

[0195] At this point, the file creation process is complete.

[0196] The following is an explanation of the process of deleting files. Fig.11 As shown in the content, the process may include but is not limited to the following S1101 to S1103.

[0197] S1101. Obtain file metadata.

[0198] Match the corresponding file metadata structure according to the file name or file ID passed in by the interface.

[0199] S1102. Release a storage block.

[0200] According to the information of the storage block corresponding to the file contained in the metadata acquired in step S301, the corresponding storage block space is released.

[0201] S1103: Delete the corresponding file metadata in the file table.

[0202] Delete all metadata corresponding to the file in the file metadata list. At this point, the file deletion process ends.

[0203] like Fig.12 As shown, the file system interface 120 includes interfaces for file creation 1201, opening 1202, reading 1203, writing 1204, closing 1205, and deleting 1206. RTE and application layer code perform corresponding file operations by calling these interfaces. The implementation of each interface will be described in detail below.

[0204] File creation can be completed by calling the file creation interface in the file management module.

[0205] The following describes the process of opening a file. Fig.13 As shown in the content, the process may include but is not limited to the following S1301 to S1304.

[0206] S1301, obtaining a metadata list corresponding to a file.

[0207] S1302: Determine whether the search is successful.

[0208] If so, execute the following S1303; if not, execute the following S1304.

[0209] S1303. Return file information.

[0210] S1304. Return status code.

[0211] Get the metadata data structure corresponding to the file, and retrieve the metadata list through the passed file name. If a match is found, check whether the file open flag is set. If so, return the corresponding file descriptor handle. Otherwise, return the complete corresponding data structure to the caller. If no match is found to the file name, the file is considered to not exist, and an error code is returned.

[0212] Returns file information. If the metadata corresponding to the correct file name can be successfully matched, all file information data corresponding to the file will be returned, including file ID, file size (File Size), and the starting address of the file's storage block (File Position). At this point, the file is opened successfully, the file open flag is set, and the file opening process ends.

[0213] The following is an explanation of the process of reading files. Fig.14 As shown in the content, the process may include but is not limited to the following S1401 to S1407.

[0214] S1401. Acquire lock.

[0215] First, acquire a mutex or spin lock to protect exclusive access to the file.

[0216] S1402: Obtain file metadata.

[0217] According to the passed file descriptor handle, determine whether the file is open. If it is not open, reading the file is not allowed and an error code is returned. If the file is already open, obtain the corresponding file metadata and save it in a local variable.

[0218] S1403: Calculate the block number and offset address.

[0219] According to the file attribute (position) in the metadata obtained in step S1402, the storage block area number where the file is located can be calculated, and the storage block offset address where the file is located can also be calculated, so that the file content can be accurately accessed according to the address later.

[0220] S1404: Call the block read interface.

[0221] Call the block reading interface, and call the block reading interface in the storage management module to read the storage content according to the file offset address and block number obtained in step S1403.

[0222] S1405: File pointer position offset.

[0223] After the file content is read, the pointer needs to be offset accordingly so that the next read and write can accurately locate the file content position.

[0224] S1406: Update file metadata.

[0225] The file metadata updated in step S1405 is updated into the file metadata list.

[0226] S1407: Release the lock.

[0227] Release the mutex lock or spin lock. At this point, the file reading process ends.

[0228] The following describes the process of writing files. Fig.15 As shown in the content, the process may include but is not limited to the following S1501 to S1506.

[0229] S1501. Acquire lock.

[0230] First, acquire a mutex or spin lock to protect exclusive access to the file.

[0231] S1502: Obtain file metadata.

[0232] According to the passed file descriptor handle, determine whether the file is open. If it is not open, writing to the file is not allowed and an error code is returned. Otherwise, the corresponding file metadata is obtained and saved in a local variable.

[0233] S1503: Block space number application.

[0234] Apply for a free block number by calling the block space application interface in the storage management module.

[0235] S1504, block space writing.

[0236] Through the block space number obtained in step S1503, as well as the passed-in file content and size, the block space write interface in the storage block management module is called to write the file content.

[0237] S1505: Update metadata.

[0238] After writing the content, modify the file size in the metadata accordingly and return the size of the successfully written file content.

[0239] S1506: Release the lock.

[0240] Release the mutex lock or spin lock. At this point, the file writing process ends.

[0241] The file closing interface is implemented as follows: by passing in the file handle, it is determined whether the file is in an open state. If it is not open, the relevant error code is returned. If it is open, the corresponding metadata is obtained and the file open flag is set to FALSE, which means that the file cannot be accessed at this time, and the metadata is updated at the same time.

[0242] The file deletion interface is implemented by calling the file deletion interface in the file management module.

[0243] So far, basic file operations have been implemented through four modules, and a file interface that can be called by the application layer has been provided, and the four modules have been integrated into the BSW components in the AUTOSAR architecture. The interface between the AUTOSAR basic software (such as MemStack, ComStack) and the file system module can be configured to ensure communication and data interaction between the modules. The necessary configuration code is generated through the AUTOSAR configuration tool, and the file system interface is used in the application layer.

[0244] The above steps describe in detail how to embed the file system design based on the AUTOSAR CP platform into the AUTOSAR software architecture, including module layering, interface definition, RTE configuration, underlying driver, and integration with AUTOSAR basic software. Through these steps, the file system can run safely and reliably in the AUTOSAR environment.

[0245] In a third aspect, the present application further provides an electronic device, comprising a memory and a processor, wherein a computer program or instructions are stored in the memory, and when the computer program or instructions are executed by the processor, the method provided in the second aspect is implemented.

[0246] Combine the following Fig.16 The electronic device 160 shown is a block diagram of the electronic device.

[0247] In one example, if Fig.16 As shown, the electronic device 160 includes: a processor 1601, at least one communication bus 1602, at least one external communication interface 1603 and a memory 1604. The communication bus 1603 is configured to realize the connection and communication between these components. The external communication interface 1603 may include a standard wired interface and a wireless interface.

[0248] The memory 1604 is configured to store instructions and applications executable by the processor 1601, and can also cache data to be processed or processed by the processor 1601 and various modules in the electronic device (for example, image data, audio data, voice communication data, and video communication data), which can be implemented through flash memory (FLASH) or random access memory (Random Access Memory, RAM).

[0249] In a fourth aspect, an embodiment of the present application provides a storage medium, that is, a computer-readable storage medium, on which a computer program or instructions are stored. When the computer program or instructions are executed by a processor, the method provided in the second aspect above is implemented.

[0250] In a fifth aspect, an embodiment of the present application provides a computer program product, which includes a computer program or instructions. When the computer program or instructions are executed by a processor, the method provided in the second aspect is implemented.

[0251] It should be noted here that the description of the above storage medium, device, and program product embodiments is similar to the description of the above method embodiments, and has similar beneficial effects as the method embodiments. For technical details not disclosed in the storage medium, device, apparatus, and program product embodiments of this application, please refer to the description of the method embodiments of this application for understanding.

[0252] It should be understood that "one embodiment" or "an embodiment" mentioned throughout the specification means that specific features, structures or characteristics related to the embodiment are included in at least one embodiment of the present application. Therefore, "in one embodiment" or "in some embodiments" appearing throughout the specification may not necessarily refer to the same embodiment. In addition, these specific features, structures or characteristics can be combined in one or more embodiments in any suitable manner. It should be understood that in various embodiments of the present application, the size of the sequence number of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiment of the present application. The above-mentioned sequence numbers of the embodiments of the present application are for description only and do not represent the advantages and disadvantages of the embodiments.

[0253] It should be noted that, in this article, the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "comprises a ..." does not exclude the existence of other identical elements in the process, method, article or device including the element.

[0254] In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are only schematic. For example, the division of units is only a logical function division. There may be other division methods in actual implementation, such as: multiple units or components can be combined, or can be integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the components shown or discussed can be through some interfaces, and the indirect coupling or communication connection of devices or units can be electrical, mechanical or other forms.

[0255] The units described above as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units; they may be located in one place or distributed on multiple network units; some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0256] In addition, all functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may be a separate unit, or two or more units may be integrated into one unit; the above-mentioned integrated units may be implemented in the form of hardware or in the form of hardware plus software functional units.

[0257] A person skilled in the art can understand that all or part of the steps of implementing the above method embodiment can be completed by hardware related to program instructions, and the aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it executes the steps of the above method embodiment; and the aforementioned storage medium includes: mobile storage devices, read-only memories (ROM), magnetic disks or optical disks, etc., various media that can store program codes.

[0258] Alternatively, if the above-mentioned integrated unit of the present application is implemented in the form of a software function module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application can essentially or in other words, the part that contributes to the relevant technology can be embodied in the form of a software product, which is stored in a storage medium and includes a number of instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the methods of each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as mobile storage devices, ROMs, magnetic disks, or optical disks.

[0259] The above description is only an implementation method of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A file system, characterized in that: The file system includes: an interface module, a file management module, a storage management module and a bottom-level driver module; The interface module is used to: receive an operation request for a target file; The file management module is used to: obtain target metadata of the target file in the file metadata based on the operation request; the target metadata includes: the file size of the target file and the starting address of the target file; The storage management module is used to: determine the storage block of the target file in the storage space of the file system based on the file size of the target file and the starting address of the target file, and call the underlying driver module to perform target processing corresponding to the operation request on the storage block of the target file.

2. The file system according to claim 1, characterized in that: The operation request includes at least one of the following: a create operation, an open operation, a read operation, a write operation, a close operation, and a delete operation; The file management module includes at least one of the following: a file creation interface, a file deletion interface, and a metadata acquisition interface; wherein: The file creation interface corresponds to the creation operation; the file creation interface is used to create a target file; The file deletion interface corresponds to the deletion operation; the file deletion interface is used to delete the target file; The metadata acquisition interface corresponds to at least one of the open operation, the read operation, the write operation and the close operation; the metadata acquisition interface is used to acquire target metadata of the target file; The storage management module includes at least one of the following: a block writing submodule, a block reading submodule, a block application submodule, and a block space release submodule; wherein: The block writing submodule corresponds to the writing operation; the block writing submodule is used to call the writing function of the bottom driver module to write data to the target file; The block reading submodule corresponds to the reading operation; the block reading submodule is used to call the reading function of the bottom driver module to read data from the target file; The block application submodule corresponds to the write operation; the block application submodule is used to apply for a storage block for the target file in the storage space; The space release submodule corresponds to the deletion operation; the space release submodule is used to call the erasing function of the underlying driver module to delete data from the target file.

3. The file system according to claim 2, characterized in that: In the case where the operation request includes a create operation, the create operation is used to request the creation of a target file; The file management module is also used to implement through the file creation interface: Searching in file metadata based on the identifier of the target file in the creation operation; If the search is successful, the first prompt information is fed back; The first prompt information is used to prompt that the target file already exists and creation fails; If the search fails, the target metadata of the target file is added to the file metadata to achieve the creation of the target file.

4. The file system according to claim 2, characterized in that: In the case where the operation request includes an open operation or a close operation, the open operation is used to request to open the target file; the close operation is used to request to close the target file; The file management module is also used to implement, through the metadata acquisition interface: Determining the target metadata in the file metadata based on an identification of the target file in the open operation or the close operation; and outputting the target metadata to open the target file; Alternatively, the output of the target metadata is stopped to close the target file.

5. The file system according to claim 2, characterized in that: In the case where the operation request includes a read operation, the read operation is used to request to read data of a target file; The file management module is further used to implement, through the metadata acquisition interface: when it is determined that the target file is open, acquiring an offset address corresponding to a read position of the target file in the target metadata based on an identifier of the target file in the read operation; The storage management module is also used to implement, through the block reading submodule: calling the reading function of the underlying driver module, and reading the data in the target file with the offset address as the starting address based on the offset address.

6. The file system according to claim 2, characterized in that: In the case where the operation request includes a write operation, the write operation is used to request to write data in the target file; In the case where it is determined that the target file is opened, the storage management module is further used to: apply for a storage block for the target file in the storage space through the block application submodule; call the write function of the underlying driver module through the block writing submodule to write data into the storage block of the target file; The file management module is further used to implement, through the metadata acquisition interface: updating the target metadata based on the data size of the storage block written into the target file.

7. The file system according to claim 2, characterized in that: In the case where the operation request includes a delete operation, the delete operation is used to request deletion of a target file; The file management module is also used to implement through the file deletion interface: Searching in the file metadata based on the identifier of the target file in the deletion operation; if the search fails, feeding back a second prompt information; The second prompt information is used to prompt that the target file does not exist and the deletion fails; If the search is successful, then the target metadata corresponding to the target file is obtained from the file metadata; and the file size of the target file and the starting address of the target file in the target metadata are obtained; The storage management module is also used to: determine the storage block of the target file according to the file size of the target file and the starting address of the target file, and call the erasing function of the bottom driver module through the space release submodule to delete the data of the storage block of the target file; The file management module is also used to delete the target metadata through the file deletion interface.

8. The file system according to claim 1, characterized in that: The file system further includes: a service module; The service module is used to transmit the target data to the bottom-level driving module, so that the bottom-level driving module performs file processing on the target data in the service module.

9. The file system according to claim 8, characterized in that: In the case where the service module includes an automotive open system architecture AUTOSAR module, the target data includes at least one of the following: system operation data, fault data, and debugging data of the AUTOSAR service; The storage management module is further used to apply for storage space of the file system in a storage medium based on the total storage amount required by the file system.

10. A file processing method, characterized in that: The method is applied to a file system, and the method comprises: Receive an operation request for a target file; Acquire target metadata of the target file in the file metadata based on the operation request; the target metadata includes: the file size of the target file and the starting address of the target file; In the storage space of the file system, the storage block of the target file is determined based on the file size of the target file and the starting address of the target file, and the underlying driver module is called to perform target processing corresponding to the operation request on the storage block of the target file.

11. The method according to claim 10, characterized in that In the case where the operation request includes a read operation or a write operation, the method further includes: Before performing the read operation or the write operation, acquiring a lock for protecting the target file; After performing the read operation or the write operation, the lock used to protect the target file is released.

12. An electronic device, characterized in that: The electronic device comprises a memory and a processor, wherein a computer program or instructions are stored in the memory, and when the computer program or instructions are executed by the processor, the method of claim 10 or claim 11 is implemented.

13. A computer-readable storage medium, characterized in that: The storage medium stores a computer program or an instruction, and when the computer program or the instruction is executed by the processor, the method of claim 10 or claim 11 is implemented.

Images