System starting method and related equipment

Abstract

The embodiment of the invention discloses a system starting method, and the method comprises the steps: generating and storing a first snapshot after a first program of equipment is powered on and started and before a file system is mounted, so as to enable the state of the first program of the equipment to be restored based on the first snapshot after the equipment is powered on again, the first snapshot comprises state information of the first program after the first program is powered on and started and before the file system is mounted. It can be considered that the state information of the first program which is powered on and started before the file system is mounted is not affected by the file system, that is, the state information recorded in the first snapshot is not affected by the file system. Therefore, after the first snapshot is generated and stored, the device can continue to be used as required, and operations such as system restart do not need to be carried out immediately. And when the equipment is powered on again as required, quick start can be realized through the generated first snapshot, so that the start time of the equipment is shortened, and the start speed of the equipment is increased.

Description

Technical Field

[0001] This application relates to the field of equipment management technology, specifically to a system startup method and related equipment. Background Technology

[0002] In actual device use, the startup time of terminal devices and other equipment can reflect the performance of the device and affect the user experience.

[0003] In an exemplary conventional approach, the device startup process may include the following steps executed in sequence: device power-on, firmware phase such as the basic input / output system (BIOS), kernel initialization, decompression of the initial root file system (Linux initial RAM disk, initrd), startup of the centralized system and configuration management program systemd, mounting the file system, hardware initialization, service initialization, service startup, and service readiness.

[0004] It is evident that the series of steps the device needs to perform during each startup process takes a long time, resulting in a long startup time, low device processing efficiency, and negatively impacting the user experience.

[0005] Currently, one way to shorten the boot time of terminal devices and other equipment is to use suspend-to-disk (STD) to achieve fast device startup. However, after generating a snapshot using STD, the device must be powered down and then powered on again immediately, which limits its application scenarios and affects the normal use of the device. Summary of the Invention

[0006] This application provides a system startup method that allows a device to continue operation as needed after generating a snapshot for fast startup, and to achieve fast startup by powering back on and using the generated snapshot. This application also provides corresponding apparatus, devices, computer-readable storage media, and computer program products.

[0007] The first aspect of this application provides a system startup method, which includes: generating and saving a first snapshot after the first program of the device is powered on and started but before the file system is mounted, so that the state of the first program of the device can be restored based on the first snapshot after the device is powered on again, the first snapshot including the state information of the first program after the first program is powered on and started but before the file system is mounted.

[0008] In the first aspect, a first snapshot can be generated after the first program is powered on and before the file system is mounted. The first snapshot includes, but is not limited to, the state information of the first program after it is powered on and before the file system is mounted. It can be assumed that the state information of the first program powered on before the file system is mounted is not affected by the file system; that is, the first program does not depend on the file system, and the state information recorded in the first snapshot is also not affected by the file system.

[0009] Therefore, after the first snapshot is generated, even if the device is still in use and the file system metadata changes with the device's usage status, the state information of the first program during startup recorded in the first snapshot will not be affected. In other words, it will not cause a data inconsistency between the file system metadata and the data recorded in the first snapshot.

[0010] As can be seen, compared to the traditional STD approach where the device needs to be powered down immediately after a snapshot is generated, in the first aspect, after generating and saving the first snapshot, the device can continue to be used as needed without immediately performing system restarts. In other words, in the first aspect, there is no restriction on when the device can be powered back on after saving the first snapshot.

[0011] After the first snapshot is generated, when the device is powered on again as needed, the device state can be quickly restored using the generated first snapshot, thereby achieving fast startup, shortening the device startup time, and speeding up the device startup process.

[0012] In one possible implementation of the first aspect, generating and saving the first snapshot may include generating the first snapshot and saving the first snapshot to persistent storage.

[0013] In this possible implementation, persistent storage can enable persistent storage of data. For example, in a Linux system, the first snapshot can be saved as a file to a regular file on the disk.

[0014] In this way, the first snapshot stored in persistent storage will not be lost even when the device is powered off. Furthermore, compared to the traditional STD technology where snapshots are one-time snapshots, this possible implementation saves the first snapshot to persistent storage. Therefore, after the first snapshot is used for system restoration, it can still be retained for subsequent reuse, thereby improving the availability of the first snapshot.

[0015] In one possible implementation of the first aspect, the first snapshot also includes the state information of the second program after the device is powered on and before the file system is mounted, so that the state of the first program and the state of the second program of the device can be restored based on the first snapshot after the device is powered on again.

[0016] In this possible implementation, multiple programs (including a first program and a second program) that do not depend on a file system can be powered on and started before the file system is mounted. After all the programs have been powered on and started, but before the file system is mounted, a first snapshot can be generated. This first snapshot can include the state information of the multiple programs. In this way, after the device is powered on again, it can efficiently restore the state of the multiple programs on the device quickly using this single snapshot, thereby achieving fast startup.

[0017] In one possible implementation of the first aspect, the status information of the first program includes the instruction execution status of the first program and / or the data processing status of the first program.

[0018] In this possible implementation, the instruction execution status and / or data processing status of the first program can be obtained by freezing the process executing the first program and obtaining the information of the frozen process.

[0019] In one possible implementation of the first aspect, the method further includes: updating a first program after the device mounts a file system; and, if the updated first program is started, replacing the state information of the first program in the first snapshot with the state information of the updated first program to obtain a second snapshot.

[0020] In this possible implementation, during the operation of the device after mounting the file system, the first snapshot can be updated and maintained according to the update status of the first program. In some examples, the first program can be a program outside the operating system kernel, so that updates can be performed during device operation without affecting the device's basic functions. For example, the first program can be one or more of the following: clock service, packet forwarding service, security policy initialization service, security verification service, etc.

[0021] In one possible implementation of the first aspect, before the first program is powered on and started, the method further includes: determining, based on the dependency relationship between the first program and the file system, that the startup operation of the first program is executed before the file system is mounted.

[0022] In this possible implementation, the device can pre-record the dependencies between installed programs using a tree diagram or similar method. Therefore, by querying this tree diagram, the first program that does not depend on the file system during startup can be determined, thus ensuring that its startup operation is executed before mounting the file system. For example, the first program can be identified as one whose corresponding node in the tree diagram is not connected to the corresponding node in the file system, and / or, if its corresponding node in the tree diagram is the parent node of the corresponding node in the file system, then the startup operation of this first program can be executed before mounting the file system.

[0023] As can be seen, this possible implementation method can determine which programs are powered on and started before the file system is mounted during the device startup process based on the dependency relationship between the program and the file system. It can be understood that, compared to the traditional startup process, this possible implementation method can appropriately adjust the timing of program startup operations during the startup process.

[0024] In one possible implementation of the first aspect, the first program includes one or more of the following programs: firmware, operating system kernel, initial root file system initrd, systemd program, and file system-independent application.

[0025] In this possible implementation, the application that does not depend on the file system can be an application that is independent of the file system, or it can be an application that is related to the file system but serves as the parent node of the file system.

[0026] A second aspect of this application provides a system startup method, the method comprising: generating and saving a first snapshot after a first program of a device is powered on and started but before the first program is used, so that the state of the first program of the device is restored based on the first snapshot after the device is powered on again, the first program not depending on the file system of the device, and the first snapshot including the state information of the first program after the first program is powered on and started but before the first program is used.

