A networked virtual USB disk creating method and system

Abstract

This application relates to a method and system for creating a networked virtual USB flash drive, belonging to the technical field of data storage. It includes the following steps: mounting the storage space of a remote server to a local file system directory on an intermediate device; creating a virtual disk image file with a predetermined capacity in the local file system directory; mapping the virtual disk image file to a block device on the intermediate device; and emulating the block device as a virtual USB flash drive conforming to the USB storage device specification via a USB device emulation protocol, so that the target host can recognize and access it. This application has the effect of virtualizing remote network storage space into a USB removable storage device that can be directly recognized by the target host.

Description

Technical Field

[0001] This application relates to the technical field of data storage, and in particular to a method and system for creating a networked virtual USB drive. Background Technology

[0002] Currently, physical USB flash drives and portable hard drives are commonly used methods for carrying data, but they require carrying physical devices with you, which poses a risk of loss or damage, and their storage capacity is fixed and cannot be flexibly expanded.

[0003] While cloud storage services solve the portability problem of physical media, allowing users to access data anytime, anywhere, access typically relies on specific clients or web pages and cannot be directly recognized as local storage devices by the operating system. Especially for applications that depend on detecting "removable storage devices" (such as automatic photo import and in-car multimedia playback), cloud storage suffers from poor compatibility and inconvenience.

[0004] Existing technologies that mount remote storage as local directories through network file systems (such as SSHFS and WebDAV) enable remote access, but they are presented as network drives or ordinary folders rather than "removable storage devices" recognized by the system, and thus cannot meet the device type recognition requirements of specific application scenarios. Summary of the Invention

[0005] In order to virtualize remote network storage space into a USB removable storage device that can be directly recognized by the target host, this application provides a method and system for creating a networked virtual USB flash drive.

[0006] On the one hand, the networked virtual USB flash drive creation method provided in this application adopts the following technical solution: A method for creating a networked virtual USB drive includes the following steps: Mount the remote server's storage space to the local file system directory on the intermediate device; Create a virtual disk image file in the local file system directory; Map the virtual disk image file to a local block device on the intermediate device; The block device is simulated as a virtual USB flash drive that conforms to the USB storage device specification.

[0007] By adopting the above technical solution, combining remote network storage space with local USB device emulation technology, a complete conversion link from remote storage to local block device and then to USB virtual device is constructed. This realizes the function of virtualizing flexible remote storage space into a standard USB removable storage device, allowing the target host to access remote storage data like a regular USB flash drive without any special driver. This solves the contradiction between the poor portability and fixed capacity of traditional physical USB flash drives and the non-local access of cloud storage.

[0008] Preferably, mounting the remote server's storage space to the local file system directory on the intermediate device specifically includes: The intermediate device reads the pre-stored remote server configuration file, calls the corresponding network file system mounting tool according to the protocol type in the configuration file, establishes a persistent connection with the remote server and performs authentication, and mounts the remote storage space to the specified directory.

[0009] By adopting the above technical solution, an automated and configurable connection between the intermediate device and the remote server is realized, supporting multiple network file system protocols. It can automatically select the mounting tool and complete the authentication based on the pre-stored configuration, improving the system's compatibility and ease of use, ensuring the stability and security of the remote storage mounting process, and providing a reliable data channel for subsequent virtual disk operations.

[0010] Preferably, the virtual disk image file is mapped to a local block device on the intermediate device, and the predetermined capacity is consistent with the capacity of the virtual USB drive presented to the target host.

[0011] By adopting the above technical solution, the capacity characteristics of virtual disk image files are clarified, and the file size in the remote storage space is directly mapped to the USB flash drive capacity recognized by the target host. This allows users to flexibly customize the size of the virtual USB flash drive within the remote storage quota according to their actual needs, breaking through the limitation of fixed physical USB flash drive capacity and realizing the elastic allocation of storage resources.

[0012] Preferably, mapping the virtual disk image file to a local block device on the intermediate device specifically includes: By using the operating system's loop device mechanism, the virtual disk image file is associated with an idle loop device, so that read and write operations on the loop device are automatically converted by the kernel into accesses to the virtual disk image file.

