Method for improving capital and small case insensitive conversion performance

Abstract

The invention provides a method and device for improving case and case insensitive conversion performance, electronic equipment and a computer readable storage medium. According to the method for improving the capital and small case insensitive conversion performance, directory traversal operation caused by capital and small case mismatching can be effectively reduced, the file access performance is remarkably improved, and system resource consumption is reduced.

Description

Technical Field

[0001] This invention relates to the field of case-insensitive file access optimization technology in distributed storage systems, and in particular to a method for improving the performance of case-insensitive conversion. Background Technology

[0002] In distributed storage systems, file access performance optimization is one of the core technologies for ensuring efficient system operation. With the continuous development of cloud computing and enterprise-level storage architectures, the demand for cross-platform file sharing is increasing, especially in scenarios where Linux and Windows systems are deployed in a hybrid manner. As a mainstream file sharing protocol, the compatibility and performance of the SMB (Server Message Block) protocol directly impact overall storage efficiency. Specifically, the SMB protocol layer needs to implement a case-insensitive filename matching mechanism to adapt to the access habits of Windows clients. This mechanism typically involves key steps such as filename parsing, directory traversal, and case comparison, among which directory traversal operations become a performance bottleneck in large-scale file scenarios.

[0003] However, in existing case-insensitive lookup methods, when the server receives a request with a case mismatch between the filename and the actual filename, it typically needs to traverse the entire directory for item-by-item comparison, triggering numerous readdir calls. This leads to a significant increase in access latency, especially when the number of files in the directory reaches tens of thousands, causing a surge in CPU utilization and severely impacting the IOPS and throughput of the storage cluster. Furthermore, this process lacks effective caching mechanisms and interface support, making efficient collaboration in multi-level systems impossible, thus limiting the overall system's scalability and stability. Summary of the Invention

[0004] The present invention aims to at least partially solve one of the technical problems in the related art.

[0005] Therefore, the first objective of this invention is to provide a method for improving case-insensitive conversion performance.

[0006] The second objective of this invention is to provide a device for improving the performance of case-insensitive conversion.

[0007] The third objective of this invention is to provide an electronic device.

[0008] The fourth objective of this invention is to provide a computer-readable storage medium.

[0009] The fifth objective of this invention is to provide a computer program product.

[0010] To achieve the above objectives, a first aspect of the present invention proposes a method for improving the performance of case-insensitive conversion, comprising: S1, receiving a file access request sent by a client and obtaining the filename to be accessed contained in the request; S2, based on the filename to be accessed, performing the following lookup operations in sequence: firstly, querying whether a mapping relationship between the filename to be accessed and the real filename exists in the cache; if it exists, using the real filename for file access; if it does not exist, calling the real filename acquisition interface added in the file system layer, passing in the parent path and the filename to be accessed, to obtain the real filename that matches the case; S3, if the real filename is obtained through the interface, writing the mapping relationship between the real filename and the filename to be accessed into the cache, and continuing to perform file access operations based on the real filename; if the real filename is not obtained, traversing the parent directory of the file, comparing the filenames in the directory with the filename to be accessed in a case-insensitive manner to determine the real filename; S4, writing the real filename determined by traversing the directory into the cache, and completing subsequent file access operations based on the real filename.

[0011] In one embodiment of the present invention, receiving a file access request sent by a client and obtaining the file name to be accessed contained in the request further includes: S11, the file access request is an Open request in the SMB protocol, and the file name to be accessed is carried by the client in the request message; S12, the file name to be accessed includes, but is not limited to, the file name part in the file path, and supports the parsing of file names containing special characters.

[0012] In one embodiment of the present invention, the step of performing the following search operations sequentially based on the file name to be accessed further includes: S21, querying whether there is a mapping relationship between the file name to be accessed and the real file name in the cache, and using the LRU algorithm to manage the cache to ensure that the cache capacity is controllable and the hit rate is high; S22, calling the real file name acquisition interface newly added in the file system layer, including converting the file name to be accessed into all lowercase form before searching, so as to improve the interface matching efficiency.

[0013] In one embodiment of the present invention, if the real file name is obtained through the interface, the step of writing the mapping relationship between the real file name and the file name to be accessed into the cache further includes: S31, when the case of the real file name returned by the interface is inconsistent with that of the file name to be accessed, the mapping relationship between the two is written into the cache in the form of key-value pairs; S32, the writing operation is executed immediately after the interface is successfully called, so as to ensure that subsequent accesses with the same file name can directly hit the cache.

[0014] In one embodiment of the present invention, the method further includes: S5, when it is detected that the file name has been renamed, updating the mapping relationship related to the file name in the cache to ensure that the cached data is consistent with the real file name in the storage system.

