A state monitoring-based U disk foolproof control method

Abstract

The application discloses a U disk foolproof control method based on state monitoring, which comprises the following steps: continuously collecting state information and recording write context in the write process of a target volume where a target removable storage device is located; generating a key block candidate set according to the write context, assigning a risk priority, and recording a digest value when the key block is written; after the write task is completed, sequentially performing a submission convergence judgment and a device cache emptying process; on this basis, generating a key block back-judgment queue, reading back the key block and performing digest comparison, and judging whether to allow pulling out according to the result; after all the key blocks are verified, further performing a back-jump observation, and if abnormal writing or state back-jump is detected, returning to the corresponding stage to re-judge. The application can improve the accuracy of the U disk safe pull-out judgment and reduce the risk of data damage caused by premature pull-out.

Description

Technical Field

[0001] This application relates to the field of security control technology for removable storage devices, and specifically to a foolproof control method for USB flash drives based on status monitoring. Background Technology

[0002] In existing computer systems, removable storage devices such as USB flash drives are widely used for file copying, backup, and transfer. Users typically rely on the "copy complete" message or progress bar displayed on the operating system interface to determine that data writing is complete, and then directly unplug the device. However, the "file writing complete" message often only indicates that the upper-layer application or part of the system call process has ended; it does not necessarily mean that all data in the target volume, file system metadata, and internal device cache content have been stably written to disk. Especially when page caching exists on the host side, the file system has a delayed write-back mechanism, write caching is enabled on the device side, or background services may still be accessing the target volume, the end-of-file data, directory entries, allocation tables, file records, and log-related content may still be in an incompletely converged state.

[0003] If the user removes the USB drive too early, it can easily lead to problems such as file content truncation, inconsistent metadata, abnormal directory structure, and files that cannot be opened normally. Existing secure removal solutions mostly rely on fixed waiting times, a single idle flag, or a uniform cache refresh strategy, which makes it difficult to take into account different file systems, different device caching capabilities, and the actual disk write status under different writing scenarios; if the waiting time is too short, it is difficult to detect residual write risks in time, while if the waiting time is too long, it will reduce the efficiency of use. Summary of the Invention

[0004] This application provides a USB flash drive error prevention control method based on status monitoring, which at least solves some of the technical problems existing in the related technologies described above.

[0005] According to a first aspect of the embodiments of this application, a USB flash drive error prevention control method based on state monitoring is provided, comprising: continuously collecting state information of the target volume and synchronously recording the write context during the writing process of the target removable storage device; generating a key block candidate set based on the write context, assigning risk priority to each key block, and calculating and recording a digest value when each key block is written; after the write task is completed, executing the submission convergence phase determination and device cache clearing phase processing in causal order based on the state information; after both the submission convergence phase determination and the device cache clearing phase processing are completed, and calculating and recording a digest value based on the key block... The candidate set and the risk priority are used to generate a key block back-judgment queue. Readback operations are performed on each key block according to the risk priority order. A digest value is calculated for the readback content and compared with the recorded digest value. The comparison result is marked as positive confirmation or negative evidence. If negative evidence exists, the target volume does not enter the allowed unplug state. After all key blocks receive positive confirmation, a back-judgment observation phase is entered to monitor whether negative back-judgment evidence appears on the target volume. If no negative back-judgment evidence is detected, the unplug state is entered. If negative back-judgment evidence is detected, the process reverts to the corresponding preceding stage based on the nature of the back-judgment event and re-executes the subsequent stage judgments.

[0006] As an optional solution, the status information includes: application write status information, including whether there are any new write requests on the target volume during the current sampling period, as well as the amount of data and frequency of write requests; file system convergence information, including the changing trend of the number of dirty pages at the volume level, the volume log advancement status when the target volume has a volume log, the update status of directory entries and allocation information, and the count of pending write operations; device write caching capability information, including whether the target removable storage device has enabled write caching, whether it supports synchronous cache refresh commands, and whether it supports write-through mode; and volume access bounce information, including whether a new write handle open event, new metadata update, or new write access from a background process occurs on the target volume after the write task report is completed.

[0007] As an optional approach, the write context records the file operation types involved in this write and the logical block positions corresponding to each file operation. The granularity of the write context is at the logical block level and is dynamically updated during the write process. When a file is appended multiple times, the state at the end of the last write is taken as the standard.

[0008] As an optional approach, generating a candidate set of key blocks based on the write context includes generating the following four types of key blocks based on the actual operation trajectory of this write operation: Tail risk blocks, which record the logical block range corresponding to the last valid write operation of the file and the logical blocks near the final data length endpoint of the file for the file created, appended, or overwritten in this write operation; Metadata association blocks, which record the directory entry blocks, file allocation table related blocks, file record blocks, and log association blocks directly associated with the files and directories involved in the file creation, overwriting, renaming, or deletion operations; Abnormal timing blocks, which monitor the completion delay of write commands during the write process, and when the completion delay deviates significantly from the normal range or the number of write command retries increases within a certain sampling time slice, the logical block interval involved in that time slice is marked as an abnormal timing block; Spatial boundary blocks, which record the logical block intervals near the corresponding boundary positions when the write process crosses cluster allocation boundaries or triggers new cluster chain expansion; and the candidate set of key blocks is formed by merging and deduplicating the above four types of key blocks.

[0009] As an optional approach, risk priorities are assigned to each key block according to the following sorting rules: the risk priority of the metadata-associated block is higher than that of the tail risk block, the risk priority of the tail risk block is higher than that of the abnormal time-series block, and the risk priority of the abnormal time-series block is higher than that of the spatial boundary block. The risk priority is dynamically adjusted according to the stability of the actual convergence process during the submission convergence phase determination. If state fluctuations occur during the submission convergence phase determination, the risk priority of the key block associated with the fluctuation period is increased, and the increased risk priority is used as the sorting basis when generating the key block back-judgment queue.

[0010] As an optional approach, calculating and recording the digest value when each key block is written specifically includes: calculating a digest value for the data content of each key block in the key block candidate set when its first write is completed or its final overwrite is completed; for key blocks of metadata type, calculating or refreshing the digest value for its data content after the last related metadata operation is completed, and associating and recording the digest value with the logical block identifier, block type label, file identifier or metadata object identifier and risk source label of the key block; when a key block is overwritten multiple times, updating and replacing the previously recorded digest value with the digest value after the last valid write is completed.