[0013] By adopting the above technical solution and utilizing the loop device mechanism built into the operating system, ordinary disk image files can be virtualized into block devices in a lightweight and efficient manner without the need for additional hardware support, thus simplifying the system architecture. At the same time, the kernel-level conversion mechanism ensures the performance and stability of data read and write, and provides a standard block device interface for subsequent USB device emulation.

[0014] Preferably, mapping the virtual disk image file to a local block device on the intermediate device specifically includes: The intermediate device, acting as an NBD client, connects to a remote server acting as an NBD server via the Network Block Device Protocol (NBD), and maps the virtual disk image file exported by the remote server to a local block device.

[0015] By adopting the above technical solution, an alternative block device mapping method is provided, which directly accesses the virtual disk image file on the remote server through the network block device protocol, bypassing the local file system layer, reducing protocol conversion overhead, and is suitable for scenarios that require higher performance or where the virtual disk image file itself is located remotely, thereby enhancing the deployment flexibility and adaptability of the solution.

[0016] Preferably, the step of simulating the block device as a virtual USB drive specifically includes: Configure the USB gadget function of the intermediate device and declare the intermediate device as a USB mass storage device; Run the USB connection monitoring program to monitor the USB connection status in real time; when the target host is detected to be connected via USB, dynamically bind the local block device to the created mass_storage function instance to complete the presentation of the virtual USB drive.

[0017] By adopting the above technical solution, a dynamic on-demand binding mechanism for USB devices is realized. The daemon process monitors the USB connection status in real time and binds the backend block device to the USB function instance only when the target host is connected. This ensures that the device can respond and be recognized quickly when connected, while avoiding long-term occupation of system resources.

[0018] On the other hand, the networked virtual USB flash drive creation system provided in this application adopts the following technical solution: A networked virtual USB flash drive creation system, comprising: A remote server is used to provide physical storage space and store virtual disk image files with a predetermined capacity; Intermediate devices are communicatively connected to both the remote server and the target host. The intermediate device includes: The network mount module is used to establish a connection with a remote server and mount its storage space as a local directory; The virtual disk management module is used to manage virtual disk image files in the local directory and map the file to a local block device; The USB device emulation module is used to emulate the local block device as a USB mass storage device and dynamically bind the backend block device when a USB connection event is detected.

[0019] By adopting the above technical solution, the remote server, intermediate device and target host are organically integrated, and the functional division of each component is clearly defined. The modular design of the intermediate device enables network mounting, virtual disk management and USB emulation to perform their respective functions. The system structure is clear, easy to implement and maintain, and provides complete technical support for realizing networked virtual USB drives.

[0020] Preferably, the intermediate device further includes a control module for coordinating the operation of the network mounting module, the virtual disk management module, and the USB device emulation module, and for managing configuration files and event responses.

[0021] By adopting the above technical solution, a control module is added to the intermediate equipment as the core scheduling unit to coordinate the operation status of each functional module, manage system configuration and event response mechanism, improve the system integration and automation level, ensure that each module works collaboratively and cooperates in an orderly manner, and enhance the system stability and manageability.

[0022] Preferably, the intermediate device is a hardware platform with computing power, a network interface, and a USB device interface, including a main control chip, a network communication module, a USB control module, and a non-volatile storage module. The non-volatile storage module is used to store the operating system and configuration files, and the USB control module is used to implement USB device emulation functions.

[0023] By adopting the above technical solution, the hardware composition of the intermediate device is specifically defined, and the core hardware modules such as the main control chip, network communication, USB control and storage are clarified, enabling the intermediate device to operate independently. The non-volatile storage module ensures the persistent storage of the operating system and configuration files, and the USB control module is specifically used to realize device simulation. The hardware architecture is clear and feasible, providing a foundation for the physical implementation of the solution.

[0024] Preferably, the target host is a computing device with a standard USB host interface. The operating system of the target host automatically recognizes the intermediate device as a standard USB mass storage device and assigns a device node or drive letter.

[0025] By adopting the above technical solution, the plug-and-play feature of the target host is emphasized. Since the intermediate device strictly follows the USB mass storage device specification, any operating system with a standard USB host interface can automatically recognize and load the universal driver without the need to install additional special software, which greatly improves the convenience of use for users and the universality of the solution.