[0027] In the second aspect, the first program does not depend on the device's file system. Thus, the state information of the first program is not affected by the file system. Therefore, after the first program is powered on and started and before the first program is used, after the first snapshot is generated, even if the device continues to be used, there will be no problem of inconsistency between the information in the snapshot and the metadata of the file system. In other words, after the first snapshot is generated, the device can continue to be used as needed without immediately performing operations such as system restart.

[0028] In one possible implementation of the second aspect, the first snapshot further includes state information of the second program after the device's second program is powered on and before the second program is used, so that the state of the device's first program and the state of the second program can be restored based on the first snapshot after the device is powered on again.

[0029] In one possible implementation of the second aspect, the status information of the first program includes the instruction execution status of the first program and / or the data processing status of the first program.

[0030] In one possible implementation of the second aspect, after generating and saving the first snapshot, the method further includes: updating the first program; and, if the updated first program is started but not used, replacing the state information of the first program in the first snapshot with the state information of the updated first program to obtain the second snapshot.

[0031] A third aspect of this application provides a system startup apparatus having the function of implementing the first aspect or any possible implementation of the first aspect, or implementing the second aspect or any possible implementation of the second aspect. This function can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above-described function, such as a processing module and an update module.

[0032] A fourth aspect of this application provides an apparatus comprising at least one processor, a memory, and computer-executable instructions stored in the memory and executable on the processor. When the computer-executable instructions are executed by the processor, the processor performs a method as described in the first aspect or any possible implementation thereof, or as described in the second aspect or any possible implementation thereof.

[0033] The fifth aspect of this application provides a computer-readable storage medium storing one or more computer-executable instructions, wherein when the computer-executable instructions are executed by a processor, the processor performs a method as described in the first aspect or any possible implementation thereof, or as described in the second aspect or any possible implementation thereof.

[0034] The sixth aspect of this application provides a computer program product storing one or more computer-executable instructions, wherein when the computer-executable instructions are executed by a processor, the processor executes a method as described in the first aspect above or any possible implementation of the first aspect above, or as described in the second aspect above or any possible implementation of the second aspect above.

[0035] A seventh aspect of this application provides a chip system including a processor for supporting a device in implementing the functions involved in the first aspect or any possible implementation thereof, or in implementing the functions involved in the second aspect or any possible implementation thereof. In one possible design, the chip system may further include a memory for storing necessary program instructions and data for the device. This chip system may be composed of chips or may include chips and other discrete devices.

[0036] The technical effects of the third to seventh aspects or any of their possible implementations can be found in the first aspect or its related possible implementations, or in the second aspect or any of its possible implementations, as described above, and will not be repeated here. Attached Figure Description

[0037] Figure 1 This is a schematic diagram of the conventional startup process of the device provided in the embodiments of this application;

[0038] Figure 2 This is an exemplary schematic diagram of the device provided in an embodiment of this application;

[0039] Figure 3 This is a schematic diagram of an embodiment of the system startup method provided in this application;

[0040] Figure 4 This is an exemplary flowchart illustrating the generation, storage, and use of snapshots provided in the embodiments of this application;

[0041] Figure 5 This is a schematic diagram of an embodiment of the system startup device provided in this application;

[0042] Figure 6 This is a schematic diagram of the structure of the device provided in the embodiment of this application. Detailed Implementation

[0043] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is for explaining specific embodiments only and is not intended to limit the scope of this application.

[0044] As will be known to those skilled in the art, with the development of technology and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0045] In this application, "at least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. The terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms can be used interchangeably where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms “comprising” and “having”, and any variations thereof, are intended to cover non-exclusive inclusion, such that a process, method, system, product, or apparatus that comprises a series of units is not necessarily limited to those units, but may include other units not expressly listed or inherent to those processes, methods, products, or apparatus.

[0046] The following section will first introduce some of the concepts involved in this application.

[0047] 1. Program

[0048] In this application, the types of programs include firmware and software.

[0049] 1) Firmware

[0050] Firmware refers to the device driver stored inside the device. It is the low-level code that connects the hardware and the operating system when the computer starts up. It can be a program written to erasable programmable read-only memory (EPROM) or electrically erasable programmable read-only memory (EEPROM).

[0051] Firmware is essential for the operating system to perform specific machine actions according to standard device drivers. For example, optical drives and CD burners all have internal firmware.

[0052] For example, the basic input output system (BIOS) firmware is a set of programs stored in the server's BIOS flash memory, including the server's basic input output program, power-on self-test program, and system startup program.

[0053] 2) Software

[0054] Software is a collection of computer data and instructions organized in a specific order. Software can include system software, application software, and middleware that lies between the two.

[0055] For example, in the scenario of device booting up, the software involved may include the operating system, and taking Linux as an example, it also involves the initial root file system initrd, the init software systemd program under Linux, and one or more applications that provide services.

[0056] 2. Operating System

[0057] An operating system is a set of interconnected system software programs that manage and control the operation of computers and other devices, utilize and run hardware and software resources, provide public services, and organize user interactions.

[0058] In computers and other devices, the operating system is the most basic and crucial foundational system software. Compared to other software, the operating system is the first layer of software closest to the hardware; other software within the device is typically managed and controlled by the operating system, receiving its support and services.

[0059] Operating systems of different architectures typically differ in structure. For example, the Windows operating system is mainly divided into a kernel, a hardware abstraction layer (HAL), an executable, and numerous subsystems; the Unix operating system can be structurally divided into a kernel layer, a system call layer, and an application layer; while the Linux operating system mainly includes a kernel, a system user interface (shell), a file system, and applications.

[0060] As is understandable, an operating system typically includes a kernel used to manage system resources. In a broader sense, an operating system includes the kernel and system programs, and may also include middleware. The kernel serves as the actual functional part of the operating system; middleware assists in application development, while system programs support kernel operation.

[0061] 3. File system

[0062] A file system is the method and data structure used by an operating system to define files on storage devices (such as disks or NAND Flash-based solid-state drives) or partitions; that is, the method of organizing files on storage devices.

[0063] 4. Swap space

[0064] The swap partition is also known as the swap partition. In systems like Linux, the swap partition is mainly used to swap some data from memory to the swap partition when memory is insufficient, so that the system does not run out of memory or more serious situations.

[0065] 5. Persistent storage

[0066] Persistent storage makes data last longer. Specifically, it saves data to storage devices such as disks, ensuring that the data is not lost even when the computer is turned off.

[0067] 6. Suspend to disk (STD)

[0068] STD, also known as hibernation, is often used in devices such as laptops and mobile phones to achieve power saving and fast boot-up.

[0069] When using STD, the terminal saves the current system state as a snapshot and then shuts down; when the terminal boots up, it does not reload the operating system, but directly reads the snapshot to restore the original state.

[0070] Taking Linux as an example, when using STD, the terminal stores the current state of the system as a snapshot in the persistent storage swap partition at any time after the Linux system kernel has successfully started. In this way, when the Linux system restarts, it reads the snapshot from the swap partition to quickly restore to the state stored in the snapshot.

[0071] In actual use, the startup time of terminal devices, network devices, and other equipment can reflect the performance of the equipment and affect the user experience.

[0072] like Figure 1 As shown, in an exemplary conventional approach, the device startup process may include the following steps performed sequentially:

[0073] The process includes device power-on, BIOS and kernel initialization, initrd decompression, systemd startup, file system mounting, hardware initialization, service initialization, service startup, and service readiness.