[0011] As an optional approach, the submission convergence phase determination includes: based on the file system convergence information in the status information, determining whether the following convergence evidence is valid in causal order: the volume-level pending data volume of the target volume continuously decreases and approaches zero over multiple consecutive sampling periods; the file system metadata update batch decreases to zero over several consecutive sampling periods; when the target volume has a volume log, the volume log advance rate is determined to have fallen back to near zero; and the pending write operation count remains zero over consecutive sampling periods. When the target volume has a volume log, the determination is made in the order of decreasing volume-level pending data volume, stopping metadata updates, stopping log advance, and returning pending writes to zero. When the target volume does not have a volume log, the determination is made in the order of decreasing volume-level pending data volume, stopping metadata updates, and returning pending writes to zero.

[0012] As an optional approach, during the device cache clearing phase, differentiated processing is adopted based on the device write cache capability information in the status information: if the target removable storage device supports write-through mode, the final write of the last batch of key metadata is performed in write-through mode; if the target removable storage device does not support write-through mode but supports synchronous cache refresh commands, a cache refresh request is sent to the target removable storage device; if the target removable storage device does not support write-through mode or synchronous cache refresh commands, or if the device write cache capability information is unclear, the scope of subsequent critical block back-judgment queues is expanded.

[0013] As an optional approach, when generating the key block back-judgment queue based on the key block candidate set and the risk priority, the size of the key block back-judgment queue is jointly determined by the risk priority of each key block, the determination during the submission convergence phase, and the actual stability of the device cache clearing phase. The order within the queue is jointly determined by the risk priority and whether any abnormal timing events have occurred during the write process. If the preceding phase converges smoothly and the device cache processing is normal, the size of the key block back-judgment queue is reduced. If there have been state fluctuations or unclear device write cache capability information during the preceding phase, the size of the key block back-judgment queue is expanded. If any abnormal timing events occur during the write process, the priority of the key block associated with them is increased in the key block back-judgment queue.

[0014] According to a second aspect of the embodiments of this application, a USB flash drive error prevention control system based on state monitoring is also provided, comprising: a state acquisition and context recording module, used to continuously acquire the state information of the target volume and synchronously record the write context during the writing process of the target volume where the target removable storage device is located; a key block generation and summary recording module, used to generate a key block candidate set according to the write context, assign risk priority to each key block, and calculate and record a summary value when each key block is written; a convergence determination and cache processing module, used to execute the submission convergence stage determination and device cache clearing stage processing sequentially according to the state information after the write task is completed; and a back-judgment verification module, used for the submission convergence stage determination and the device cache clearing stage processing. After the cache clearing phase is completed, a key block back-judgment queue is generated based on the key block candidate set and the risk priority. Read-back operations are performed on each key block according to the risk priority order. A digest value is calculated for the read-back content and compared with the recorded digest value. The comparison result is marked as positive confirmation or negative evidence. If negative evidence exists, the target volume does not enter the allowed unplug state. The back-judgment observation and phase rollback module is used to enter the back-judgment observation phase after all key blocks have received positive confirmation. It monitors whether negative back-judgment evidence appears on the target volume. If no negative back-judgment evidence is detected, the volume enters the allowed unplug state. If negative back-judgment evidence is detected, the volume rolls back to the corresponding preceding phase according to the nature of the back-judgment event and re-executes the subsequent phase judgments.

[0015] This application continuously collects target volume status information and synchronously records the write context during the writing process. It can identify high-risk locations such as the end of the file, metadata-related areas, abnormal timing areas, and spatial boundary areas by combining the actual write trajectory. After the write operation is completed, it makes a step-by-step determination according to the causal order of commit convergence, device cache clearing, critical block back-checking, and jump observation. It also allows subsequent verification results to correct previous conclusions, thus ensuring that the unpluggable determination is based on the simultaneous satisfaction of volume-level status, device status, and critical data consistency. Therefore, it not only more effectively reduces the risks of file truncation, metadata inconsistency, and directory structure anomalies caused by premature unplugging, but also allows for differentiated processing for different device caching capabilities and different write scenarios, ensuring data reliability while avoiding unnecessary waiting, thus balancing security, accuracy, and efficiency.

[0016] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Furthermore, no embodiment in this disclosure is required to achieve all the effects described above. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0018] Figure 1 A schematic diagram of a USB flash drive error prevention control method based on state monitoring provided in this embodiment of the present disclosure; Figure 2 This is a schematic diagram illustrating the process of generating a candidate set of key blocks according to an embodiment of the present disclosure. Figure 3 This is a schematic diagram of the submission convergence phase determination process provided in an embodiment of the present disclosure; Figure 4 This is a schematic diagram of the back-judgment process and the back-judgment result marking process; Figure 5 A schematic diagram of a USB flash drive error prevention control system based on condition monitoring is provided in an embodiment of this disclosure; Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0019] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0020] According to embodiments of this disclosure, a USB flash drive foolproof control method based on state monitoring is provided. This method can be deployed on the host side and is applicable to removable storage devices connected to the host via a Universal Serial Bus (USB) interface, including USB flash drives, USB portable hard drives, etc. The execution entity of the method can optionally be a volume-level system service, a file system filter driver, a volume filter driver, or a software module that works in both kernel and user modes. The information used originates from the existing state interfaces of the operating system and its storage stack.

[0021] During the writing process, the method continuously collects various status information of the target volume and synchronously records the writing context, generates a candidate set of key blocks and its summary. After the writing task is completed, the target volume goes through multiple judgment stages in causal order according to the collected status information, including the submission convergence stage judgment, the device cache clearing stage processing, the key block back judgment and the back jump observation. Only when the judgment results of all stages meet the conditions and there is no contradiction can the target volume enter the unpluggable state.

[0022] The implementation process of the method described in this application will be described in detail below with reference to specific embodiments. It should be noted that this embodiment is only used to explain this application and is not intended to limit the scope of protection of this application. Conventional adjustments or substitutions of each step by those skilled in the art without departing from the concept of this application should be included in the scope of protection of this application.