[0015] To achieve the above objectives, a second aspect of the present invention provides an apparatus for improving the performance of case-insensitive conversion, comprising: a file request receiving module, configured to receive a file access request sent by a client and obtain the filename to be accessed contained in the request; a filename lookup execution module, configured to perform the following lookup operations sequentially based on the filename to be accessed: firstly, querying whether a mapping relationship between the filename to be accessed and the real filename exists in the cache; if it exists, using the real filename for file access; if it does not exist, calling a real filename acquisition interface added in the file system layer, passing in the parent path and the filename to be accessed, to obtain a case-matched real filename; a real filename processing module, configured to, if the real filename is obtained through the interface, write the mapping relationship between the real filename and the filename to be accessed into the cache, and continue to perform file access operations based on the real filename; if the real filename is not obtained, traversing the parent directory of the file, comparing the filenames in the directory with the filename to be accessed in a case-insensitive manner to determine the real filename; and a cache update and access execution module, configured to write the real filename determined by traversing the directory into the cache, and complete subsequent file access operations based on the real filename.

[0016] To achieve the above objectives, a third aspect of the present invention provides an electronic device, comprising: a processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of the first aspects.

[0017] To achieve the above objectives, a fourth aspect of the present invention provides a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, are used to implement the method as described in any one of the first aspects.

[0018] To achieve the above objectives, a fifth aspect of the present invention provides a computer program product that, when executed by a processor, implements the method described in any one of the first aspects.

[0019] The technical solutions provided by the embodiments of the present invention bring at least the following beneficial effects: effectively reducing directory traversal operations, improving cross-platform file access performance, and reducing system resource consumption.

[0020] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0021] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 This is a flowchart of a method for improving case-insensitive conversion performance according to an embodiment of the present invention; Figure 2 This is a schematic diagram of a device for improving case-insensitive conversion performance according to an embodiment of the present invention. Detailed Implementation

[0022] Embodiments of the present invention are described in detail below, examples of which are illustrated in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain the present invention, and should not be construed as limiting the present invention.

[0023] Figure 1 This is a flowchart of a method for improving case-insensitive conversion performance according to an embodiment of the present invention.

[0024] like Figure 1 As shown, the method to improve the performance of case-insensitive conversion includes the following steps: S1 receives a file access request from the client and retrieves the filename to be accessed contained in the request. Specifically, in this invention, "receiving a file access request sent by the client and obtaining the filename to be accessed contained in the request" is the key initial step in the entire case-insensitive conversion process. This step is technically implemented based on the SMB (Server Message Block) protocol on a Linux system, specifically through the Samba service for communication between the client and server.

[0025] At the technical implementation level, the server listens on the SMB protocol's TCP port (usually port 445) to receive file access requests from clients. This request is typically encapsulated in the SMB protocol's "open" or "create" command, containing the filename the client wishes to access (e.g., AAA.txt). Upon receiving the request, the server first parses the request message, extracting the filename field. This field is usually located in the "path" parameter of the SMB request, and its format conforms to the SMB protocol specification (e.g., the UTF-8 encoded path format defined in the SMB 3.1.1 standard). During parsing, the server needs to standardize the path, including removing redundant path symbols (such as "..") and resolving symbolic links, to ensure the accuracy of subsequent processing.

[0026] At the parameter level, the length of the filename field is typically limited by the maximum path length limit of the SMB protocol (e.g., MAX_PATH_LENGTH = 260 bytes), while also supporting the Unicode character set for compatibility with multilingual environments. When receiving a request, the server needs to record context information such as the client's IP address, session ID, and shared path for subsequent cache management and access control. Furthermore, the case sensitivity of the filename (e.g., all uppercase, all lowercase, mixed case) directly affects whether a case-insensitive lookup process is triggered.

[0027] At the application level, this step is widely used in cross-platform file sharing scenarios, especially when Windows clients access Linux storage systems. For example, in enterprise-level distributed storage systems, when users access files in a shared directory via Windows clients, the server must adapt the received filenames to ensure correctness and performance because Windows is case-insensitive by default, while Linux is case-sensitive.

[0028] The technical benefit of this step is that it provides accurate input data for the subsequent case-insensitive conversion process, serving as a prerequisite for triggering cache queries and file system interface calls. By efficiently and accurately extracting and parsing the filenames sent by the client, the server can quickly determine whether case conversion is necessary. This significantly reduces the number of readdir operations and improves overall access performance, especially when dealing with a large number of directory files.

[0029] Furthermore, S1 includes: S11, the file access request is an Open request in the SMB protocol, and the file name to be accessed is carried by the client in the request message.

[0030] Specifically, in this invention, the file access request is an Open request in the SMB protocol, initiated by the client to open or create a file. In this request message, the client carries the filename to be accessed (FileName), which may differ in case from the actual filename stored on the storage device. For example, the client sends "AAA.txt", while the actual filename on the storage device is "aaa.txt". Since the Linux file system is case-sensitive, while Windows clients are typically case-insensitive, case-insensitive filename matching is required at the SMB protocol layer.