[0026] In summary, this application includes at least one of the following beneficial technical effects: 1. By simulating a virtual USB flash drive that conforms to the USB storage device specification after the remote storage space is transformed through multiple layers of virtualization, the target host can automatically recognize and access it without installing any special drivers. It is compatible with all operating systems and applications that support standard USB storage devices, solving the problem of difficult local access to cloud storage. 2. By creating a virtual disk image file with a predetermined capacity in the remote storage space and directly mapping the size of the file to the capacity of the virtual USB flash drive, users can flexibly adjust the size of the USB flash drive within the remote storage quota according to their actual needs, breaking through the limitation of the fixed capacity of traditional physical USB flash drives. 3. The data is actually stored on a remote server rather than on an intermediate device, so users can access the data anytime and anywhere without carrying physical media, avoiding the risk of losing or damaging the physical USB drive; at the same time, it is convenient for administrators to centrally manage permissions and back up data for multiple virtual USB drives. Attached Figure Description

[0027] Figure 1 This is a flowchart illustrating Embodiment 1 of this application; Figure 2 This is a schematic diagram of Embodiment 2 of this application; Figure 3 This is a schematic diagram of the main control chip in Embodiment 2 of this application. Detailed Implementation

[0028] The following combination Figures 1-3 This application will be described in further detail.

[0029] Example 1 Embodiment 1 of this application discloses a method for creating a networked virtual USB drive.

[0030] Reference Figure 1 A method for creating a networked virtual USB drive includes the following steps: S1: On the intermediate device, mount the storage space of the remote cloud drive to the local file system directory of the intermediate device.

[0031] S2: After mounting the remote file system, create a virtual disk image file.

[0032] S3: The intermediate device maps the virtual disk image file to a local block device.

[0033] S4: On the intermediate device, the local block device is simulated as a standard USB mass storage device through USB device emulation software; S5: When the user connects the intermediate device signal to the target host, the target host will automatically recognize the device; S6: When a user performs read and write operations on a virtual USB drive on the target host, the actual data storage occurs on the remote server.

[0034] Specifically, in step S1, on the intermediate device, the storage space of the remote cloud drive is mounted to the local file system directory of the intermediate device, including the following: After the intermediate device starts up, it first initializes the network connection. The intermediate device's network communication hardware connects to a pre-configured network based on the locally stored network configuration parameters. This pre-configured network can be a wired or wireless network. Once the connection is successful, the intermediate device reads the remote server configuration file stored in the same storage device. This configuration file contains information such as the remote server's network address, access protocol type, authentication method, and credentials. The remote server can be a storage server provided by a cloud storage service provider, a privately deployed NAS network-attached storage device, or a regular file server.

[0035] Based on the protocol type specified in the configuration file, the intermediate device invokes the corresponding network file system mounting tool. If using the SSHFS protocol, the device executes the `sshfs` command, carrying user authentication information, to mount the storage space allocated to that user on the remote server to the specified directory on the local file system, such as ` / mnt / remote_disk`. If using the WebDAV protocol, the device invokes tools such as `davfs2` to complete the mounting. During the mounting process, the device establishes a persistent network connection with the remote server and performs authentication to ensure that only authorized users can access the remote storage space.

[0036] After successful mounting, the remote server's storage space appears as a directory on the intermediate device. The intermediate device can read and write files within this directory, and all operations are synchronized to the remote server in real time via network protocols. This step establishes a data channel between the intermediate device and the remote storage, laying the foundation for the subsequent creation and access of virtual disk files.

[0037] Step S2, after mounting the remote file system, creates a virtual disk image file, including the following: The virtual disk image file has a predetermined fixed size, and the capacity of the virtual disk image file is the final capacity of the USB flash drive presented to the target host. Users can freely define this size within the range allowed by the remote storage space according to their own needs, such as setting it to 32GB, 64GB or 128GB.