[0023] Please see Figure 1 , Figure 1 This is a flowchart of a USB flash drive foolproof control method based on state monitoring according to an embodiment of the present invention, such as... Figure 1 As shown, the method includes steps S1-S5: In step S1, during the writing process of the target volume where the target removable storage device is located, the status information of the target volume is continuously collected and the writing context is recorded synchronously.

[0024] After the target removable storage device is recognized and mounted by the host, the system begins to continuously collect status information of the target volume where the device resides. The collection of status information continues throughout the entire write process, and the collection results are used as inputs in the subsequent commit and convergence phase and the device cache clearing phase.

[0025] In some embodiments, the status information includes four categories. The first category is application write status information, namely, whether there are any new write requests on the target volume during the current sampling period, and the amount of data and frequency of the write requests. The length of the sampling period is configurable, for example, optionally set to an interval on the order of hundreds of milliseconds. At the end of each sampling period, the system counts the number of new write requests and the cumulative amount of data on the target volume, and records the statistical results in a time-series record for use in subsequent stages.

[0026] The second category is file system convergence information, specifically including the trend of changes in the number of dirty pages at the volume level, the progress status of the volume journal, and the update status of directory entries and allocation information, as well as the count of pending write operations. The number of dirty pages at the volume level reflects the amount of data that has not yet been written back to the device from the host page cache; the progress status of the volume journal reflects the progress of file system transaction commits; the update status of directory entries and allocation information is used to determine whether operations at the file system metadata level are still ongoing; and the count of pending write operations is used to characterize the number of write operations that have not yet been completed on the target volume. In actual implementation, the above information can be obtained from the corresponding volume-level or file system-level interface depending on the operating system platform being run; this solution is not limited to a specific operating system-specific interface.

[0027] The third category is device write caching capability information, including whether the target removable storage device has write caching enabled, whether it supports synchronous cache refresh commands (such as the SYNCHRONIZE CACHE command or equivalent commands in the SCSI protocol), and whether it supports write-through mode. This type of information can usually be obtained during the device enumeration phase, and the system saves it and references it during the device cache clearing phase.

[0028] The fourth category is volume access bounce information, which refers to whether new write handle open events, new metadata updates, or new write accesses from background processes have occurred on the target volume after the write task report is completed. Typical sources of such background accesses include the operating system's thumbnail generation service, file content indexing service, real-time protection scanning process, and cloud synchronization clients, which may initiate new accesses to the target volume shortly after the write task's user interface has displayed completion.

[0029] While collecting status information, the system simultaneously records the write context. The write context records the file operation types involved in this write operation and the corresponding logical block positions, with the recording granularity at the logical block level. It does not save a complete copy of the file content, but rather identifies in a structured manner which data locations during this write process may become high-risk objects for subsequent backtesting. Specifically, the content recorded in the write context includes: which files were created, overwritten, appended, or renamed during this task, which directory entries changed, and which logical block intervals during the write process belong to the end-of-file region, cluster allocation boundary region, or metadata association region.

[0030] Meanwhile, the write context is dynamically updated during the write process. When a file undergoes multiple append writes, the state at the end of the last write is used as the reference. That is, the records of previous intermediate states are overwritten by the final state, and the generation of subsequent candidate sets of key blocks is based on the final state record. The logical block-level record granularity ensures the accuracy of subsequent key block location, while the storage and computational overhead of the context record itself is kept within an acceptable range.

[0031] In step S2, a candidate set of key blocks is generated based on the writing context, a risk priority is assigned to each key block, and a summary value is calculated and recorded when each key block is written.

[0032] During the write process, the system synchronously generates a candidate set of critical blocks based on the file operation type and logical block location information recorded in the write context. Each critical block in the candidate set is determined by the actual operation trajectory of this write operation and is used to identify the locations of logical blocks that are more likely to cause data inconsistency or structural damage if the write operation is not stable enough.

[0033] Specifically, please refer to Figure 2 , Figure 2 A schematic diagram illustrating the key block candidate set generation process provided in an embodiment of this disclosure is shown. Figure 2 As shown, in step S201, the tail risk block is generated.

[0034] For each file created, appended, or overwritten, the system extracts the logical block range corresponding to the last valid write operation of that file from the write context, as well as several logical blocks near the final data length endpoint of the file, and marks these logical blocks as tail-risk blocks. The end of the file is considered a high-risk location because when the user immediately unplugs the device after the copy interface reports completion, the last few data blocks at the end of the file are most likely not yet fully flushed from the host page cache or device write cache to the storage medium, resulting in truncation or incomplete tail data. In some embodiments, for a large file that has just completed an append write, the system includes all logical blocks involved in its last write batch, along with several blocks immediately adjacent to its data endpoint, within the tail-risk block range.

[0035] In step S202, metadata association blocks are generated. For files and directories involved in file creation, overwriting, renaming, or deletion operations during this write process, the system records the directory entry blocks, file allocation table related blocks, file record blocks, and log association blocks directly associated with them, marking these logical blocks as metadata association blocks. The risk of such blocks is that if the state between the metadata block and the corresponding data block is out of sync, the consequences are not limited to errors in the content of a single file, but rather structural inconsistencies between the file's existence, size, directory structure, and the actual data. For example, the directory entry may show that the file exists and its size is correct, but the corresponding data block has not actually been stably written. For FAT-based file systems, the relevant metadata association blocks mainly involve the file allocation table and directory entries; for NTFS file systems, the relevant metadata association blocks also involve file records and inodes in the Master File Table (MFT).

[0036] In step S203, abnormal timing blocks are generated. During the write process, the system continuously monitors the completion delay of each write command. When the completion delay significantly deviates from the normal range within a certain sampling time slice, or the number of write command retries increases, the system extracts all logical block intervals involved in that time slice and marks them as abnormal timing blocks. Abnormal completion delays often mean that the device's write stability is lower than normal during the corresponding time period, and data at these locations are prioritized for confirmation in subsequent backtesting. In some embodiments, the normal range is determined by the statistical interval of completion delays of multiple previous sampling time slices during the current write process. When the completion delay of the current sampling time slice exceeds the statistical interval, it is determined to be a significant deviation from the normal range.