[0074] It is evident that during each startup process, Figure 1 The series of steps shown takes a long time, resulting in a long startup time for the device, low processing efficiency, and a negative impact on the user experience.

[0075] Currently, one way to shorten the startup time of terminal devices and other equipment is to use STD to enable fast device startup.

[0076] However, the STD approach has at least the following problems:

[0077] 1) After taking a snapshot using STD, the device must be powered off immediately and then powered on again to run (e.g., wake up from hibernation, power off and then start up or restart).

[0078] Currently, file system metadata is stored in memory, and there is a strong consistency check between memory and hardware. If a file system exists at the time of the snapshot (STD) and the device is not powered off (e.g., not hibernating), the files in the file system will be continuously updated, and the file system metadata in memory will also be continuously updated. This can lead to inconsistencies between the system's file system metadata and the data in the snapshot. If the operating system performs a snapshot restore at this time, the inconsistency between the file system metadata in memory and the STD snapshot will occur, resulting in file system corruption and causing a very serious data loss incident.

[0079] As can be seen, currently, when using STD, the device must be powered off and then powered on again immediately after a snapshot is generated (e.g., wake up from hibernation, power off and then start up or restart), which limits the application scenarios and affects the normal use of the device.

[0080] 2) Snapshots generated using STD are one-time snapshots.

[0081] In operating systems such as Linux, snapshots generated using STD are stored in the swap partition.

[0082] When a snapshot is generated, there is no snapshot in the swap partition. That is, the swap partition recorded in the snapshot does not include the snapshot itself. After the snapshot is generated, when the system restarts and reads the snapshot from the swap partition to quickly restore to the state where the snapshot was stored, the snapshot will be lost after the system restore because the swap partition being restored does not include the snapshot itself.

[0083] It is evident that snapshots generated using STD are one-time snapshots, and will be lost after the system is powered on and restored.

[0084] Based on this, this application provides a system startup method that allows the device to continue to be used as needed after generating a snapshot for fast startup, and to achieve fast startup by powering back on as needed using the generated snapshot. In some examples, the snapshot can be reused.

[0085] The embodiments of this application can be applied to devices.

[0086] The specific type of device is not limited here. For example, the device can be a terminal device, a network device, a single server or a server cluster, or a virtual machine (VM) or container (Docker), etc.

[0087] There are no restrictions on the type of terminal device.

[0088] For example, the terminal device can be one or more of the following: mobile phone, tablet computer, computer with wireless transceiver function, virtual reality (VR) terminal, augmented reality (AR) terminal, terminal in industrial control, terminal in self-driving, terminal in remote medical care, terminal in smart grid, terminal in transportation safety, terminal in smart city, terminal in smart home, terminal in Internet of Things (IoT), wearable device, robot, etc.

[0089] When the device is a network device, there can be various types of network devices. For example, the network device can be a switch, router, firewall, bridge, hub, gateway, virtual private network (VPN) server, network interface controller (NIC), wireless access point (AP), modem, radio access network (RAN) equipment such as base station, optical transceiver, fiber optic transceiver, etc.

[0090] like Figure 2In the example shown, the device may have an operating system installed. This operating system can be an existing system such as Linux or Windows, or another existing or future-developed operating system. This embodiment does not limit this. For example, when the device is a network device, the operating system installed on the network device can be a Linux network operating system or other Linux-based operating system used for network devices. Furthermore, in some examples, the device may also include firmware, hardware, etc. The specific types of hardware included in the device and the corresponding firmware can be varied. For example, the hardware may include storage devices, sensing devices, etc., and the type of hardware is determined accordingly; no limitation is made here.

[0091] like Figure 2 As shown, starting a device can include starting the device's operating system; in addition, in some examples, it can also include starting other programs.

[0092] In this embodiment, a snapshot can be generated and saved for the device to start up quickly in the future. In this embodiment, the state information in the generated snapshot does not depend on the file system and is therefore unaffected by the file system. This allows the device to continue to be used as needed after a snapshot for quick startup is generated, and the system state of the device can be restored by the generated snapshot after power-on as needed, thus achieving quick startup.

[0093] In this embodiment of the application, there are multiple ways to make the state information in the generated snapshot independent of the file system and thus unaffected by the file system. Specifically, step 301 illustrates an exemplary way of generating and saving a snapshot in this embodiment of the application, and step 302 illustrates another exemplary way of generating and saving a snapshot in this embodiment of the application.

[0094] The following section uses the first snapshot as an example to introduce steps 301 and 302 respectively.

[0095] Method 1: Based on the above-mentioned equipment, such as Figure 3 In the example shown, a system startup method according to an embodiment of this application may include step 301.

[0096] Step 301: After one or more programs on the device are powered on and before the file system is mounted, generate and save the first snapshot.

[0097] The first snapshot includes the state information of one or more programs after they have been powered on and before the file system has been mounted.

[0098] In some examples, the power-on startup of one or more programs and the mounting of the file system in step 301 can be considered as included in the first startup process of the device.

[0099] The device startup process can include the process from powering on the device to the point where the device's operating system is able to provide services (e.g., provide services to the user). Powering on the device refers to connecting the device to a power source.

[0100] Mounting a file system refers to the operation performed by the operating system to make computer files and directories on storage devices (such as hard drives, compact disc read-only memory, CD-ROMs, or shared resources) accessible to users through the computer's file system. In operating systems such as Windows and Linux, mounting a file system is typically included during the boot process. For example, in Linux, mounting a file system can refer to mounting a storage device to an existing directory.

[0101] It is understood that, in the embodiments of this application, the first startup process of the device can be any startup process of the device, and is not limited to the first startup process of the device.

[0102] For example, when the device's operating system is Linux, the first boot process may include the following multiple steps executed in sequence:

[0103] The process includes firmware stages such as BIOS, kernel initialization, decompressing initrd, booting the centralized system and configuration management program systemd, mounting the file system, hardware initialization, service initialization, service startup, and service readiness.

[0104] Alternatively, in other examples of Linux systems or scenarios corresponding to other operating systems, the first boot process may include steps different from the multiple steps mentioned above, or may include more, fewer, or different steps in different execution order than the multiple steps mentioned above.

[0105] In this embodiment of the application, the first startup process may include one or more program power-on startups, wherein program power-on startup may refer to performing a startup operation on the program after the device is powered on. The one or more program power-on startups may include a first program power-on startup, specifically, in some examples, it may include the first program power-on startup for the first time.

[0106] In some examples, the first snapshot can be generated after any power-on startup of the first program and before the file system is mounted. In other examples, the first snapshot can be generated after the first program's initial power-on startup and before the file system is mounted. In other words, in this example, since the first program exists during the first startup process before the file system is mounted, it can be assumed that the state information of the first program needs to be obtained as the latest snapshot, and the first snapshot is generated at the specified generation time during the first startup process. Furthermore, in this example, if one or more programs are not starting for the first time during a certain startup process, it is very likely that a snapshot storing the state information of one or more programs after power-on startup and before the file system is mounted already exists, so there is no need to obtain the snapshot again. It can be seen that in this example, a snapshot can be obtained only when a program is starting for the first time, thereby avoiding repeated and invalid operations, reducing resource consumption, and improving processing efficiency.

[0107] The first procedure is described below as an example.

[0108] The specific type of the first program and the number of programs it includes can vary, and no restrictions are imposed here.