[0038] Virtual disk image files can be in various formats, including but not limited to .img, .vhd, and .vmdk. Virtual disk image files can be created in two ways: First, an administrator or system automation tool can use a disk image creation tool on a remote server to generate a blank image file of a specified size. Second, after an intermediate device mounts a remote directory to its local machine via a protocol, it can directly use the dd or qemu-img commands mentioned above to create a virtual disk image file within that mounted directory.

[0039] Step S3, the intermediate device maps the virtual disk image file to a local block device, including the following: Intermediate devices utilize the block device virtualization mechanism provided by the operating system to achieve this mapping. Depending on the implementation environment, different block device virtualization tools can be selected to complete this mapping, such as loop devices or network block devices (NBDs).

[0040] Loop devices are a common type of pseudo-device in Linux systems, allowing a regular file to be simulated as a block device. The intermediate device first obtains a free loop device from the system; each loop device corresponds to a device node. Then, the virtual disk image file prepared in step S2 is associated with this loop device. After the association is established, all read and write operations on this loop device will be automatically translated by the operating system kernel into data access to the corresponding location in the virtual disk image file. This method is simple to implement, requires no additional network configuration, and is suitable for scenarios where the virtual disk image file has already been mounted locally via a remote file system protocol.

[0041] In some cases, if a virtual disk image file needs to be remotely accessed via a dedicated block device protocol, or if it's desirable to bypass the file system layer and access remote storage directly as a block device, Network Block Devices (NBD) can be used. NBD exposes block devices or files on the remote server to the client via a TCP / IP network, and the client maps them to local block devices. In this approach, the intermediate device acts as the NBD client, and the remote server acts as the NBD server. The server exports a pre-prepared virtual disk image file as a block device, and the intermediate device obtains the corresponding local block device upon connection. This method reduces the overhead of file system protocols but requires additional configuration of the NBD server and client.

[0042] Regardless of the method used, once the mapping is successful, the intermediate device will acquire a local block device node. The size of this block device is exactly the same as the virtual disk image file, and subsequent USB emulation processes can directly use it as backend storage. All read and write operations on this block device will ultimately be applied to the virtual disk image file on the remote server through the corresponding mapping mechanism. After mapping is complete, the block device is in a ready state, waiting to be used for device emulation after a USB connection event is triggered. This step is typically performed immediately after the intermediate device starts up and completes the remote file system mounting to ensure that the block device is ready when the target host connects, thus achieving a fast response.

[0043] Step S4 involves emulating a standard USB mass storage device on the intermediate device using USB device emulation software, including the following: The intermediate device's operating system has USB gadget functionality, allowing the device to function as a USB peripheral when hardware support is available. The intermediate device first configures the USB gadget, declaring itself as a USB mass storage device and setting the appropriate device descriptor to conform to the USB Mass Storage Class specification. After completing the basic configuration, the intermediate device creates a `mass_storage` functional instance, which simulates a mass storage device. At this point, the functional instance is not yet associated with the actual backend storage and is in a standby state. Simultaneously, the intermediate device's operating system runs a daemon process that continuously monitors the USB hardware connection status. This daemon process remains resident in the background after system startup, waiting for the target host to connect.

[0044] When the target host connects to the intermediate device via USB cable, the USB controller detects the connection and triggers an event. Upon capturing this event, the daemon immediately performs an activation operation, binding the local block device prepared in step S3 as backend storage to the `mass_storage` function instance. After binding, the intermediate device's USB gadget function has an actual data storage backend. The target host identifies the device during enumeration, loads the standard USB storage driver, and assigns a drive letter or device node to the device. Users can then perform read and write operations on the device just like using a regular USB flash drive.

[0045] Through the above steps, the intermediate device enables the virtual disk image file on remote storage to be ultimately presented as a standard USB removable storage device on the target host.

[0046] Step S5: When the user connects the intermediate device signal to the target host, the target host will automatically recognize the device, including the following: Since the intermediate device has been configured as a standard USB mass storage device in step S4, the target host's operating system will treat it as a regular USB flash drive. The operating system automatically loads the built-in USB storage driver and assigns an accessible drive letter or device node to the device. For example, in Windows, it will appear as a new removable disk drive letter, and in Linux, it will appear as a device node such as / dev / sdb. After allocation, the user can perform file operations on the device just like a regular USB flash drive, including opening, copying, pasting, creating, deleting, and renaming. All read and write operations on the device are completely transparent to the user, and the operation is exactly the same as with a regular physical USB flash drive.