[0037] In step S204, spatial boundary blocks are generated. When a write operation crosses a cluster allocation boundary or triggers a new cluster chain extension, the system records the logical block range near the corresponding boundary location and marks it as a spatial boundary block. The risk of boundary locations is that file length information or directory entries may have been updated to reflect the newly allocated storage space, but the actual data in the newly allocated area may not have been stably written yet.

[0038] In step S205, the above four types of key blocks are merged and deduplicated to form a unified set of key block candidates. During merging, if the same logical block simultaneously satisfies multiple tagging conditions—for example, if a logical block is located at the end of a file and also happens to be at a cluster allocation boundary—only one record is retained, but all risk source tags are preserved for subsequent priority allocation reference. When allocating risk priorities, for key blocks that simultaneously have multiple risk source tags, the priority corresponding to the highest risk type is taken.

[0039] In some embodiments, the system assigns risk priorities to each critical block in the candidate critical block set. The initial sorting rule is as follows: metadata-associated blocks have the highest risk priority, followed by tail-risk blocks, then anomalous time-series blocks, and space boundary blocks have the lowest risk priority. This is because different types of blocks have varying degrees of impact on the overall consistency of the file system when they are corrupted. Metadata-associated block corruption may affect directory structure and file accessibility, with a wide impact; tail-risk block corruption usually affects the integrity of a single file; and the risk level of anomalous time-series blocks and space boundary blocks is related to the specific write scenario.

[0040] In some embodiments, the risk priority can be dynamically adjusted based on the stability of the actual convergence process during the subsequent submission convergence phase determination: if fluctuations occur in the volume-level pending data volume or a brief rebound in metadata update batches during the submission convergence phase determination, the risk priority of the critical blocks associated with the period of fluctuation is increased; the increased risk priority serves as the sorting basis when generating the critical block back-judgment queue. This allows data blocks corresponding to periods exhibiting instability during the convergence process to receive a higher verification order during the back-judgment phase.

[0041] In some embodiments, for each key block in the key block candidate set, upon completion of its first write or final overwrite, the system calculates a digest value for the data content of that key block. The digest calculation can optionally employ Cyclic Redundancy Check (CRC), rolling checksum, or other mature low-computational-overhead verification methods. Taking CRC as an example, the system performs byte-by-byte XOR and shift operations on the complete data content of the key block using a fixed polynomial to obtain a fixed-length checksum. This checksum has a high detection capability for any single-bit flip or short burst error in the data content, while its computational complexity is far lower than that of cryptographic hash functions, making it suitable for completion with low additional overhead on the write path. The system associates the calculated digest value with the logical block identifier, block type label, file identifier or metadata object identifier, and risk source label of the key block to form a complete digest record.

[0042] When a critical block is overwritten multiple times during the write process, the digest value after the last valid write operation is completed replaces the previously recorded digest value, ensuring that the digest record always corresponds to the final write state of the critical block. For metadata-type critical blocks, their digest values ​​are refreshed after the last related metadata operation is completed. The digest record serves as the benchmark for readback comparison in the subsequent critical block review phase. During review, the system reads the current content of the critical block from the medium, recalculates the digest, and then compares it with the digest value recorded here.

[0043] In step S3, after the write task is completed, the submission convergence phase determination and device cache clearing phase processing are executed sequentially according to the causal order based on the status information.

[0044] After the write task is completed, the system, based on the continuously collected status information, performs the submission convergence phase judgment in causal order. Traditional solutions often rely solely on a fixed delay or a single idle flag to determine whether a connection can be made, which can easily lead to two opposite biases: insufficient delay may result in premature release, while excessive delay degrades the user experience. This embodiment adopts a method of judging whether multiple convergence evidences are valid in causal order, and only proceeds to the next stage after all evidences are valid.

[0045] Specifically, please refer to Figure 3 , Figure 3 A schematic diagram of the submission convergence phase determination process provided in an embodiment of this disclosure is shown. For example... Figure 3 As shown, in step S301, the first convergence evidence determination is to determine whether the volume-level data to be written of the target volume has been continuously decreasing and approaching zero in multiple consecutive sampling periods.

[0046] At the end of each sampling period, the system reads the amount of data to be written on the target volume and observes its trend across multiple sampling periods. Evidence is only valid if this data amount shows a continuous decrease or remains stable within a low range; if it rebounds within a sampling period, the evidence is considered invalid. "Approaching zero" here means that the amount of data to be written remains below a preset low threshold for several consecutive sampling periods without any sign of rebound. This threshold can be configured based on the target volume capacity and the size of this write task.

[0047] In step S302, the second convergence evidence determination involves determining whether the file system metadata update batches have decreased to zero over several consecutive sampling periods. The system monitors the frequency of metadata operations on the target volume, such as directory entry updates, allocation information changes, and file attribute modifications. This evidence is only valid when the frequency continuously decreases to zero or close to zero. The first piece of evidence is a prerequisite for the second piece of evidence; if the volume-level data to be written is still fluctuating, it is usually accompanied by continuous metadata updates.

[0048] In step S303, a third convergence criterion is determined based on whether the target volume has a volume log. If the target volume has a volume log, the third convergence criterion is determined: the volume log advance rate has fallen back to near zero. For target volumes using a journaling file system, the system monitors the advance of the log write pointer. A decline in the log advance rate indicates that the transaction commit process at the file system level is nearing completion. For target volumes without a volume log, this determination is skipped, and the system directly proceeds to the determination of the pending write operation count.

[0049] In step S304, after the third piece of evidence is established, the fourth piece of convergence evidence is determined, namely, the count of pending write operations remains zero throughout the continuous sampling period. The system maintains a count value reflecting the number of currently incomplete write operations on the target volume, and this piece of evidence can only be considered established when this value is consistently zero.

[0050] The four convergence criteria mentioned above are causally dependent. When the target volume has a volume log, the system determines each criterion in the following causal order: decrease in volume-level pending data → cessation of metadata updates → cessation of log advancement → zeroing of pending writes. When the target volume does not have a volume log, the system determines each criterion in the same causal order: decrease in volume-level pending data → cessation of metadata updates → zeroing of pending writes. If any criterion is still fluctuating, the system remains at the convergence submission stage and does not advance to the device cache clearing stage.