[0109] For example, the first program can be firmware or software (e.g., the kernel of an operating system and / or system software). The first program can be a single program or can include multiple programs.

[0110] The first program can be launched for the first time during the first startup process in any of the following situations:

[0111] 1) The first program is the program that is installed on the device for the first time. Therefore, the first program has not been started before step 301, but is started for the first time in step 301;

[0112] 2) The first program is the program in the device that has been updated by new plug-ins, updated software packages, etc. In this case, the updated program is the first program, and the updated program has not been started before step 301, but is started for the first time in step 301.

[0113] Furthermore, in this embodiment of the application, the first program is included in one or more programs, and the startup timing of the one or more programs is during the first startup process of the device, after the device is powered on and before the file system is mounted.

[0114] As can be seen, one or more programs can be executed without relying on the file system, thus enabling them to be powered on and started before the file system is mounted during the startup process.

[0115] For example, the one or more programs may include one or more of the following programs:

[0116] Firmware, operating system kernel, initial root file system initrd, systemd programs, and file system-independent applications.

[0117] It is understandable that when any of the programs in one or more programs are of different types, there can be multiple scenarios for the startup operation performed on that program. These will be described in detail below.

[0118] In one example, the program or program includes firmware, such as BIOS or Unified Extensible Firmware Interface (UEFI).

[0119] At this point, taking the BIOS as an example, the boot operation performed on the firmware may include one or more of the following steps in the firmware phase:

[0120] 1) Power-on self-test (POST): When the device is powered on, it checks whether the hardware devices are working properly, including memory, central processing unit (CPU), hard drive, graphics card, etc.

[0121] 2) Booting the BIOS: After the power-on self-test is completed, the device boots the Basic Input Output System (BIOS) to load the operating system and perform subsequent boot steps.

[0122] In one example, the one or more programs may include the kernel of an operating system, and the boot operation performed on the kernel may include kernel initialization.

[0123] In one example, the one or more programs may include initrd, and the startup operation performed on initrd may include unpacking initrd.

[0124] In one example, the one or more programs may include systemd programs, and the startup operation performed on the systemd program may include starting the systemd program.

[0125] In another example, the one or more programs may include file system-independent applications, and the startup operation performed on a file system-independent application may include initializing the application.

[0126] In this example, an application that does not depend on the file system can be either an application that is independent of the file system or an application that is related to the file system but serves as the parent node of the file system.

[0127] Specifically, when the dependency relationship between an application and the file system is described using a tree diagram, the statement that an application does not depend on the file system can mean either that the node corresponding to the application is not connected to the node corresponding to the file system in the tree diagram, or that the node corresponding to the application is the parent node of the node corresponding to the file system. In this case, the node corresponding to the application being the parent node of the node corresponding to the file system can mean that the file system depends on the application; in other words, it can mean that the application is associated with the file system, and the file system needs to be mounted and used after the application starts.

[0128] For example, an application that does not depend on the file system can be one or more of the following: clock service, message forwarding service, security policy initialization service, and security verification service.

[0129] In this embodiment of the application, one or more programs may include all programs that are powered on and started before the file system is mounted during the first boot process, or may include some programs that are powered on and started before the file system is mounted during the first boot process (for example, one or more programs may include the kernel, initrd and systemd, but not the BIOS).

[0130] In some embodiments, the one or more programs may be predetermined before the first startup process (e.g., during the historical operation of the device) or determined during the first startup process (e.g., at the beginning of the first startup process).

[0131] In some embodiments, prior to the first program being powered on and started, the method further includes: determining one or more programs based on the dependencies between the programs associated with the first startup process of the device and the file system.

[0132] Specifically, taking the first program in one or more programs as an example, the startup operation of the first program can be determined to be executed before the file system is mounted, based on the dependency relationship between the first program and the file system, thereby determining that the first program is contained in one or more programs.

[0133] In this embodiment, the dependencies between programs and the file system can be used to determine which programs are powered on and started before the file system is mounted during the device startup process. Therefore, in this embodiment, compared to the traditional startup process, the timing of program startup operations can be appropriately adjusted.

[0134] For example, such as Figure 1 In the traditional startup process shown, the service initialization step is performed after the file system is mounted. However, in some examples of this application's embodiments, if... Figure 1In the service initialization step shown, if a certain service does not depend on the file system, the startup operation of that service can be adjusted to be performed before mounting the file system. In other words, the startup operation of that service can be determined to be performed before mounting the file system based on the dependency relationship between the service and the file system.

[0135] There are several ways to record the dependencies between the first program and the file system, and no restrictions are placed here. For example, the dependencies between the first program and the file system can be recorded using a tree diagram or a list.

[0136] In one example, the device may pre-define the dependencies between programs installed on the device using a tree diagram or similar method. Therefore, after determining the programs associated with the device's first boot process, one or more programs that do not depend on the file system can be identified by querying the tree diagram.

[0137] For example, in the program associated with the first boot process of the device, a program whose corresponding node in the tree diagram is not connected to the node corresponding to the file system, and / or a program whose corresponding node in the tree diagram is the parent node of the node corresponding to the file system, can be one or more programs.

[0138] In this embodiment of the application, after powering on one or more programs and before mounting the file system, a first snapshot is generated. At this time, the state information recorded in the first snapshot can be unaffected by the file system.

[0139] Since the specific details of the programs contained in the one or more programs and the power-on startup methods are varied, the specific timing for generating the first snapshot can also vary.

[0140] The following examples illustrate this point.

[0141] 1) One or more programs are the first program.

[0142] In one example, where the one or more programs are the first program, a first snapshot can be generated at any point in time between the first program being powered on and booted for the first time and before the file system is mounted. This first snapshot includes the state information of the first program after the first program is powered on and booted for the first time and before the file system is mounted.

[0143] 2) One or more procedures include a first procedure and a second procedure that is different from the first procedure.

[0144] Specifically, in this example, the first snapshot also includes the status information of the second program after the device's second program is powered on and before the file system is mounted.

[0145] The startup order between the second program and the first program can be varied.

[0146] In one example, one or more programs include a first program and a second program different from the first program, and the first program and the second program are powered on and started sequentially.

[0147] In one example, the one or more programs include a first program and a second program different from the first program, which may be the first power-on startup during the first startup process or may have been performed during other startup processes prior to the first startup process.

[0148] Furthermore, in this example, the first program and the second program are powered on and started sequentially; for example, the first program is powered on and started for the first time, and then the second program is powered on and started. Therefore, the first snapshot is generated at a certain point in time, after the second program has been powered on and started but before the file system is mounted.

[0149] In another example, one or more programs include a first program and a second program different from the first program, and the first program and the second program are powered on and started in parallel.

[0150] In one example, the one or more programs include a first program and a second program different from the first program, which may be the first power-on startup during the first startup process or may have been performed during other startup processes prior to the first startup process.

[0151] Furthermore, in this example, the first program and the second program are powered on and started in parallel. Therefore, the first snapshot is generated at a certain point in time, after both the first program and the second program have been powered on and started, but before the file system is mounted.

[0152] It is evident that when the one or more programs are actually multiple programs, regardless of whether the startup operations of these multiple programs are executed sequentially or in parallel, the first snapshot can be generated at a certain point in time after each of the multiple programs has performed its corresponding startup operation and before the file system is mounted.