[0047] After completing the operation, the user should follow the operating system's specifications to perform a safe eject or unmount operation to ensure data integrity and prevent data loss. After ejection, the target host releases device resources, and the intermediate device returns to a ready-to-connect state, awaiting the next use.

[0048] In step S6, when a user performs read and write operations on the virtual USB drive on the target host, the actual data storage occurs on the remote server, including the following: When a user copies, saves, or modifies files on the virtual USB drive, these operation requests are sent from the target host to the intermediate device via the USB bus. Upon receiving the request, the intermediate device translates it into an access to the local block device. Since this block device has already been associated with the virtual disk image file in the remote mount directory in step S3, read / write operations on the block device are further translated into accesses to the virtual disk image file. Finally, this data is transmitted in real-time and written to the virtual disk image file on the remote server via the network file system protocol between the intermediate device and the remote server.

[0049] When a user reads a file from a virtual USB drive, the process is reversed. The intermediate device reads data from a virtual disk image file on a remote server, returns it to the target host via the USB bus, and the user can then view the file content.

[0050] The implementation principle of the networked virtual USB flash drive creation method in Embodiment 1 of this application is as follows: By establishing a multi-layer virtualization conversion mechanism on an intermediate device, the storage space on the remote server is ultimately presented as a standard USB removable storage device recognizable by the target host. First, the remote storage space is mounted to the local intermediate device through the network file system protocol, realizing localized access to the remote storage; then, a virtual disk image file with a predetermined capacity is created in the mount directory; next, the image file is mapped to a local block device through the block device virtualization mechanism of the operating system, completing the conversion from file to device; finally, the block device is simulated as a virtual USB flash drive conforming to the USB storage device specification using USB device emulation technology. When the target host connects via USB, it can perform read and write operations on the remote storage space just like using a regular physical USB flash drive. The entire process achieves the goal of remote storage being recognized and used by the host in the form of a standard removable storage device.

[0051] Example 2 Embodiment 2 of this application discloses a networked virtual USB flash drive creation system.

[0052] Reference Figure 2 A networked virtual USB flash drive creation system includes an intermediate device, a remote server, and a target host. The intermediate device is communicatively connected to both the remote server and the target host. The intermediate device is connected to the remote server via a network and to the target host via a USB interface. The remote server provides the final physical storage space, the target host recognizes and uses the virtual USB flash drive, and the intermediate device virtualizes the remote server's storage space into a USB removable storage device recognizable by the target host.

[0053] An intermediate device is a hardware platform with computing capabilities, a network interface, and a USB device interface. It includes a main control chip, a network communication module, memory, a non-volatile small-capacity storage module, a USB control module, and a power management module. The main control chip executes software programs and processes data streams. The network communication module establishes a connection with a remote server. The memory runs the operating system and applications and serves as a temporary cache for data read / write operations. The non-volatile small-capacity storage module stores the operating system and configuration files. The USB control module enables USB device emulation, allowing the intermediate device to declare itself as a USB mass storage device to the target host. The power management module supplies power to all components.

[0054] refer to Figure 3The intermediate devices also include a network mounting module, a virtual disk management module, a USB device emulation module, and a control module running on the main control chip. The network mounting module establishes and maintains connections with remote servers, mounting remote storage space as local directories. The virtual disk management module manages virtual disk image files in the remote mounted directory and maps these files to local block devices. The USB device emulation module simulates the local block device as a USB mass storage device and dynamically binds it to the backend block device when a USB connection event is detected. The control module coordinates the work of each module and manages configuration files and event responses.

[0055] The remote server provides the final physical storage space. A virtual disk image file of a predetermined fixed size is pre-stored on the remote server; the size of this file determines the final virtual USB drive capacity presented to the target host. The remote server communicates with the intermediate device via the Network File System protocol, allowing the intermediate device to access this virtual disk image file.