[0051] If a state fluctuation occurs during the submission of the convergence phase judgment, such as a brief increase in the volume-level pending data volume or a temporary increase in the number of metadata update batches, the system will record the period of fluctuation and raise the risk priority of the key blocks associated with that period, so that these key blocks will be given a higher position in the subsequent key block back-judgment queue.

[0052] In some embodiments, after all convergence evidence submitted for the convergence phase determination is valid, the system enters the device cache clearing phase. This phase employs differentiated processing based on the device write cache capability information in the status information, specifically divided into the following three scenarios.

[0053] If the target removable storage device supports write-through mode, the system performs the final write of the last batch of critical metadata in write-through mode, allowing these critical writes to bypass the device-side write cache and reach the storage medium directly. If the target removable storage device supports synchronous cache refresh commands, the system sends a cache refresh request to the target removable storage device after the final write is completed and monitors the completion time of this request.

[0054] In some embodiments, the system compares the completion time of this cache refresh with the average time of all cache refreshes during the current usage period. If the current time is significantly longer, this is used as a reference signal that the device's cache behavior is unstable. If the device's write cache capability information is unclear, for example, if the device does not declare whether write caching is enabled in the capability description, or if the device's response to the cache refresh command does not meet expectations, the scope of subsequent critical block review queue generation will be expanded. For example, spatial boundary blocks that were originally in a lower priority position and some abnormal time-series blocks will also be included in the scope of review.

[0055] The system selects one of the processing paths based on the actual capability information reported by the device. The differentiated strategy avoids the performance cost of forcibly refreshing the cache for all devices, and at the same time, it compensates for the uncertainty on the device side by expanding the scope of the backtest for devices with unclear cache capabilities.

[0056] In some embodiments, after the device cache clearing phase begins, the system enables controlled write freeze on the target volume. Controlled write freeze means suspending new ordinary write requests from entering the target volume and placing newly arriving write requests in a waiting queue; allowing finishing operations already in transit to complete, that is, not interrupting the execution process of write commands that have been sent to the device but have not yet returned completion confirmation; the read-back operations required for subsequent critical block reassessment continue to be executed, that is, block read requests issued during the critical block reassessment phase are not restricted by the freeze policy; and preventing background processes from inserting new writes during the finishing phase, including write operations initiated by background processes such as indexing services, thumbnail services, and synchronization services.

[0057] Controlled write freezes take effect from the device cache clearing phase and continue through the subsequent critical block reversion and jumpback observation phases. They are lifted once the target volume enters an unpluggable state, releasing requests from the waiting queue. For new ordinary write requests arriving during the freeze period, the system first marks them as jump events to be judged; when they are determined to be evidence of a reverse jump, the current freeze state is lifted and the system rolls back to the corresponding preceding phase. Optionally, if a forced write request with higher priority than the freeze policy occurs during the controlled write freeze, the system can lift the current freeze state and roll back to the corresponding preceding phase, while simultaneously updating the critical block candidate set and digest record based on the new write operation.

[0058] In step S4, after the submission convergence phase determination and the device cache clearing phase processing are completed, a key block back-judgment queue is generated according to the key block candidate set and the risk priority. The readback operation is performed on each key block in the order of the risk priority. The digest value of the readback content is calculated and compared with the recorded digest value. The comparison result is marked as positive confirmation or negative evidence. If the negative evidence exists, the target volume does not enter the allowed unplug state.

[0059] Please see Figure 4 , Figure 4 A schematic diagram illustrating the back-judgment process and back-judgment result marking processing flow provided in an embodiment of this disclosure is shown. Figure 4 As shown, in step S401, after the submission of the convergence phase judgment and the device cache clearing phase processing are completed, the system generates a key block back-judgment queue based on the key block candidate set and the risk priority of each key block.

[0060] The size of the critical block back-judgment queue is determined by the risk priority of each critical block and the actual stability of the preceding stage. The order within the queue is determined by the risk priority and abnormal timing events. A lower coverage ratio is used when the preceding stage is stable, and the coverage ratio is increased when there are state fluctuations or unclear information about the device's write cache capability in the preceding stage.

[0061] High-risk priority critical blocks are placed at the front of the queue. If the preceding stages converge smoothly and the device cache processing is normal, it means that no abnormal signals occurred during the entire process from the end of writing to the completion of cache processing on the target volume. The size of the critical block backtesting queue can be reduced accordingly, and only the critical blocks with the highest risk priority need to be included to meet the verification requirements. If there were state fluctuations in the preceding stages (e.g., the volume-level data to be written increased during the convergence process) or the device write cache capability information is unclear, the system cannot confirm whether the processing in these stages has fully met expectations. Therefore, the size of the critical block backtesting queue is expanded to include more critical blocks in the scope of verification to compensate for this uncertainty. If there are abnormal time-series events, the priority of the critical blocks associated with them is increased in the critical block backtesting queue, so that these blocks get a higher verification order under budget constraints.

[0062] For example, if the task involves only a small-scale overwrite of an existing small file, and the entire convergence process is smooth with normal device caching behavior, the critical block backtesting queue may only contain the data block corresponding to the last overwrite, the tail risk block of that file, and the associated metadata block. However, if the task involves operations such as creating directories, creating files in batches, appending large files, or crossing cluster allocation boundaries, or if there were state fluctuations during the convergence phase, the critical block backtesting queue will expand to include the corresponding directory entry block, allocation-related metadata blocks, the block range involved in the abnormal period, and spatial boundary blocks.

[0063] In step S402, readback operations are performed on each key block according to the risk priority order, and a summary value is calculated for the readback content and compared with the recorded summary value.

[0064] The system sets a backtesting budget for readback operations. The backtesting budget represents at least one of the following constraints: the maximum allowed amount of data to be read back, the maximum allowed backtesting execution time, or the maximum number of blocks allowed for backtesting in a single round. The system performs readback operations on each critical block in the critical block backtesting queue sequentially according to risk priority, under the constraints of the backtesting budget. The backtesting budget can be preset based on the size of the critical block candidate set, the target volume capacity, and the allowed backtesting overhead threshold on the host side.