[0031] At the technical implementation level, after receiving an Open request, the server first attempts to open the file using the filename provided by the client. If the opening fails, a case-insensitive search process is initiated. At this point, the server checks a newly added cache for a mapping record between the client's filename and the real filename. If a match is found, the real filename is used directly for subsequent operations, avoiding directory traversal. If no match is found, a new interface added to the file system layer (such as get_real_filename()) is called, passing in the parent directory path and the filename to be searched. This interface performs a case-insensitive filename matching and returns the real filename. If the interface returns successfully, the server uses the real filename to continue processing Open requests and writes the mapping relationship into the cache for reuse in subsequent requests.

[0032] At the parameter level, the cache implementation can adopt an LRU or LFU caching strategy, with a cache capacity configurable from 1024 to 8192 entries and a cache item expiration time (TTL) set from 300 to 3600 seconds to balance cache hit rate and memory usage. The file system interface implementation must comply with the POSIX standard and be compatible with mainstream Linux file systems such as EXT4 and XFS. Its lookup efficiency should be controlled within 1 to 5ms to ensure overall performance improvement.

[0033] At the application level, this step is widely applicable to Linux-based distributed storage systems, especially in scenarios where Windows clients and Linux storage devices are interconnected via Samba. When clients access files with non-case-sensitive access via command line, scripts, or applications, this mechanism can effectively reduce the performance loss caused by readdir operations, especially in high-concurrency storage environments with large directory structures, where it has a significant optimization effect.

[0034] This step plays a crucial role in the overall technical solution. By introducing a caching mechanism and a file system interface, it effectively shortens the response time of case-insensitive lookups, improves file access efficiency, and thus enhances the overall performance and stability of the system. It has high practical value and innovation.

[0035] S12, the filename to be accessed includes, but is not limited to, the filename part in the file path, and filename parsing containing special characters is supported.

[0036] Specifically, this step involves parsing the "filename to be accessed." Its technical implementation is based on optimizing the filename processing logic in the SMB protocol, aiming to improve the efficiency of case-insensitive conversion. In Linux systems, file systems (such as ext4 and XFS) are case-sensitive by default, while Windows clients typically handle filenames in a case-insensitive manner when accessing files via the SMB protocol. Therefore, when the filename sent by the client differs in case from the actual filename on the storage device, the server needs to perform a case-insensitive lookup process. This process usually relies on directory traversal and item-by-item comparison, which is inefficient.

[0037] In this invention, the filename to be accessed includes not only the filename portion of the file path but also supports parsing filenames containing special characters (such as "@", "#", "%", "_", "-", ".", "$", etc.). Specifically, after receiving the filename sent by the client, the server first attempts to directly open the file corresponding to that filename. If opening fails, a case-insensitive search process is initiated. In this process, the system standardizes special characters in the filename, for example, by decoding URL-encoded characters or converting non-ASCII characters to UTF-8 encoding to ensure consistency of filenames across different systems.

[0038] Furthermore, this step introduces a caching mechanism and collaborative processing with the file system interface during filename parsing. The cache stores the mapping between the client's requested filename and the actual filename stored on the storage side. The cache key can be a standardized filename (e.g., all lowercase or all uppercase), and the cache value is the actual stored filename. Parameters such as cache hit rate, maximum number of cache entries (e.g., a default setting of 10240), and cache expiration time (TTL, e.g., 300 seconds) can be dynamically configured according to system load and performance requirements, conforming to POSIX standards and the SMB 3.1.1 protocol specification.

[0039] This step is widely applicable in practical applications for cross-platform file access scenarios in distributed storage systems. Particularly when Windows clients access Linux storage nodes via Samba, it significantly reduces the number of `readdir` calls caused by case mismatches, thereby reducing I / O latency and improving overall throughput. Its technical value lies in effectively alleviating the performance bottleneck caused by directory traversal through intelligent caching and interface optimization, enhancing system responsiveness and stability.

[0040] S2, based on the filename to be accessed, perform the following lookup operations in sequence: First, check if there is a mapping relationship between the filename to be accessed and the real filename in the cache. If it exists, use the real filename to access the file. Specifically, in this invention, the step "based on the filename to be accessed, perform the following lookup operations sequentially: first, check if there is a mapping relationship between the filename to be accessed and the real filename in the cache; if so, use the real filename to access the file" is one of the core mechanisms for improving the case-insensitive conversion performance of the SMB protocol in Linux systems. The technical implementation principle of this step is based on the collaborative optimization of the caching mechanism and the file system interface, aiming to reduce directory traversal operations caused by case mismatch, thereby reducing system latency and improving overall access efficiency.

[0041] At the technical implementation level, this step first introduces a case-mapping cache on the SMB server. This cache stores the mapping between filenames used in client requests (which may be case-incorrect) and the actual filenames (case-correct) that exist in the storage system. The cache structure typically uses a hash table or LRU cache to support fast lookups and dynamic updates. When a client sends a filename request (such as "AAA.txt"), the server first attempts to open the file using that filename. If that fails, it proceeds to the cache lookup phase.