[0056] The target host is a computing device with a standard USB host interface. No dedicated driver needs to be installed on the target host. When connected to the intermediate device via USB, the target host automatically recognizes the intermediate device as a standard USB mass storage device and assigns a device node and drive letter, enabling read and write access to the virtual USB drive.

[0057] The above are all preferred embodiments of this application, and are not intended to limit the scope of protection of this application. Therefore, all equivalent changes made in accordance with the structure, shape and principle of this application should be covered within the scope of protection of this application.

Claims

1. A networked virtual USB drive creation method, characterized by: Includes the following steps: Mount the remote server's storage space to the local file system directory on the intermediate device; Create a virtual disk image file in the local file system directory; The virtual disk image file is a disk image file with a predetermined capacity, which is consistent with the capacity of the virtual USB drive presented to the target host. Map the virtual disk image file to a local block device on the intermediate device; By using the operating system's loop device mechanism, the virtual disk image file is associated with an idle loop device, so that read and write operations on the loop device are automatically converted by the kernel into accesses to the virtual disk image file. The block device is simulated as a virtual USB flash drive that conforms to the USB storage device specification.

2. The method for creating a networked virtual USB drive according to claim 1, characterized in that: The step of mounting the remote server's storage space to the local file system directory on the intermediate device specifically includes: The intermediate device reads the pre-stored remote server configuration file, calls the corresponding network file system mounting tool according to the protocol type in the configuration file, establishes a persistent connection with the remote server and performs authentication, and mounts the remote storage space to the specified directory.

3. The method for creating a networked virtual USB drive according to claim 1, characterized in that: The virtual disk image file is a disk image file with a predetermined capacity, which is consistent with the capacity of the virtual USB drive presented to the target host.

4. The method for creating a networked virtual USB drive according to claim 1, characterized in that: Mapping the virtual disk image file to a local block device on the intermediate device specifically includes: By using the operating system's loop device mechanism, the virtual disk image file is associated with an idle loop device, so that read and write operations on the loop device are automatically converted by the kernel into accesses to the virtual disk image file.

5. The method for creating a networked virtual USB drive according to claim 1, characterized in that: Mapping the virtual disk image file to a local block device on the intermediate device specifically includes: The intermediate device, acting as an NBD client, connects to a remote server acting as an NBD server via the Network Block Device Protocol (NBD), and maps the virtual disk image file exported by the remote server to a local block device.

6. The method for creating a networked virtual USB drive according to claim 1, characterized in that: Mapping the virtual disk image file to a local block device on the intermediate device specifically includes: Configure the USB gadget function of the intermediate device and declare the intermediate device as a USB mass storage device; Run the USB connection monitoring program to monitor the USB connection status in real time; when the target host is detected to be connected via USB, dynamically bind the local block device to the created mass_storage function instance to complete the presentation of the virtual USB drive.

7. A networked virtual USB flash drive creation system, based on the method described in any one of claims 1-6, characterized in that: include: A remote server is used to provide physical storage space and store virtual disk image files with a predetermined capacity; Intermediate devices are communicatively connected to both the remote server and the target host. The intermediate device includes: The network mount module is used to establish a connection with a remote server and mount its storage space as a local directory; The virtual disk management module is used to manage virtual disk image files in the local directory and map the file to a local block device; The USB device emulation module is used to emulate the local block device as a USB mass storage device and dynamically bind the backend block device when a USB connection event is detected.

8. A networked virtual USB flash drive creation system according to claim 7, characterized in that: The intermediate device also includes a control module for coordinating the operation of the network mounting module, the virtual disk management module, and the USB device emulation module, and for managing configuration files and event responses.

9. A networked virtual USB flash drive creation system according to claim 7, characterized in that: The intermediate device is a hardware platform with computing power, network interface and USB device interface, including a main control chip, network communication module, USB control module and non-volatile storage module; The non-volatile storage module is used to store the operating system and configuration files, and the USB control module is used to implement USB device emulation functions.

10. A networked virtual USB flash drive creation system according to claim 7, characterized in that: The target host is a computing device with a standard USB host interface. The operating system of the target host automatically recognizes the intermediate device as a standard USB mass storage device and assigns a device node or drive letter.

Images