[0065] Specifically, the system sends a read-only retrieval request to the target removable storage device for the logical address of the target critical block, obtaining the current content of that block on the storage medium. Optionally, to avoid reading old data still in the host sidepage cache, the system bypasses the host sidepage cache and reads directly during the readback operation. After obtaining the readback content, the system calculates a digest value for the content using the same digest calculation method as in the write phase, and compares the calculated digest value with the digest value recorded for the critical block in the aforementioned steps.

[0066] For key blocks of data types and key blocks of metadata types, the read-back and comparison process is the same, the only difference being their respective logical locations and block type labels. Throughout the read-back process, the system sets a timeout limit for each read operation. If the read of a key block does not return within the preset time, the judgment result of that block is also marked as reverse evidence, because the read timeout itself reflects that the device's access at that location is abnormal.

[0067] In step S403, the back-judgment results are marked and processed. If the comparison results are consistent, the system marks the back-judgment result of the key block as positive confirmation. If the read-back operation fails, the read-back operation times out (the system sets a timeout limit for each read operation), or the calculated digest value is inconsistent with the recorded digest value, the system marks the back-judgment result of the key block as reverse evidence.

[0068] Even if all evidence from the preceding commit convergence phase and device cache clearing phase is valid, the target volume will not enter the allow-to-remove state if any critical block is found to have reverse evidence during the critical block back-judgment phase. In traditional status monitoring schemes, data verification is often an additional check independent of status determination, and the verification result will not affect the existing status determination conclusion. In this embodiment, if the media content of a critical block is inconsistent with the expected digest value, even if the device status has converged according to indicators such as volume-level dirty pages and log progress, the system still determines that there is a problem with the actual write status of the volume.

[0069] When the backtesting budget is exhausted and there are still critical blocks in the critical block backtesting queue that have not been verified, the target volume continues to remain in the non-allowed pull-out state and starts the next round of backtesting budget to continue the read-back operation for the remaining critical blocks until the verification of the critical blocks that have not been verified is completed.

[0070] In step S5, after all key blocks have received the positive confirmation, the system enters the backtracking observation phase to monitor whether there is evidence of a reverse backtracking on the target volume. If no evidence of a reverse backtracking is detected, the system enters the allowable unplugging state. If evidence of a reverse backtracking is detected, the system reverts to the corresponding preceding phase based on the nature of the backtracking event and re-executes the subsequent phases.

[0071] After all critical blocks in the critical block backtesting queue have received positive confirmation, the system enters the backtracking observation phase. This phase continuously monitors the target volume's status; the monitoring duration is configurable, for example, optionally set to a second-level observation window. This observation window can be preset based on the typical latency of background access after the write task is completed. The backtracking observation phase confirms that, for a period of time after the backtesting is passed, the stable state of the target volume has not been disrupted again by background processes or internal system activities.

[0072] Specifically, during the bounce observation phase, the system monitors evidence of a reverse bounce, including: new write requests on the target volume, new metadata update operations, the volume log being re-progressed, critical blocks that have received positive confirmation being overwritten again, or background processes initiating new write access to the target volume. The system continuously monitors these events, and once any type of reverse bounce evidence is captured within the observation window, it determines that the currently established stable state has been broken.

[0073] As an example, the file content indexing service may delay indexing a new file for several seconds after detecting it. This operation involves writing and updating the index metadata, which results in new metadata modifications on the target volume. Such state changes caused by background processes are typical events that need to be captured during the jumpback observation phase.

[0074] If no reverse bounce evidence is detected during the entire observation window during the bounce observation phase, the target volume enters the unpluggable state. At this time, the system can output a status indication that safe unplugging is allowed to the user, or perform a system-level safe removal operation; if controlled write freeze was previously enabled, the freeze will be lifted and the final unloading of the target volume will be completed in the unpluggable state.

[0075] If evidence of a reverse bounce is detected, the system rolls back to the corresponding preceding stage based on the nature of the bounce event, and re-executes the subsequent stage determinations from that preceding stage. The specific rollback rules are as follows: If a new write request occurs, the system rolls back to the write stage and incrementally updates the key block candidate set. That is, based on the file operation type and logical block location involved in the new write operation, new key block entries are added according to the generation rules of the four types of key blocks in the aforementioned steps. Simultaneously, a digest value is calculated and recorded for the key blocks involved in the new write. Then, the subsequent stage determinations are re-executed from the active write stage. When a new write request occurs during a controlled write freeze, the new write request includes new ordinary write requests that were intercepted and recorded by the controlled write freeze.

[0076] If no new write requests occur, but the volume log is restarted or new metadata is updated, the system rolls back to the submission convergence phase judgment, waits for the four convergence evidences to be established one by one, and then proceeds through the device cache clearing phase and critical block back judgment in sequence.

[0077] If a key block that has already received a positive acknowledgment is overwritten again, the system invalidates the original digest value record of the key block, recalculates and records the digest value of the key block after it is overwritten, and adds the key block back to the key block back-judgment queue. When the key block back-judgment is entered again in a subsequent process, the system will prioritize reading back the key block.

[0078] If multiple types of backtracking events occur simultaneously within the same backtracking observation phase, the system determines the backtracking target phase based on the event type with the largest backtracking magnitude. The priority of backtracking to the write phase is higher than that of backtracking to the submission convergence phase, and the priority of backtracking to the submission convergence phase is higher than that of backtracking to the phase of generating the critical block backtracking queue and performing the readback operation.

[0079] Optionally, the system can set an observation counter for the number of rollbacks. When the number of rollbacks reaches a preset upper limit within a certain period of time, where the preset upper limit is based on the maximum number of rollbacks allowed within the observation window, the system can issue a prompt message to the user, suggesting that the background application that may be causing continuous rollbacks be closed before performing the safe removal operation.

[0080] Using the above method, the system continuously accumulates state evidence and key block summary information during the writing process. After the writing task is completed, it goes through four judgment stages in causal order: submission convergence stage judgment, device cache clearing stage processing, key block back judgment, and backtracking observation. The results of each stage are mutually constrained. The subsequent back judgment results can overturn the stability conclusions established in the previous stage and trigger stage backtracking. This enables the system to avoid premature release or unnecessary waiting when facing scenarios such as short-term write access by background processes, unstable device cache behavior, and unstable file end write to disk.