[0042] At the parameter level, cache capacity, time-to-live (TTL), and hit rate are key performance parameters. For example, the cache capacity can be set to 1024-8192 records to balance memory usage and hit efficiency; the TTL of cached items can be set to 300 seconds to 5 minutes to ensure that cached data is valid within a reasonable time and to avoid cache pollution caused by filename changes. In addition, the time complexity of cache lookups should be controlled to O(1) or O(log n) to ensure fast response in high-concurrency scenarios.

[0043] At the application level, this step is suitable for cross-platform file sharing environments, especially SMB protocol communication between Windows clients and Linux servers. In actual deployments, when clients access files in non-standard case via command line, scripts, or applications, the server can directly locate the real filename through cache lookup, avoiding time-consuming readdir system calls and item-by-item comparison operations, thereby significantly improving file access performance.

[0044] The technical effect of this step is that, through the cache hit mechanism, the directory traversal operation, which originally required O(n) complexity, can be reduced to an O(1) hash lookup, greatly reducing the number of system calls and CPU overhead. In large-scale file directories, this optimization can reduce file access latency by 30% to 70%, improve system throughput, and enhance the stability and responsiveness of SMB services in high-concurrency and high-load scenarios, demonstrating significant engineering practical value and performance improvement effects.

[0045] Furthermore, S2 includes: S21, the query cache is checked to see if there is a mapping relationship between the filename to be accessed and the actual filename. The LRU algorithm is used to manage the cache to ensure that the cache capacity is controllable and the hit rate is high. Specifically, in this invention, determining whether a mapping relationship exists between the filename to be accessed and the actual filename in the query cache, and managing the cache using the LRU (Least Recently Used) algorithm, is one of the key steps in optimizing the performance of case-insensitive conversion. This step introduces a caching mechanism at the SMB protocol layer to store the mapping relationship between case-mismatched filenames used in client requests and the actual filenames stored on the storage side. This avoids performing a full directory traversal and case-insensitive comparison on each access, significantly improving file access efficiency.

[0046] At the technical implementation level, this cache is typically constructed using a hash table or associative array. The key is the filename to be accessed sent by the client (case-sensitive), and the value is the actual filename stored on the server. When a client initiates a file access request, the server first standardizes the filename (e.g., converting it to lowercase or preserving its original form), and then searches the cache. If a match is found, the actual filename is used directly for subsequent operations, eliminating the need for directory traversal. If no match is found, the server continues to call the case-insensitive lookup interface added to the file system, or executes the traditional `readdir` traversal process.

[0047] Furthermore, to ensure controllable cache capacity and maintain a high hit rate, this invention employs the LRU algorithm for cache management. This algorithm maintains an access order linked list, placing the most recently accessed entry at the head of the list. When the cache reaches a preset capacity limit (e.g., 1024 records), the least recently used entry at the tail of the list is automatically removed. The time complexity of the LRU algorithm is O(1) or O(n) (depending on the implementation). In practical deployments, it is typically implemented using a hash table and a doubly linked list to balance query and update efficiency.

[0048] At the parameter level, cache capacity can be dynamically configured based on system load and memory resources. For example, the maximum number of cache entries can be set between 1024 and 8192, and the cache expiration time can be set between 300 and 3600 seconds to adapt to the cache hit rate requirements under different business scenarios. In addition, the newly added interface for obtaining the real filename in the file system should support POSIX standard file path resolution and be compatible with the case-insensitive lookup function of mainstream Linux file systems (such as ext4 and xfs).

[0049] In application scenarios, this step is widely applicable to distributed storage environments where the SMB protocol runs on Linux systems, especially in scenarios where Windows clients frequently access Linux storage nodes. For example, in enterprise-level file sharing services, users may access files via command line or script with non-standard capitalization. In this case, the caching mechanism can effectively reduce the performance loss caused by case mismatch and improve overall I / O throughput.

[0050] The technical effect of this step is that it significantly reduces the number of readdir calls through the cache hit mechanism, thereby reducing the consumption of CPU and I / O resources and improving the response speed of file access and system throughput. The performance improvement is particularly significant when there are a large number of directory files, reducing the average search time from O(n) to O(1), effectively supporting the business needs of high concurrency and large-scale file access.

[0051] S22, the call to the newly added real file name acquisition interface in the file system layer includes converting the file name to be accessed into all lowercase form before searching, so as to improve the interface matching efficiency.

[0052] Specifically, this step involves adding a new interface for retrieving the actual filename at the file system layer. Its technical implementation is based on an optimized case-insensitive matching mechanism. In Linux systems, the file system is case-sensitive by default, while the SMB protocol is typically case-insensitive in Windows clients. Therefore, when the filename sent by the client differs in case from the actual filename on the storage end, the server needs to traverse the directory and perform case-insensitive comparisons to find the actual filename. This process significantly increases system overhead and reduces I / O performance when there are many directory files.

[0053] To address the aforementioned issues, this invention adds a new interface at the file system layer. This interface receives the parent path and the filename to be searched (which may contain case errors) provided by the client and returns the actual filename in the directory that matches the case-insensitive match. The implementation of this interface relies on extensions to the file system kernel module. For example, in ext4 or XFS file systems, efficient matching of directory entries can be achieved by calling the vfs_readdir() or iterate_dir() functions, combined with case-insensitive string comparison algorithms (such as strcasecmp() or utf8_strcasecmp()).