[0153] Furthermore, based on the above examples, it can be seen that the first snapshot may only include the status information of the first program that starts up for the first time and no longer include the status information of other programs; or, the first snapshot may include the status information of the first program that starts up for the first time and may also include the status information of other programs whose startup operation is performed before mounting the file system. This application embodiment does not limit this.

[0154] For example, the state information included in the first snapshot can be determined based on the startup operation corresponding to the one or more programs.

[0155] For example, if the one or more programs include an operating system kernel, and the boot operation performed on the kernel may include kernel initialization, then the kernel's status information includes the status information of the initialized kernel; if the one or more programs may include an initrd, and the boot operation performed on the initrd may include decompressing the initrd, then the initrd's status information may include the status information of the decompressed initrd; if the one or more programs may include a systemd program, and the boot operation performed on the systemd program may include starting the systemd program, then the systemd program's status information may include the status information of the systemd program after it has started; and if the one or more programs may include one or more services that are not dependent on a file system, and the boot operation performed on the one or more services that are not dependent on a file system may include initializing the one or more services, then the status information of the one or more services includes the status information of the one or more services after they have been initialized.

[0156] Taking the first program as an example, in the first snapshot, the status information of the first program may include the instruction execution status and / or the data processing status of the first program.

[0157] The instruction execution status and / or data processing status of the first program can be included in the relevant information of the process executing the first program.

[0158] Specifically, the one or more programs can be run through kernel-mode and / or user-mode processes, or executed through the registers of processors such as the CPU. Therefore, a first snapshot can be generated by freezing the kernel-mode and / or user-mode processes corresponding to the one or more programs and obtaining the data of the kernel-mode and / or user-mode processes. Data in the processor's registers can also be saved to store the running state of the one or more programs, such as the execution state of instructions during execution and the data processing state of related data.

[0159] As can be seen, in this method, the state information of one or more programs that start before the file system is mounted is necessarily unaffected by the file system, and the first snapshot generated at this time is also necessarily unaffected by the file system. Therefore, after generating and saving the first snapshot, the device can continue to be used as needed without immediately performing system restarts or other operations. In other words, there is no restriction on when the device is powered on again after saving the first snapshot.

[0160] Method 2: Based on the above equipment, such as Figure 3 In the example shown, a system startup method according to an embodiment of this application may include step 302.

[0161] Step 302: After one or more programs on the device are powered on and before one or more programs are used, generate and save the first snapshot.

[0162] One or more programs are independent of the device's file system. The first snapshot includes state information of one or more programs after they are powered on and before they are used.

[0163] One or more programs may include a first program. In this case, step 302 may specifically be to generate and save a first snapshot after the first program of the device is powered on and started but before the first program is used, so that the state of the first program of the device can be restored based on the first snapshot after the device is powered on again. The first program does not depend on the device's file system. The first snapshot includes the state information of the first program after the first program is powered on and started but before the first program is used.

[0164] In this example, program usage refers to the normal use of the program's functions. For example, after the program is started, it can run normally on the device to process data or execute instructions, or it can interact with the user.

[0165] In this example, the first program does not depend on the device's file system. Thus, the state information of the first program is not affected by the file system. Therefore, after the first program is powered on and started but before the first program is used, and after the first snapshot is generated, the device will not have any problems with the information in the snapshot being inconsistent with the file system's metadata, even if it continues to be used. In other words, after the first snapshot is generated, the device can continue to be used as needed without immediately performing operations such as system restart.

[0166] In some examples, the first program being independent of the device's file system can specifically mean that the first program is file system-independent. Because the first program is file system-independent, the state information of the first program is not affected regardless of when the file system is mounted and used. Therefore, in this example, the first snapshot can be generated either before or after the file system is mounted.

[0167] In addition, in some examples, the first snapshot may also include the state information of the second program after the device is powered on and before the second program is used, so that the state of the first program and the state of the second program of the device can be restored based on the first snapshot after the device is powered on again.

[0168] In this example, other relevant descriptions of the first program, the second program, and status information can be found in the relevant embodiments of Method 1, and will not be repeated here. For example, the first program and the second program can run in parallel or serially, and the first snapshot can be generated and saved after both the first program and the second program have been powered on and started, but when neither of the first program nor the second program is in use. Furthermore, the status information of the first program includes the instruction execution status of the first program and / or the data processing status of the first program.

[0169] In either method one or method two described above, a first snapshot can be generated and saved.

[0170] When saving the first snapshot, the first snapshot can be written directly to the storage space when it is generated, or it can be generated in memory or cache and then written from memory or cache to storage space such as disk to achieve the storage of the first snapshot.

[0171] In this embodiment, a first snapshot can be saved so that during the startup process after the device is powered off and then powered on again (e.g., restarting or turning on after being shut down), the first snapshot can be read to directly restore the state of the first snapshot, thereby shortening the startup time of the device and speeding up the startup speed of the device.

[0172] The following provides an example of how the first snapshot can be saved.

[0173] The storage location of this first snapshot can be in several ways.

[0174] Save the first snapshot to persistent storage.

[0175] For example, the persistent storage space can be a storage device such as a disk or solid-state drive in the device.

[0176] In this embodiment of the application, persistent storage space can realize persistent storage of data. For example, in a Linux system, the first snapshot can be saved to a regular file on the disk in the form of file storage.

[0177] In this way, the first snapshot stored in the persistent storage space will not be lost even when the device is powered off. Furthermore, compared to the traditional STD technology where snapshots are one-time snapshots, in this embodiment, since the first snapshot is saved to the persistent storage space, it can still be retained after being used for system restoration, enabling subsequent reuse and thus improving the availability of the first snapshot.

[0178] In another embodiment, the first snapshot may also be saved in a storage space such as a swap partition.

[0179] The following example illustrates an exemplary process for generating and saving the first snapshot.

[0180] like Figure 4 In the example shown, during the device's first boot process, after powering on one or more programs and before mounting the file system, a first snapshot can be instructed to be generated via a specified instruction. For example, this specified instruction could be:

[0181] echo disk> / sys / power / state.

[0182] The process of generating and saving the first snapshot in response to the specified instruction may include the following steps:

[0183] 1. Freeze user-mode processes;

[0184] 2. Freeze kernel-mode processes. By freezing both user-mode and kernel-mode processes, the startup process can be prevented from continuing.

[0185] 3. Save the state information of user-mode processes. For example, the memory information of user-mode processes can be saved, specifically including: the code and data of user-mode processes (such as one or more of the executable file, installation package, configuration information, etc. of the program corresponding to the user-mode process).

[0186] 4. Save the state information of kernel-mode processes. For example, the memory information of kernel-mode processes can be saved, specifically including:

[0187] 1) Management information for user-mode processes;

[0188] 2) The code and data of the program corresponding to the kernel-mode process (such as one or more of the executable file, installation package, and configuration information of the program corresponding to the kernel-mode process);

[0189] 5. The data stored in the registers of the CPU or other processor is used to restore the execution state of the one or more programs in the device. This includes, for example, one or more pieces of information such as the execution time corresponding to the first snapshot, the execution status of the relevant instructions of the one or more programs, and the processing status of the relevant data. The processor's registers can be used to execute the relevant instructions of the one or more programs and / or process the relevant data of the one or more programs.

[0190] 6. Summarize the state information of user-mode processes, the state information of kernel-mode processes, and the data in the registers of processors such as the CPU, obtain the first snapshot, and write it to persistent storage space such as disk.