[0081] Therefore, this method can reduce the probability of local data corruption and structural inconsistencies caused by premature disconnection in actual deployment, while maintaining reasonable control over the user-perceived waiting time.

[0082] Please see Figure 5 , Figure 5 This is a schematic diagram of a USB flash drive error prevention control system based on condition monitoring, provided in an embodiment of this application. Figure 5 As shown, the system includes: a status acquisition and context recording module 501, used to continuously acquire the status information of the target volume and synchronously record the write context during the writing process of the target volume where the target removable storage device is located; a key block generation and summary recording module 502, used to generate a key block candidate set according to the write context, assign risk priority to each key block, and calculate and record the summary value when each key block is written; a convergence determination and cache processing module 503, used to execute the submission convergence phase determination and device cache clearing phase processing in causal order according to the status information after the write task is completed; and a backtesting verification module 504, used to verify the completion of both the submission convergence phase determination and the device cache clearing phase processing. Subsequently, a key block back-judgment queue is generated based on the key block candidate set and the risk priority. Readback operations are performed on each key block according to the risk priority order. A digest value is calculated for the readback content and compared with the recorded digest value. The comparison result is marked as positive confirmation or negative evidence. If negative evidence exists, the target volume does not enter the allowed unplug state. The back-judgment observation and stage rollback module 505 is used to enter the back-judgment observation stage after all key blocks have obtained the positive confirmation, monitoring whether negative back-judgment evidence appears on the target volume. If no negative back-judgment evidence is detected, the unplug state is entered. If negative back-judgment evidence is detected, the process rolls back to the corresponding preceding stage according to the nature of the back-judgment event and re-executes the subsequent stage judgments.

[0083] Those skilled in the art will clearly understand that the technical solutions of the embodiments of this application can be implemented by means of software and / or hardware. In this specification, "unit" and "module" refer to software and / or hardware that can independently complete or cooperate with other components to complete a specific function, wherein the hardware may be, for example, a field-programmable gate array (FPGA), an integrated circuit (IC), etc.

[0084] Each processing unit and / or module in the embodiments of this application can be implemented by an analog circuit that implements the functions described in the embodiments of this application, or by software that executes the functions described in the embodiments of this application.

[0085] Please see Figure 6 It shows a schematic diagram of the structure of an electronic device according to an embodiment of this application, which can be used to implement... Figure 1 The method in the illustrated embodiment. (As shown) Figure 6 As shown, the electronic device may include: at least one processor 601, at least one network interface 604, a user interface 603, a memory 605, and at least one communication bus 602. The communication bus 602 is used to enable connection and communication between the components. The user interface 603 may include buttons, and optionally include a standard wired or wireless interface. The network interface 604 may include, but is not limited to, a Bluetooth module, an NFC module, a Wi-Fi module, etc.

[0086] The processor 601 may include one or more processing cores and connect to various parts within the electronic device through various interfaces and lines. It implements various functions and data processing of the electronic device by running or executing instructions, programs, code sets, or instruction sets stored in the memory 605, and by accessing data in the memory 605. Optionally, the processor 601 may be implemented using at least one hardware form of DSP, FPGA, or PLA. The processor 601 may also integrate one or more combinations of CPU, GPU, and modem.

[0087] Memory 605 may include random access memory (RAM) or read-only memory (ROM). Optionally, memory 605 includes a non-transitory computer-readable medium for storing instructions, programs, code, code sets, or instruction sets. Memory 605 may be divided into a program storage area and a data storage area, wherein the program storage area can be used to store instructions for implementing an operating system and instructions for implementing the foregoing method embodiments; the data storage area can be used to store data related to the relevant method embodiments. Memory 605 may also be at least one storage device located remotely from processor 601. Figure 6As shown, the memory 605, which serves as a computer storage medium, may contain an operating system, a network communication module, a user interface module, and program instructions.

[0088] In particular, the methods and / or embodiments in this application can be implemented as computer software programs. For example, the embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowchart. When the computer program is executed by processor 601, it performs the functions defined in the methods of this application.

[0089] Another embodiment of this application provides a storage medium storing computer program instructions thereon, which can be executed by a processor to implement the methods and / or technical solutions of any one or more embodiments of this application.

[0090] In the above embodiments, the descriptions of each embodiment have different focuses. Parts not described in detail in a certain embodiment can be referred to in the relevant descriptions of other embodiments. The above descriptions are merely preferred embodiments of this application and explanations of the technical principles used. Those skilled in the art should understand that the scope of the invention involved in this application is not limited to the technical solutions formed by specific combinations of the above technical features, but should also cover other technical solutions formed by arbitrary combinations of the above technical features or their equivalent features without departing from the inventive concept.

Claims

1. A USB flash drive error prevention control method based on condition monitoring, characterized in that, include: During the writing process of the target volume where the target removable storage device is located, the status information of the target volume is continuously collected and the writing context is recorded synchronously. A candidate set of key blocks is generated based on the write context, and a risk priority is assigned to each key block. A digest value is calculated and recorded when each key block is written. After the write task is completed, the commit convergence phase determination and device cache clearing phase are executed sequentially according to the state information and causal order. After both the commit convergence phase determination and the device cache clearing phase are completed, a key block back-judgment queue is generated based on the candidate set of key blocks and the risk priority. A readback operation is performed on each key block according to the risk priority order. A digest value is calculated for the readback content and compared with the recorded digest value. The comparison result is marked as positive confirmation or negative evidence. If negative evidence exists, the target volume does not enter the allowed unplug state. After all key blocks receive positive confirmation, a back-judgment observation phase is entered to monitor whether negative back-judgment evidence appears on the target volume. If no negative back-judgment evidence is detected, the unplug state is entered. If negative back-judgment evidence is detected, the process reverts to the corresponding preceding phase based on the nature of the back-judgment event and re-executes the subsequent phase determinations.