[0054] Regarding specific parameter settings, this interface supports passing two parameters: `const char parent_path` and `const char requested_name`, with the output being `char *real_name`. To improve performance, the interface can internally employ a hash table or LRU caching mechanism to cache the recently queried filename mapping, reducing the overhead of duplicate queries. Furthermore, the interface allows setting a maximum number of cached entries (e.g., 1024) and a cache expiration time (e.g., 300 seconds) to balance memory usage and query efficiency.

[0055] In practical applications, this interface is primarily used by SMB servers to handle scenarios where filenames do not match. For example, when a client accesses a file via command line or script, the filename's case may differ from the storage file's. By calling this interface, the server can quickly obtain the actual filename, avoiding full directory traversal and significantly reducing the number of `readdir` calls and CPU usage.

[0056] From a technical perspective, the introduction of this interface effectively shortens the response time for filename lookup. Especially in high-concurrency, large-directory storage environments, it can reduce the average lookup time from milliseconds to microseconds, significantly improving the compatibility and performance of the SMB protocol and enhancing the overall throughput and stability of the system.

[0057] S3, if the real filename is obtained through the interface, the mapping relationship between the real filename and the filename to be accessed is written into the cache, and the file access operation is continued based on the real filename. Specifically, in this invention, after the server successfully obtains the real filename through the newly added file system interface, the core of this step is to write the mapping relationship between the filename to be accessed sent by the client and the obtained real filename into the cache, and then continue to perform subsequent file access operations based on the real filename. This step builds an efficient caching mechanism between the SMB protocol layer and the file system layer to significantly improve the performance of case-insensitive conversion.

[0058] At the technical implementation level, this step first obtains the real filename corresponding to the client's requested filename through a file system interface (such as get_real_filename(parent_path, requested_name)). This interface is based on a case-insensitive matching strategy, such as using the strcasecmp function under UTF-8 encoding for string comparison, thereby quickly locating the real filename without triggering directory traversal. Once the real filename is obtained, the server constructs a key-value pair, where the key is the filename to be accessed sent by the client (which may be case-insensitive), and the value is the corresponding real filename (case-insensitive), and writes this mapping relationship into the cache. The cache typically uses a hash table structure to support O(1) time complexity lookup operations, and its maximum capacity can be configured to 1024~8192 records, supporting LRU or LFU eviction policies to ensure a balance between cache efficiency and memory usage.

[0059] At the parameter level, this caching mechanism supports dynamic configuration, including cache refresh cycle (e.g., 300 seconds), cache hit rate threshold (e.g., 80%), and maximum number of cache entries. Furthermore, the response time of the file system interface should be controlled within 1-5 milliseconds to ensure low latency throughout the overall access process. Key performance indicators such as interface call frequency, cache hit rate, and directory traversal counts can be collected and analyzed through system logs or performance monitoring modules to evaluate the optimization effect.

[0060] At the application level, this step is widely applicable to distributed storage environments based on Linux systems, especially in scenarios where Samba services interact with Windows clients. When clients access files via command line or applications using non-case-sensitive methods, the server can quickly retrieve the actual filename through caching or APIs, avoiding performance bottlenecks caused by directory traversal, which is particularly advantageous in large-scale file directories.

[0061] The technical advantage of this step lies in significantly reducing directory traversal operations caused by case mismatches through cached mapping relationships, thereby reducing SMB request response time and improving file access efficiency. In actual testing, this mechanism can reduce file open latency by 30% to 60% and effectively reduce the number of readdir system calls, improving system throughput and stability, demonstrating good engineering practicality and innovative value.

[0062] S4, write the real file name determined by traversing the directory into the cache, and complete the subsequent file access operation based on the real file name.

[0063] Specifically, the step of "writing the real filename determined by traversing the directory into the cache and completing subsequent file access operations based on the real filename" is one of the key implementation steps in this invention to improve the performance of case-insensitive conversion. Its technical implementation principle is based on the collaborative optimization of the caching mechanism and the file system interface, aiming to reduce directory traversal operations caused by case mismatch, thereby improving the file access efficiency of the SMB protocol on Linux systems.

[0064] At the technical implementation level, when the filename sent by the client does not match the case of the filename actually existing on the storage side, the server first attempts to open the file. If this fails, it enters a case-insensitive search process. In traditional implementations, this process requires traversing all filenames in the parent directory and performing case-insensitive comparisons one by one until a match is found. In this invention, after the server completes the traversal search and determines the real filename, it establishes a mapping relationship between the real filename and the original filename in the client request, and writes this mapping into a newly added cache. This cache typically uses a hash table structure, with the filename requested by the client as the key and the real filename as the value, supporting fast lookups with O(1) time complexity.