[0191] Understandable. Figure 4 This is merely an exemplary description of an embodiment of this application and is not intended to be limiting. In other examples, it may include... Figure 4 Examples can include more or fewer steps, or may include... Figure 4 Examples of different steps, or, Figure 4 The order of steps in the example can also be changed (for example, the order of saving the memory information of the user-mode process, saving the memory information of the kernel-mode process, and saving the CPU registers can be changed), and this application embodiment does not limit this.

[0192] In this embodiment, during the first boot process, the boot operation of one or more programs occurs before the file system is mounted, and these programs can be considered independent of the file system. Therefore, the state information recorded in the first snapshot, generated after the one or more programs are powered on and before the file system is mounted, is not affected by the file system. Thus, even if the device remains in use after the first snapshot is generated, and the file system metadata changes with the device's usage status, the state information of the one or more programs during the boot process recorded in the first snapshot will not be affected. In other words, there will be no data inconsistency between the file system metadata and the data recorded in the first snapshot.

[0193] As can be seen, compared to the traditional STD approach where the device needs to be powered down immediately after a snapshot is generated, in this embodiment, the device can continue to be used as needed after the first snapshot is generated and saved, without the need for an immediate system restart. In other words, in this embodiment, there is no restriction on when the device should be powered back on after the first snapshot is saved.

[0194] After the first snapshot is generated, when the device is powered on again as needed, it can be quickly started using the generated first snapshot, which shortens the device startup time and speeds up the startup process.

[0195] Furthermore, in some embodiments, during the operation of the device after the first startup process is completed, the first snapshot can be updated and maintained according to the program update status.

[0196] The following example illustrates the update process of the second program. The second program can be the first program; or, the second program can be a program different from the first program among one or more programs. When the first snapshot is not updated and maintained, the first snapshot stores the status information of the second program after it is powered on and before the file system is mounted.

[0197] Specifically, in some embodiments, after the device's first program powers on and before the file system is mounted, a first snapshot is generated and saved; in this case, the method further includes:

[0198] After the device mounts the file system, update the second program in one or more programs;

[0199] When the updated second program is started, the state information of the second program in the first snapshot is replaced with the state information of the updated second program to obtain the second snapshot.

[0200] The second procedure can be the first procedure, or it can be different from the first procedure.

[0201] Specifically, when the second program is the first program, the first program can be updated during operation after the device mounts the file system; then, during operation, when the updated first program is started for the first time, the status information of the first program in the first snapshot is replaced according to the status information corresponding to the first start operation of the updated first program, so as to update the first snapshot.

[0202] In some embodiments, after the device's first program is powered on and started but before the first program is used, a first snapshot is generated and saved. After generating and saving the first snapshot, the method further includes:

[0203] Update the second program in one or more programs;

[0204] If the updated second program is started but not used, the state information of the second program in the first snapshot is replaced with the state information of the updated second program to obtain the second snapshot.

[0205] Specifically, when the second program is the first program, the first program can be updated after the first snapshot is generated and saved; if the updated first program is started but not used, the status information of the first program in the first snapshot is replaced with the status information of the updated first program to obtain the second snapshot.

[0206] In this embodiment, the second program can be updated during device operation, and the updated second program can be launched. In some examples, the second program can be a program outside the operating system kernel, thereby allowing updates to be performed during device operation without affecting the device's basic functions. For example, the second program can be one or more of a clock service, a packet forwarding service, a security policy initialization service, a security verification service, etc.

[0207] During operation, when the updated second program is launched for the first time, the status information corresponding to the first launch operation of the updated second program can be consistent with the status information after the launch operation performed by the updated second program before mounting the file system during the device's startup process.

[0208] For example, the startup operation performed by the updated second program before mounting the file system or before using the updated second program initializes the updated second program. The state information of the second program stored in the first snapshot can be the state information of the initialized second program. Therefore, during runtime, in the case of the first startup of the updated second program, the state information corresponding to the first startup operation of the updated second program can be the state information of the initialized updated second program. In other words, in this example, the state information of the initialized updated second program can replace the state information of the initialized second program in the first snapshot to update the first snapshot.

[0209] In this embodiment of the application, during the operation of the device after startup, any one of one or more programs can be updated. After the update, the updated second program can be started without powering off the device, and the status information of the second program in the first snapshot can be incrementally updated. This provides a way to quickly and accurately update the first snapshot while the device is running, which can ensure the accuracy of the snapshot.

[0210] For ease of description, in the embodiments of this application, the updated first snapshot can be referred to as the second snapshot. The second snapshot can be used to restore the updated state information of the second program of the device based on the first snapshot after the device is powered on again. That is to say, the purpose of the second snapshot is the same or similar to that of the first snapshot, and the usage is also the same or similar to that of the first snapshot. Both can be used in subsequent steps (e.g., for step 303) to achieve rapid startup of the device.

[0211] In this embodiment of the application, generating and saving a first snapshot allows the device to restore the state of its first program based on the first snapshot after power-on, thereby achieving rapid restoration of the device state and enabling rapid device startup.

[0212] Specifically, in some embodiments, after generating and saving the first snapshot, the method further includes step 303.

[0213] Step 303: After the device is powered on again, restore the state of one or more programs of the device based on the first snapshot.

[0214] For example, if the first snapshot includes the state information of the first program after it is powered on and before the file system is mounted, the state of the first program of the device can be restored based on the first snapshot after the device is powered on again.

[0215] In this embodiment of the application, "powering the device back on" refers to turning the device power off and then on again. For example, it could be restarting the device, waking it from hibernation, or turning it off and then on again.

[0216] In step 303, the device can be powered on for the first time after the first snapshot is generated, or it can be powered on for any subsequent nth time after the first snapshot is generated, where n is greater than 1. It can be considered that the device power-on operation in step 303 is the start of the device's second startup process. The second startup process is any startup process after the first startup process.

[0217] For example, the second startup process of the device can be the next startup process after the first startup process. In this case, the device can be powered on again after the first startup process, thereby triggering the second startup process. In this example, powering on the device can be a reboot, a sleep cycle followed by waking up, or a shutdown followed by startup, etc.

[0218] In this example, since the first snapshot records the state information of a program that is independent of the file system, even if the device is still in use and the file system metadata changes with the device's usage state after the first snapshot is generated, the state information of the program during startup recorded in the first snapshot will not be affected. In other words, there will be no data inconsistency between the file system metadata and the data recorded in the first snapshot.

[0219] As can be seen, compared to the traditional STD approach where the device needs to be powered down immediately after a snapshot is generated, in this example, after generating and saving the first snapshot, the device can continue to be used as needed without immediately performing a system restart. In other words, in this example, there is no restriction on when the device should be powered back on after saving the first snapshot.

[0220] Alternatively, in some examples, the first snapshot can be saved in persistent storage such as disk. In this case, even if the device is repeatedly powered off and on, the first snapshot will not be deleted from the persistent storage if one or more programs associated with the first snapshot are not updated. Therefore, the first snapshot can be retained after it has been used for system restore, allowing for reuse. In this example, the second boot process can be any boot process after the first boot process, without being limited to the second boot process being the next boot process after the first boot process.

[0221] During the second boot process of the device, the first snapshot can be read.

[0222] There are several possible scenarios regarding when the device reads the first snapshot.

[0223] For example, in one instance, such as Figure 4 In the example shown, for a Linux system, the first snapshot is read after the device is powered on and the firmware stages such as BIOS are executed.