2. The method according to claim 1, characterized in that, The status information includes: application write status information, including whether there are any new write requests on the target volume during the current sampling period, as well as the amount of data and frequency of write requests; file system convergence information, including the trend of the number of dirty pages at the volume level, the volume log progress status when the target volume has a volume log, the update status of directory entries and allocation information, and the count of pending write operations; device write caching capability information, including whether the target removable storage device has enabled write caching, whether it supports synchronous cache refresh commands, and whether it supports write-through mode; and volume access bounce information, including whether a new write handle open event, new metadata update, or new write access from a background process occurs on the target volume after the write task report is completed.

3. The method according to claim 1, characterized in that, The write context records the file operation types involved in this write and the logical block positions corresponding to each file operation. The granularity of the write context is at the logical block level and is dynamically updated during the write process. When a file is appended multiple times, the state at the end of the last write is used as the reference.

4. The method according to claim 1, characterized in that, Based on the write context, a candidate set of key blocks is generated, including the following four types of key blocks generated based on the actual operation trajectory of this write: tail risk block, which is used to represent the file that is newly created, appended or overwritten in this write, and records the logical block range corresponding to the last valid write operation of the file and the logical block near the final data length of the file. Metadata association blocks record the directory entry blocks, file allocation table related blocks, file record blocks, and log association blocks directly associated with the files and directories involved in the file creation, overwriting, renaming, or deletion operations. Abnormal timing blocks monitor the completion delay of write commands during the writing process. When the completion delay deviates significantly from the normal range or the number of write command retries increases within a certain sampling time slice, the logical block interval involved in that time slice is marked as an abnormal timing block. Spatial boundary blocks record the logical block intervals near the corresponding boundary positions when the writing process crosses the cluster allocation boundary or triggers the expansion of a new cluster chain. The above four types of key blocks are merged and deduplicated to form the candidate set of key blocks.

5. The method according to claim 4, characterized in that, Risk priorities are assigned to each key block according to the following sorting rules: the risk priority of the metadata-associated block is higher than that of the tail risk block, the risk priority of the tail risk block is higher than that of the abnormal time series block, and the risk priority of the abnormal time series block is higher than that of the spatial boundary block. The risk priority is dynamically adjusted according to the stability of the actual convergence process during the submission convergence phase determination. If state fluctuations occur during the submission convergence phase determination, the risk priority of the key block associated with the fluctuation period is increased, and the increased risk priority is used as the sorting basis when generating the key block back-judgment queue.

6. The method according to claim 1, characterized in that, The digest value is calculated and recorded when each key block is written. Specifically, this includes: calculating a digest value for the data content of each key block in the key block candidate set when its first write is completed or its final overwrite is completed; for key blocks of metadata type, calculating or refreshing the digest value for its data content after the last related metadata operation is completed, and associating the digest value with the logical block identifier, block type label, file identifier or metadata object identifier and risk source label of the key block; when a key block is overwritten multiple times, the digest value after the last valid write is completed is used to update and replace the previously recorded digest value.

7. The method according to claim 1, characterized in that, The convergence phase determination includes: based on the file system convergence information in the status information, determining whether the following convergence evidence is valid in causal order: the volume-level pending data volume of the target volume continuously decreases and approaches zero over multiple consecutive sampling periods; the file system metadata update batch decreases to zero over several consecutive sampling periods; when the target volume has a volume log, the volume log advance rate is determined to have fallen back to near zero; and the pending write operation count remains zero over consecutive sampling periods. When the target volume has a volume log, the determination is made in the order of decreasing volume-level pending data volume, stopping metadata updates, stopping log advance, and returning pending writes to zero. When the target volume does not have a volume log, the determination is made in the order of decreasing volume-level pending data volume, stopping metadata updates, and returning pending writes to zero.

8. The method according to claim 1, characterized in that, During the device cache clearing phase, differentiated processing is adopted based on the device write cache capability information in the status information: if the target removable storage device supports write-through mode, the final write of the last batch of key metadata is performed in write-through mode; if the target removable storage device does not support write-through mode but supports synchronous cache refresh command, a cache refresh request is sent to the target removable storage device; if the target removable storage device does not support write-through mode and does not support synchronous cache refresh command, or if the device write cache capability information is unclear, the scope of the subsequent critical block back-judgment queue is expanded.

9. The method according to claim 1, characterized in that, When generating the key block back-judgment queue based on the key block candidate set and the risk priority, the size of the key block back-judgment queue is jointly determined by the risk priority of each key block and the actual stability of the submission convergence phase and the device cache clearing phase. The order within the queue is jointly determined by the risk priority and whether any abnormal timing events have occurred during the write process. If the preceding phase converges smoothly and the device cache processing is normal, the size of the key block back-judgment queue is reduced. If there have been state fluctuations or unclear device write cache capability information in the preceding phase, the size of the key block back-judgment queue is expanded. If there are abnormal timing events during the write process, the priority of the key block associated with it in the key block back-judgment queue is increased.

10. A USB flash drive error prevention control system based on condition monitoring, characterized in that, include: The status acquisition and context recording module is used to continuously acquire the status information of the target volume and synchronously record the writing context during the writing process of the target volume where the target removable storage device is located. The key block generation and summary recording module is used to generate a key block candidate set according to the writing context, assign risk priority to each key block, and calculate and record the summary value when each key block is written. The convergence determination and cache processing module is used to execute the submission convergence stage determination and device cache clearing stage processing in causal order according to the status information after the writing task is completed. The back-judgment verification module is used to generate a key block back-judgment queue based on the key block candidate set and the risk priority after the submission convergence phase judgment and the device cache clearing phase processing are completed. It then performs readback operations on each key block according to the risk priority order, calculates a digest value for the readback content and compares it with the recorded digest value, marking the comparison result as positive confirmation or negative evidence. If negative evidence exists, the target volume does not enter the allowed unplug state. The back-judgment observation and phase rollback module is used to enter the back-judgment observation phase after all key blocks have obtained the positive confirmation, monitoring whether negative back-judgment evidence appears on the target volume. If no negative back-judgment evidence is detected, the volume enters the allowed unplug state; if negative back-judgment evidence is detected, the volume rolls back to the corresponding preceding phase according to the nature of the back-judgment event and re-executes the subsequent phase judgments.

Images