[0065] At the parameter level, cache capacity, time-to-live (TTL), and replacement policy are key factors affecting performance. In some implementations, the cache capacity can be set to 1024~8192 records to accommodate different file access scenarios; TTL is typically set to 300~600 seconds to ensure that cached data is valid within a reasonable time and avoid cache pollution caused by filename changes. In addition, the cache can use LRU or LFU algorithms for eviction management to maintain a balance between cache hit rate and memory usage.

[0066] At the application level, this step is widely applicable to scenarios where the SMB protocol provides file sharing services to Windows clients on Linux systems, especially when there are a large number of files in a directory (e.g., more than 1000 files). Traditional traversal methods will significantly increase the number of readdir calls and CPU overhead. Through the caching mechanism, the server can directly hit the cache in subsequent access requests for the same or similar filenames, avoiding repeated traversal, thereby significantly reducing response latency and improving throughput.

[0067] From a technical perspective, this step effectively reduces I / O overhead and CPU computational load during filename lookup, especially in high-concurrency, large-scale file directory scenarios, reducing file access latency by 30% to 60%, significantly improving overall system performance and client experience. Simultaneously, this caching mechanism complements the newly added interface to the file system, enhancing the system's adaptability to case-insensitive access, and demonstrating good practicality and scalability.

[0068] The method for improving case-insensitive conversion performance in this invention improves file access efficiency by introducing a filename mapping cache and adding a new file system interface on the SMB server side. This avoids a full traversal of the directory when filenames are case-insensitive, and significantly improves file access efficiency, especially in large-scale file scenarios where system overhead is effectively reduced.

[0069] Furthermore, S3 includes: S31, when the case of the actual filename returned by the interface is inconsistent with the case of the filename to be accessed, the mapping relationship between the two is written to the cache in the form of key-value pairs. Specifically, in some implementations, when the actual filename returned by the interface differs from the filename requested by the client in terms of capitalization, the system writes the mapping relationship between the two into a key-value pair in the cache, thereby achieving performance optimization for case-insensitive conversion. This step is technically based on the SMB protocol's adaptation logic on Linux systems, especially when handling case-insensitive filenames sent by Windows clients, reducing repeated directory traversal operations through the caching mechanism.

[0070] From a technical implementation perspective, this cache typically employs a hash table or LRU cache structure to support efficient key-value lookup and update operations. In a key-value pair, the "key" is the filename to be accessed sent by the client (e.g., AAA.txt), while the "value" is the actual filename existing in the storage system (e.g., aaa.txt). If file access fails, the system retrieves the actual filename by calling a newly added file system interface and writes this mapping into the cache for direct lookup during subsequent accesses.

[0071] At the parameter level, cache capacity, time-to-live (TTL), and hash collision handling strategies are key configuration items. For example, the cache capacity can be set to 10,000 records to accommodate file access needs in high-concurrency scenarios; the TTL can be set to 300 seconds (5 minutes) to ensure that cached data remains valid for a reasonable period of time, while avoiding the problem of using the old mapping after filename changes due to long-term caching. In addition, key-value pair writes must follow atomic operations to ensure data consistency in multi-threaded or distributed environments.

[0072] At the application level, this step is widely applicable to interaction scenarios between SMB shared services and Linux file systems in distributed storage systems, especially in hybrid operating system environments where filenames frequently exhibit case inconsistencies when clients access files via command line or scripts. By caching the mapping relationship, the system can significantly reduce the number of readdir calls, lower CPU and I / O overhead, and improve overall access performance.

[0073] In terms of technical effectiveness, this step effectively solves the performance bottleneck caused by directory traversal in the traditional case-insensitive search process. Through the cache hit mechanism, the system can complete the filename mapping query in O(1) time complexity, thereby reducing the file access latency from milliseconds to microseconds. Especially in large-scale file directories, the performance improvement can reach more than 30%, significantly enhancing the system's responsiveness and stability.

[0074] S32, the write operation is executed immediately after the interface call is successful, to ensure that subsequent accesses with the same filename can directly hit the cache.

[0075] Specifically, in this invention, the step of "the write operation is executed immediately after the interface call is successful to ensure that subsequent accesses to the same filename can directly hit the cache" is one of the key steps in optimizing the performance of case-insensitive filename conversion. The technical implementation principle of this step is based on the coordinated operation of the caching mechanism and the file system interface, aiming to reduce directory traversal operations caused by case mismatch, thereby improving the compatibility and access efficiency of the SMB protocol on Linux systems.

[0076] At the technical implementation level, when a client sends a filename request with a case mismatch (e.g., AAA.txt) via the SMB protocol, the server first attempts to open the file using that filename. If this fails, it calls a newly added file system interface (e.g., get_real_filename()), passing in the parent directory path and the filename to be searched, to obtain the actual filename with a case mismatch that exists in the storage system (e.g., aaa.txt). Once this interface call succeeds, the server immediately performs a write operation, writing the mapping between the client-requested filename and the actual filename into the local cache. The cache structure can use a hash table or an LRU caching strategy to support fast lookup and efficient memory management.