[0224] In this example, the one or more programs associated with the first snapshot may include programs that perform operations during the device's boot process, after the firmware phase and before the file system is mounted. For example, the programs associated with the first snapshot may include one or more programs such as kernel initialization-related programs, initrd, systemd, or file system-independent services.

[0225] Alternatively, in another example, the first snapshot is read after the device is powered on and firmware stages such as the BIOS are skipped via kernel execution (Kexec).

[0226] In this example, Kexec is a mechanism within the Linux kernel. Kexec skips the bootloader and hardware initialization phases executed by system firmware (such as BIOS or UEFI), directly loading the new kernel into main memory and starting execution immediately, thus allowing a new kernel to boot from the currently running kernel. Therefore, Kexec can skip firmware phases such as the BIOS.

[0227] Thus, in this example, on a device using Kexec, the first snapshot can be read by skipping the firmware phase after the device is powered on.

[0228] In this example, the one or more programs associated with the first snapshot may include programs that perform operations during the device's boot process, after the firmware phase and before the file system is mounted. For example, the programs associated with the first snapshot may include one or more programs such as kernel initialization-related programs, initrd, systemd, or file system-independent services.

[0229] Alternatively, in yet another example, the first snapshot can be read after the device is powered on.

[0230] In this example, one or more programs associated with the first snapshot may include programs that perform operations during the device's boot process, after the device is powered on and before the file system is mounted. For example, the programs associated with the first snapshot may include one or more programs such as firmware stage management programs, kernel initialization-related programs, initrd, systemd, or file system-independent services.

[0231] After the device reads the first snapshot, it restores the device's state based on the first snapshot.

[0232] In this embodiment of the application, the kernel state, user state, etc. of the system can be restored based on the first snapshot, thereby restoring the state of the device.

[0233] Specifically, such as Figure 4 In the example shown, the first snapshot can be saved in persistent storage such as a disk.

[0234] After entering the kernel initialization phase, the first snapshot can be read from the disk to restore the system state.

[0235] Specifically, the memory information of the kernel-mode process can be read from the first snapshot to restore the kernel-mode process; at this time, the restored kernel-mode process is in a frozen state, that is, in a stopped state. Similarly, the memory information of the user-mode process can be read from the first snapshot to restore the user-mode process; at this time, the restored user-mode process can also be in a frozen state (that is, in a stopped state).

[0236] Furthermore, data from the registers of the CPU and other processors can be read from the first snapshot to restore the state of the registers of the CPU and other processors, thereby restoring the running state of the program associated with the first snapshot in the device's system. Specifically, this includes the running time corresponding to the first snapshot, the execution state of related instructions of one or more programs associated with the first snapshot, the processing state of related data, etc.

[0237] After restoring the state of the processor's registers, kernel-mode processes and user-mode processes can be unfrozen. This allows the system state to be restored based on the first snapshot.

[0238] Furthermore, in some examples, when generating the first snapshot using method one as described above, since the first snapshot records the state of the first program on the device before the device mounts the file system, the file system can still be mounted after restoring the state of the device based on the first snapshot.

[0239] In addition, in some examples, after the file system mounting operation is completed, one or more operations such as initializing file system dependent services, starting services, service ready, and providing services can be performed to complete the device startup process and enable users to use the device's service functions.

[0240] Among them, services that depend on the file system can be determined based on the relationship between the service and the file system.

[0241] For example, when describing the relationship between a service and a file system using a tree diagram, a service that depends on the file system can be a node in the tree diagram where the node corresponding to the service is a child node of the node corresponding to the file system. In other words, the service is associated with the file system and needs to be started and used after the file system is mounted.

[0242] For example, services that depend on a file system may include web services, File Transfer Protocol (FTP) services, etc.

[0243] In other examples, during other boot processes, if the device does not read the first snapshot from the disk after entering the kernel initialization phase, it can perform steps such as kernel initialization, decompressing initrd, starting systemd, mounting the file system, hardware initialization, service initialization, service startup, and service readiness to complete the boot process.

[0244] Tests showed that, compared to the solution that only uses Kexec to start the device, the second startup process in any embodiment of this application, which uses the first snapshot, reduces three steps. The total time taken by these three steps is more than 20 seconds, resulting in a reduction of more than 20 seconds in the overall device startup time. This effectively improves the device startup speed and enhances product competitiveness.

[0245] Furthermore, when the device is used as a network device or a node for artificial intelligence computing, in a hot start scenario, the device can use the first snapshot for a fast start, which can shorten the blackout period (the time when the forwarding chip is removed from the system management of the device) by more than 20 seconds, effectively shortening the duration of the blackout period.

[0246] The above describes the system startup method provided by the embodiments of this application from multiple aspects. The system startup device provided by the embodiments of this application will be described below with reference to the accompanying drawings.

[0247] like Figure 5 As shown, this application embodiment provides a system startup device 50.

[0248] In some embodiments, the system activation device 50 includes:

[0249] The processing module 501 is used to generate and save a first snapshot after the first program of the device is powered on and started but before the file system is mounted, so that the state of the first program of the device can be restored based on the first snapshot after the device is powered on again. The first snapshot includes the state information of the first program after the first program is powered on and started but before the file system is mounted.

[0250] Optionally, the first snapshot also includes the state information of the second program after the device is powered on and before the file system is mounted, so that the state of the first program and the state of the second program can be restored based on the first snapshot after the device is powered on again.

[0251] Optionally, the status information of the first program includes the instruction execution status of the first program and / or the data processing status of the first program.

[0252] Optionally, the system startup device 50 further includes an update module 502;

[0253] Update module 502 is used for:

[0254] After the device mounts the file system, update the first program;

[0255] If the updated first program is started, the state information of the first program in the first snapshot is replaced with the state information of the updated first program to obtain the second snapshot.

[0256] Optionally, the processing module 501 is used for:

[0257] Based on the dependency relationship between the first program and the file system, it is determined that the startup operation of the first program is executed before the file system is mounted.

[0258] Optionally, the first procedure includes one or more of the following procedures:

[0259] Firmware, operating system kernel, initial root file system initrd, systemd programs, and file system-independent applications.

[0260] Alternatively, in some embodiments, the processing module 501 is used to:

[0261] After the device's first program is powered on and started but before it is used, a first snapshot is generated and saved so that the state of the device's first program can be restored based on the first snapshot after the device is powered on again. The first program does not depend on the device's file system. The first snapshot includes the state information of the first program after it is powered on and started but before it is used.

[0262] Optionally, the first snapshot also includes the state information of the second program after the device's second program is powered on and before the second program is used, so that the state of the device's first program and the state of the second program can be restored based on the first snapshot after the device is powered on again.

[0263] Optionally, the status information of the first program includes the instruction execution status of the first program and / or the data processing status of the first program.

[0264] Optionally, update module 502 is used for:

[0265] Update the first program;

[0266] If the updated first program is started but not used, the state information of the first program in the first snapshot is replaced with the state information of the updated first program to obtain the second snapshot.

[0267] Figure 6The diagram shown is a possible logical structure of the device 60 provided in an embodiment of this application. The device 60 is used to implement the functions of the device involved in any of the above embodiments. The device 60 includes: a memory 601, a processor 602, a communication interface 603, and a bus 604. The memory 601, processor 602, and communication interface 603 are interconnected via the bus 604.