[0077] At the parameter level, this cache is typically set to a maximum capacity (e.g., 10,000 records) and employs a TTL (Time To Live) mechanism, such as setting the validity period of cache entries to 300 seconds, to ensure the timeliness and consistency of cached data. Furthermore, calls to the file system interface must comply with the POSIX standard or the Linux kernel VFS interface specification to ensure compatibility and portability.

[0078] At the application level, this step is suitable for scenarios where there are a large number of files in the SMB shared directory and clients frequently access files using case-insensitive filenames, such as file creation, reading, or writing operations when a Windows client accesses a Linux storage cluster. By performing the write operation immediately after a successful API call, it ensures that subsequent access requests with the same filename can directly hit the cache, avoiding repeated readdir operations and significantly reducing I / O latency.

[0079] The technical effect of this step is that by updating the cache in real time, the number of system calls and CPU overhead during the file name lookup process is effectively reduced, which improves the response speed and stability of the SMB server under high concurrency and large-scale file directories, thereby enhancing the overall system performance and user experience.

[0080] S5. When it is detected that the file name has been renamed, update the mapping relationship related to the file name in the cache to ensure that the cached data is consistent with the real file name in the storage system.

[0081] Specifically, when a filename is detected to have been renamed, the mapping relationship associated with that filename in the cache is updated to ensure that the cached data remains consistent with the actual filename in the storage system. This step is one of the core components of the performance optimization mechanism for maintaining case-insensitive conversion in this invention, and its technical implementation is based on the collaborative processing logic between the SMB protocol layer and the file system layer.

[0082] At the technical implementation level, when the file system detects that a filename has been modified (e.g., via a rename system call), the SMB server needs to listen for metadata change events in the file system, for example, through inotify mechanisms or file system hooks for real-time monitoring. Once a filename change is detected, the SMB protocol layer will trigger a cache update process, synchronously updating the mapping relationship between the old and new filenames. Specifically, the cache stores key-value pairs between the client's requested filename (which may not be case-sensitive) and the actual filename stored on the storage side (case-sensitive). The update operation includes deleting the old mapping entry and inserting the new mapping entry to ensure that subsequent requests can match correctly.

[0083] At the parameter level, cache update strategies can be managed based on LRU or LFU algorithms, and cache capacity can be dynamically configured according to system load, for example, set to 1024~8192 records. The filename matching algorithm uses case-insensitive string comparison (such as the strcasecmp function) to ensure consistent processing across different client operating systems (such as Windows). Furthermore, metrics such as file system interface call frequency, cache hit rate, and update latency can all be collected and optimized through the performance monitoring module.

[0084] At the application level, this step is widely applicable to file access scenarios of SMB shared services in distributed storage systems, especially in mixed client environments (such as the coexistence of Windows and Linux clients). When users frequently perform file access or renaming operations with case mismatch, it can significantly reduce the performance loss caused by directory traversal and improve file access efficiency and system response speed.

[0085] The technical effect of this step is that by updating the mapping relationship in the cache in real time, the timeliness and accuracy of the cached data can be ensured, so that the real file name can be quickly located in subsequent file access requests, avoiding repeated execution of time-consuming readdir operations, reducing server-side processing latency, and improving the overall system throughput and concurrency performance. It has significant practical value and innovation.

[0086] To achieve the above embodiments, the present invention also proposes a device for improving case-insensitive conversion performance. Figure 2 This is a schematic diagram of a device for improving case-insensitive conversion performance, provided as an embodiment of the present invention. Figure 2 As shown, the device includes: The file request receiving module 100 is used to receive file access requests sent by the client and obtain the file name to be accessed contained in the request; The filename lookup execution module 200 is used to perform the following lookup operations in sequence based on the filename to be accessed: First, it checks whether there is a mapping relationship between the filename to be accessed and the real filename in the cache. If it exists, the real filename is used to access the file. If it does not exist, the real filename acquisition interface added by the file system layer is called, and the parent path and the filename to be accessed are passed in to obtain the real filename that matches the case. The real filename processing module 300 is used to, if the real filename is obtained through the interface, write the mapping relationship between the real filename and the filename to be accessed into the cache, and continue to perform file access operation based on the real filename; if the real filename is not obtained, it traverses the parent directory of the file, performs a case-insensitive comparison between the filenames in the directory and the filename to be accessed, so as to determine the real filename. The cache update and access execution module 400 is used to write the real file name determined by traversing the directory into the cache, and to complete subsequent file access operations based on the real file name.

[0087] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0088] To implement the above embodiments, the present invention also proposes an electronic device, including: a processor and a memory communicatively connected to the processor; the memory stores computer execution instructions; the processor executes the computer execution instructions stored in the memory to implement the method provided in the foregoing embodiments.

[0089] To implement the above embodiments, the present invention also proposes a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the methods provided in the foregoing embodiments.

[0090] To implement the above embodiments, the present invention also proposes a computer program product, including a computer program that, when executed by a processor, implements the methods provided in the foregoing embodiments.

[0091] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in this invention all comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0092] It should be noted that personal information collected from users should be used for legitimate and reasonable purposes and should not be shared or sold outside of these legitimate uses. Furthermore, such collection / sharing should only be conducted after receiving the user's informed consent, including but not limited to notifying the user to read the user agreement / user notice and sign an agreement / authorization that includes authorization of relevant user information before the user uses the function. In addition, any necessary steps must be taken to protect and safeguard access to such personal information data and ensure that others with access to personal information data comply with their privacy policies and procedures.

[0093] This invention is intended to provide implementation schemes for users to selectively prevent the use or access to personal information data. That is, this disclosure is intended to provide hardware and / or software to prevent or block access to such personal information data. Once personal information data is no longer needed, risks can be minimized by restricting data collection and deleting data. Furthermore, where applicable, such personal information can be de-identified to protect user privacy.

[0094] In the foregoing descriptions of the embodiments, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0095] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this invention, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0096] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing custom logic functions or processes, and the scope of preferred embodiments of the invention includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of the invention pertain.

[0097] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable medium may be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

[0098] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware as in another embodiment, it can be implemented using any of the following techniques known in the art, or a combination thereof: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0099] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0100] Furthermore, the functional units in the various embodiments of the present invention can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0101] The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc. Although embodiments of the present invention have been shown and described above, it is to be understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of the present invention.

[0102] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0103] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for improving the performance of case-insensitive conversion, characterized in that, include: S1 receives a file access request sent by the client and obtains the file name to be accessed contained in the request; S2, based on the filename to be accessed, perform the following lookup operations in sequence: first, check if there is a mapping relationship between the filename to be accessed and the real filename in the cache. If it exists, use the real filename to access the file. If it does not exist, call the real filename acquisition interface added by the file system layer, pass in the parent path and the filename to be accessed, and obtain the real filename that matches the case. S3, if the real file name is obtained through the interface, the mapping relationship between the real file name and the file name to be accessed is written into the cache, and the file access operation is continued based on the real file name; if the real file name is not obtained, the parent directory of the file is traversed, and the file names in the directory are compared with the file name to be accessed in a case-insensitive manner to determine the real file name; S4, write the real file name determined by traversing the directory into the cache, and complete the subsequent file access operation based on the real file name.

2. The method as described in claim 1, characterized in that, The step of receiving a file access request sent by a client and obtaining the filename to be accessed contained in the request also includes: S11, the file access request is an Open request in the SMB protocol, and the file name to be accessed is carried by the client in the request message; S12, the filename to be accessed includes, but is not limited to, the filename part in the file path, and filename parsing containing special characters is supported.

3. The method as described in claim 1, characterized in that, The step of performing the following search operations sequentially based on the filename to be accessed also includes: S21, the query cache is checked to see if there is a mapping relationship between the file name to be accessed and the real file name. The LRU algorithm is used to manage the cache to ensure that the cache capacity is controllable and the hit rate is high. S22, the call to the newly added real file name acquisition interface in the file system layer includes converting the file name to be accessed into all lowercase form before searching, so as to improve the interface matching efficiency.

4. The method as described in claim 1, characterized in that, If the real filename is obtained through the interface, writing the mapping relationship between the real filename and the filename to be accessed into the cache further includes: S31, when the case of the real file name returned by the interface is inconsistent with the case of the file name to be accessed, the mapping relationship between the two is written into the cache in the form of key-value pairs; S32, the write operation is executed immediately after the interface call is successful, to ensure that subsequent accesses with the same filename can directly hit the cache.

5. The method as described in claim 1, characterized in that, Also includes: S5. When it is detected that the file name has been renamed, update the mapping relationship related to the file name in the cache to ensure that the cached data is consistent with the real file name in the storage system.

6. A device for improving case-insensitive conversion performance, characterized in that, include: The file request receiving module is used to receive file access requests sent by clients and obtain the file name to be accessed contained in the request; The filename lookup execution module is used to perform the following lookup operations sequentially based on the filename to be accessed: First, it checks whether there is a mapping relationship between the filename to be accessed and the real filename in the cache. If it exists, the real filename is used to access the file. If it does not exist, the real filename acquisition interface added by the file system layer is called, and the parent path and the filename to be accessed are passed in to obtain the real filename that matches the case. The real filename processing module is used to, if the real filename is obtained through the interface, write the mapping relationship between the real filename and the filename to be accessed into the cache, and continue to perform file access operation based on the real filename; if the real filename is not obtained, it traverses the parent directory of the file, performs a case-insensitive comparison between the filenames in the directory and the filename to be accessed, so as to determine the real filename. The cache update and access execution module is used to write the real file name determined by traversing the directory into the cache, and to complete subsequent file access operations based on the real file name.

7. The apparatus as claimed in claim 6, characterized in that, The file request receiving module is also used for: Receive the Open request in the SMB protocol sent by the client, and extract the file name to be accessed from the request message; The filename to be accessed is parsed, and the filename part of the file path and the filename containing special characters are supported.

8. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1-5.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-5.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1-5.

Images