[0268] The memory 601 may be a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 601 may store a program. When the program stored in the memory 601 is executed by the processor 602, the processor 602 and the communication interface 603 are used to execute one or more steps in steps 301-303 of the above-described system boot method embodiment.

[0269] Processor 602 may be a central processing unit (CPU), microprocessor, application-specific integrated circuit (ASIC), graphics processing unit (GPU), digital signal processing (DSP), field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or any combination thereof, for executing relevant programs to achieve the functions required by the processing module and update module in the system startup device of the above embodiments, or to execute one or more steps in the method embodiments of this application. The steps of the method disclosed in the embodiments of this application can be executed by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. The software modules may be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory 601. Processor 602 reads information from memory 601 and, in conjunction with its hardware, executes one or more steps in the system startup method embodiments described above.

[0270] The communication interface 603 uses transceiver devices, such as, but not limited to, transceivers, to enable communication between the device 60 and other devices or communication networks.

[0271] Bus 604 enables the transmission of information between various components of device 60 (e.g., memory 601, processor 602, and communication interface 603). Bus 604 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, Figure 6 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0272] In another embodiment of this application, a computer-readable storage medium is also provided, which stores computer-executable instructions. When the processor of the device executes the computer-executable instructions, the device performs the aforementioned... Figure 6 The steps performed by the processor in the process.

[0273] In another embodiment of this application, a computer program product is also provided, which includes computer-executable instructions stored in a computer-readable storage medium; when the processor of the device executes the computer-executable instructions, the device performs the above-described... Figure 6 The steps performed by the processor in the process.

[0274] In another embodiment of this application, a chip system is also provided, the chip system including a processor for implementing the above. Figure 6 The steps performed by the processor. In one possible design, the chip system may also include a memory for storing program instructions and data necessary for data writing. The chip system may consist of chips or may include chips and other discrete components.

[0275] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0276] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0277] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0278] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0279] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A system startup method, characterized by, The method comprises: generating and saving a first snapshot after a first program of a device is powered on and before a file system is mounted, so that the device restores the state of the first program based on the first snapshot after the device is powered on again, the first snapshot comprising state information of the first program after the first program is powered on and before the file system is mounted.

2. The method of claim 1, wherein, The first snapshot further comprises state information of a second program of the device after the second program is powered on and before the file system is mounted, so that the device restores the state of the first program and the state of the second program based on the first snapshot after the device is powered on again.

3. The method according to claim 1 or 2, characterized in that, The state information of the first program comprises an instruction execution state of the first program and / or a data processing state of the first program.

4. The method according to any one of claims 1 to 3, characterized in that, The method further comprises: updating the first program after the device mounts the file system; replacing the state information of the first program in the first snapshot with state information of the updated first program based on the state information of the updated first program to obtain a second snapshot in the case that the updated first program is started.

5. The method according to any one of claims 1 to 4, characterized in that, Before the first program is powered on, the method further comprises: determining that the starting operation of the first program is performed before the file system is mounted according to the dependency relationship between the first program and the file system.

6. The method according to any one of claims 1 to 4, characterized in that, The first program comprises one or more of the following programs: firmware, kernel of an operating system, initial root file system initrd, systemd program, application program not dependent on the file system.

7. A system startup method characterized by comprising: The method comprises: generating and saving a first snapshot after a first program of a device is powered on and before the first program is used, so that the device restores the state of the first program based on the first snapshot after the device is powered on again, the first program not being dependent on a file system of the device, the first snapshot comprising state information of the first program after the first program is powered on and before the first program is used.

8. The method of claim 7, wherein, The first snapshot further comprises state information of a second program of the device after the second program is powered on and before the second program is used, so that the device restores the state of the first program and the state of the second program based on the first snapshot after the device is powered on again.

9. The method according to claim 7 or 8, characterized in that, The state information of the first program comprises an instruction execution state of the first program and / or a data processing state of the first program.

10. The method according to any one of claims 7 to 9, characterized in that, After the first snapshot is generated and saved, the method further comprises: updating the first program; replacing the state information of the first program in the first snapshot with state information of the updated first program based on the state information of the updated first program to obtain a second snapshot in the case that the updated first program is started and not used.

11. A system startup apparatus, comprising: comprises: The processing module is configured to generate and save a first snapshot after the first program of the device is powered on and before a file system is mounted, so that the device is restored to a state of the first program based on the first snapshot after the device is powered on again.

12. The apparatus of claim 11, wherein, The first snapshot further includes state information of a second program of the device after the second program is powered on and before the file system is mounted, so that the device is restored to a state of the first program and a state of the second program based on the first snapshot after the device is powered on again.

13. The apparatus of claim 11 or 12, wherein, The state information of the first program includes an instruction execution state of the first program and / or a data processing state of the first program.

14. The apparatus of any one of claims 11-13, wherein, The apparatus further includes an updating module. The updating module is configured to: update the first program after the device mounts the file system; and replace the state information of the first program in the first snapshot with state information of the updated first program to obtain a second snapshot when the updated first program is started.

15. The apparatus of any of claims 11-14, wherein the processing module is configured to: determine, according to a dependency relationship between the first program and the file system, that a start operation of the first program is performed before the file system is mounted.

16. The apparatus of any one of claims 11-15, wherein, The first program includes one or more of the following programs: firmware, a kernel of an operating system, an initial root file system initrd, a systemd program, and an application program that does not depend on the file system.

17. A system boot apparatus, comprising: The apparatus includes: a processing module configured to generate and save a first snapshot after a first program of a device is powered on and before the first program is used, so that the device is restored to a state of the first program based on the first snapshot after the device is powered on again, the first program not depending on a file system of the device, the first snapshot including state information of the first program after the first program is powered on and before the first program is used.

18. The apparatus of claim 17, wherein, The first snapshot further includes state information of a second program of the device after the second program is powered on and before the second program is used, so that the device is restored to a state of the first program and a state of the second program based on the first snapshot after the device is powered on again.

19. The apparatus of claim 17 or 18, wherein, The state information of the first program includes an instruction execution state of the first program and / or a data processing state of the first program.

20. The apparatus of any of claims 17-19, wherein, The apparatus further includes an updating module. The updating module is configured to: update the first program after the device mounts the file system; and replace the state information of the first program in the first snapshot with state information of the updated first program to obtain a second snapshot when the updated first program is started.

15. The apparatus of any of claims 11-14, wherein the processing module is configured to: determine, according to a dependency relationship between the first program and the file system, that a start operation of the first program is performed before the file system is mounted. The first program includes one or more of the following programs: firmware, a kernel of an operating system, an initial root file system initrd, a systemd program, and an application program that does not depend on the file system. The apparatus includes: a processing module configured to generate and save a first snapshot after a first program of a device is powered on and before the first program is used, so that the device is restored to a state of the first program based on the first snapshot after the device is powered on again, the first program not depending on a file system of the device, the first snapshot including state information of the first program after the first program is powered on and before the first program is used. The first snapshot further includes state information of a second program of the device after the second program is powered on and before the second program is used, so that the device is restored to a state of the first program and a state of the second program based on the first snapshot after the device is powered on again. The state information of the first program includes an instruction execution state of the first program and / or a data processing state of the first program. The apparatus further includes an updating module. The updating module is configured to: update the first program after the device mounts the file system; and replace the state information of the first program in the first snapshot with state information of the updated first program to obtain a second snapshot when the updated first program is started.

Images