Electronic device, and file system operating method of electronic device

Abstract

This electronic device may comprise: a memory storing instructions and including one or more pieces of storage media; and at least one processor including processing circuitry. When executed individually or collectively by the at least one processor, the instructions can control such that the electronic device executes a kernel thread in a kernel space by using the processor, checks whether a daemon is terminated in a user space after a designated time elapses since the kernel thread was executed, increases the frequency of counting on the basis that the daemon in the user space is not terminated and waits for termination of at least one thread, determines, on the basis that the frequency of counting exceeds a designated level, that the daemon is in a non-responding state, stops all requests in progress through a file system, and determines, on the basis that all threads of the daemon are terminated, that the non-responding state of the daemon is released.

Description

Electronic devices and methods of operating file systems of electronic devices

[0001] Various embodiments of this document relate to an electronic device including a memory and a method for operating a file system of the electronic device.

[0002] Recently developed electronic devices such as smart phones, tablet PCs, portable multimedia players (PMPs), personal digital assistants (PDAs), laptop personal computers (PCs), and wearable devices can perform various functions (e.g., games, social network services (SNS), internet, multimedia, photo and video recording and playback) in addition to mobility.

[0003] Electronic devices may include storage devices such as NAND flash memory or solid state disks (SSDs) to store large amounts of data required to perform various functions.

[0004] An electronic device can write at least a portion of an application's data to main memory using a file system, which is a type of program module or software executable by a processor. Furthermore, the electronic device can use the file system to classify the type of file being written and control the file to be stored separately in memory when writing the application's data to main memory.

[0005] In electronic devices (e.g., smartphones), the file system can manage files based on system calls made by applications. For example, the file system can write data to the device's non-volatile memory (e.g., a solid-state drive (SSD)) in response to a write request from an application. In response to a read request from an application, the file system can read data from memory and provide it to the application.

[0006] The above information is provided as background information to aid in understanding the present disclosure. No claim or determination is made as to whether any of the above is applicable as prior art related to the present disclosure.

[0007] Volatile memory (e.g., random access memory (RAM)) may include a memory area corresponding to kernel space allocated to an operating system (e.g., kernel) and a memory area corresponding to user space allocated to an application. For example, a first application that calls a file system and a second application that supports processing the call (e.g., filesystem in user space (FUSE) daemon) may be loaded from non-volatile memory into user space and executed by the processor.

[0008] An electronic device may include at least one processor that stores instructions, a memory that includes one or more storage media, and processing circuitry. The instructions, when individually or collectively executed by the at least one processor, may control the electronic device to execute a kernel thread using the processor in a kernel space, determine whether a daemon has terminated in a user space after a specified period of time has elapsed after the execution of the kernel thread, increase a counting count based on the user space daemon not having terminated but is waiting for termination of at least one thread, determine that the daemon is in a non-responsive state based on the counting count exceeding a specified level, abort all requests in progress through the file system, and determine that the non-responsive state of the daemon has been released based on the termination of all threads of the daemon.

[0009] An electronic device may include at least one processor storing instructions, a memory including one or more storage media, and processing circuitry. The instructions, when individually or collectively executed by the at least one processor, may be configured to set a timer having a first predetermined period for a pending request, cancel the timer based on completion of the pending request within the first period, determine that a file system of the electronic device is normal, determine that a daemon is unresponsive based on incomplete completion of the pending request within the first period, and control to stop all pending requests through the file system of the electronic device.

[0010] An electronic device according to this document can detect a deadlock and unresponsive state of a daemon and provide a method for resolving the deadlock and unresponsive state of the daemon.

[0011] FIG. 1 is a block diagram of an electronic device within a network environment according to various embodiments.

[0012] FIG. 2a is a block diagram illustrating the structure of a file system of an electronic device according to one embodiment.

[0013] FIG. 2b is a block diagram illustrating a structure for processing a request in a file system of an electronic device according to one embodiment.

[0014] Figure 3a illustrates a communication process between a daemon and a driver in a file system according to one embodiment.

[0015] Figure 3b illustrates self I / O that may occur during communication between a daemon and a driver in a file system according to one embodiment.

[0016] FIG. 4 is a flowchart illustrating a method for operating a file system of an electronic device according to one embodiment.

[0017] FIG. 5 is a flowchart illustrating a method for determining an unresponsive state by detecting the state of a daemon in an electronic device according to one embodiment.

[0018] FIG. 6 is a flowchart illustrating a method for determining a non-responsive state using ping and a timer in an electronic device according to one embodiment.

[0019] FIG. 1 is a block diagram of an electronic device (101) within a network environment (100) according to various embodiments. Referring to FIG. 1, in the network environment (100), the electronic device (101) may communicate with the electronic device (102) via a first network (198) (e.g., a short-range wireless communication network), or may communicate with at least one of the electronic device (104) or the server (108) via a second network (199) (e.g., a long-range wireless communication network). In one embodiment, the electronic device (101) may communicate with the electronic device (104) via the server (108). According to one embodiment, the electronic device (101) may include a processor (120), a memory (130), an input module (150), an audio output module (155), a display module (160), an audio module (170), a sensor module (176), an interface (177), a connection terminal (178), a haptic module (179), a camera module (180), a power management module (188), a battery (189), a communication module (190), a subscriber identification module (196), or an antenna module (197). In some embodiments, the electronic device (101) may omit at least one of these components (e.g., the connection terminal (178)), or may have one or more other components added. In some embodiments, some of these components (e.g., the sensor module (176), the camera module (180), or the antenna module (197)) may be integrated into one component (e.g., the display module (160)).

[0020] The processor (120) may, for example, execute software (e.g., a program (140)) to control at least one other component (e.g., a hardware or software component) of the electronic device (101) connected to the processor (120) and perform various data processing or operations. According to one embodiment, as at least a part of the data processing or operations, the processor (120) may store commands or data received from other components (e.g., a sensor module (176) or a communication module (190)) in a volatile memory (132), process the commands or data stored in the volatile memory (132), and store result data in a non-volatile memory (134). According to one embodiment, the processor (120) may include a main processor (121) (e.g., a central processing unit or an application processor) or an auxiliary processor (123) (e.g., a graphics processing unit, a neural processing unit (NPU), an image signal processor, a sensor hub processor, or a communication processor) that can operate independently or together with the main processor (121). For example, when the electronic device (101) includes the main processor (121) and the auxiliary processor (123), the auxiliary processor (123) may be configured to use less power than the main processor (121) or to be specialized for a given function. The auxiliary processor (123) may be implemented separately from the main processor (121) or as a part thereof.

[0021] The auxiliary processor (123) may control at least a portion of functions or states associated with at least one component (e.g., a display module (160), a sensor module (176), or a communication module (190)) of the electronic device (101), for example, on behalf of the main processor (121) while the main processor (121) is in an inactive (e.g., sleep) state, or together with the main processor (121) while the main processor (121) is in an active (e.g., application execution) state. In one embodiment, the auxiliary processor (123) (e.g., an image signal processor or a communication processor) may be implemented as a part of another functionally related component (e.g., a camera module (180) or a communication module (190)). In one embodiment, the auxiliary processor (123) (e.g., a neural network processing unit) may include a hardware structure specialized for processing artificial intelligence models. The artificial intelligence models may be generated through machine learning. This learning can be performed, for example, on the electronic device (101) itself where the artificial intelligence model is executed, or can be performed through a separate server (e.g., server (108)). The learning algorithm can include, for example, supervised learning, unsupervised learning, semi-supervised learning, or reinforcement learning, but is not limited to the examples described above. The artificial intelligence model can include multiple artificial neural network layers.The artificial neural network may be one of a deep neural network (DNN), a convolutional neural network (CNN), a recurrent neural network (RNN), a restricted Boltzmann machine (RBM), a deep belief network (DBN), a bidirectional recurrent deep neural network (BRDNN), a deep Q-network, or a combination of two or more of the above, but is not limited to the examples described above. In addition to, or alternatively to, a hardware structure, an artificial intelligence model may include a software structure.

[0022] The memory (130) can store various data used by at least one component (e.g., processor (120) or sensor module (176)) of the electronic device (101). The data can include, for example, software (e.g., program (140)) and input data or output data for commands related thereto. The memory (130) can include volatile memory (132) or non-volatile memory (134).

[0023] The program (140) may be stored as software in the memory (130) and may include, for example, an operating system (142), middleware (144), or an application (146).

[0024] The input module (150) can receive commands or data to be used in a component of the electronic device (101) (e.g., a processor (120)) from an external source (e.g., a user) of the electronic device (101). The input module (150) can include, for example, a microphone, a mouse, a keyboard, a key (e.g., a button), or a digital pen (e.g., a stylus pen).

[0025] The audio output module (155) can output audio signals to the outside of the electronic device (101). The audio output module (155) can include, for example, a speaker or a receiver. The speaker can be used for general purposes, such as multimedia playback or recording playback. The receiver can be used to receive incoming calls. In one embodiment, the receiver can be implemented separately from the speaker or as part of the speaker.

[0026] The display module (160) can visually provide information to an external party (e.g., a user) of the electronic device (101). The display module (160) may include, for example, a display, a holographic device, or a projector and a control circuit for controlling the device. According to one embodiment, the display module (160) may include a touch sensor configured to detect a touch, or a pressure sensor configured to measure the intensity of a force generated by the touch.

[0027] The audio module (170) can convert sound into an electrical signal, or vice versa, convert an electrical signal into sound. According to one embodiment, the audio module (170) can acquire sound through the input module (150), output sound through the sound output module (155), or an external electronic device (e.g., electronic device (102)) (e.g., speaker or headphone) directly or wirelessly connected to the electronic device (101).

[0028] The sensor module (176) can detect the operating status (e.g., power or temperature) of the electronic device (101) or the external environmental status (e.g., user status) and generate an electrical signal or data value corresponding to the detected status. According to one embodiment, the sensor module (176) can include, for example, a gesture sensor, a gyro sensor, a barometric pressure sensor, a magnetic sensor, an acceleration sensor, a grip sensor, a proximity sensor, a color sensor, an IR (infrared) sensor, a biometric sensor, a temperature sensor, a humidity sensor, or an illuminance sensor.

[0029] The interface (177) may support one or more designated protocols that may be used to directly or wirelessly connect the electronic device (101) with an external electronic device (e.g., the electronic device (102)). In one embodiment, the interface (177) may include, for example, a high definition multimedia interface (HDMI), a universal serial bus (USB) interface, an SD card interface, or an audio interface.

[0030] The connection terminal (178) may include a connector through which the electronic device (101) may be physically connected to an external electronic device (e.g., electronic device (102)). According to one embodiment, the connection terminal (178) may include, for example, an HDMI connector, a USB connector, an SD card connector, or an audio connector (e.g., a headphone connector).

[0031] The haptic module (179) can convert electrical signals into mechanical stimuli (e.g., vibration or movement) or electrical stimuli that a user can perceive through tactile or kinesthetic sensations. According to one embodiment, the haptic module (179) can include, for example, a motor, a piezoelectric element, or an electrical stimulation device.

[0032] The camera module (180) can capture still images and videos. According to one embodiment, the camera module (180) may include one or more lenses, image sensors, image signal processors, or flashes.

[0033] The power management module (188) can manage power supplied to the electronic device (101). According to one embodiment, the power management module (188) can be implemented as, for example, at least a part of a power management integrated circuit (PMIC).

[0034] A battery (189) may power at least one component of the electronic device (101). In one embodiment, the battery (189) may include, for example, a non-rechargeable primary battery, a rechargeable secondary battery, or a fuel cell.

[0035] The communication module (190) may support the establishment of a direct (e.g., wired) communication channel or a wireless communication channel between the electronic device (101) and an external electronic device (e.g., electronic device (102), electronic device (104), or server (108)), and the performance of communication through the established communication channel. The communication module (190) may operate independently from the processor (120) (e.g., application processor) and may include one or more communication processors that support direct (e.g., wired) communication or wireless communication. According to one embodiment, the communication module (190) may include a wireless communication module (192) (e.g., a cellular communication module, a short-range wireless communication module, or a global navigation satellite system (GNSS) communication module) or a wired communication module (194) (e.g., a local area network (LAN) communication module, or a power line communication module). Among these communication modules, the corresponding communication module can communicate with an external electronic device (104) via a first network (198) (e.g., a short-range communication network such as Bluetooth, wireless fidelity (WiFi) direct, or infrared data association (IrDA)) or a second network (199) (e.g., a long-range communication network such as a legacy cellular network, a 5G network, a next-generation communication network, the Internet, or a computer network (e.g., a LAN or WAN)). These various types of communication modules can be integrated into a single component (e.g., a single chip) or implemented as multiple separate components (e.g., multiple chips). The wireless communication module (192) can verify or authenticate the electronic device (101) within a communication network such as the first network (198) or the second network (199) by using subscriber information (e.g., an international mobile subscriber identity (IMSI)) stored in the subscriber identification module (196).

[0036] The wireless communication module (192) can support 5G networks and next-generation communication technologies following the 4G network, such as NR access technology (new radio access technology). The NR access technology can support high-speed transmission of high-capacity data (eMBB (enhanced mobile broadband)), minimization of terminal power and connection of multiple terminals (mMTC (massive machine type communications)), or high reliability and low latency (URLLC (ultra-reliable and low-latency communications)). The wireless communication module (192) can support, for example, a high-frequency band (e.g., mmWave band) to achieve a high data transmission rate. The wireless communication module (192) can support various technologies for securing performance in a high-frequency band, such as beamforming, massive multiple-input and multiple-output (MIMO), full dimensional MIMO (FD-MIMO), array antenna, analog beam-forming, or large scale antenna. The wireless communication module (192) can support various requirements specified in the electronic device (101), an external electronic device (e.g., the electronic device (104)), or a network system (e.g., the second network (199)). According to one embodiment, the wireless communication module (192) can support a peak data rate (e.g., 20 Gbps or more) for eMBB realization, a loss coverage (e.g., 164 dB or less) for mMTC realization, or a U-plane latency (e.g., 0.5 ms or less for downlink (DL) and uplink (UL), or 1 ms or less for round trip) for URLLC realization.

[0037] The antenna module (197) can transmit or receive signals or power to or from an external device (e.g., an external electronic device). In one embodiment, the antenna module (197) may include an antenna including a radiator formed of a conductor or a conductive pattern formed on a substrate (e.g., a PCB). In one embodiment, the antenna module (197) may include a plurality of antennas (e.g., an array antenna). In this case, at least one antenna suitable for a communication method used in a communication network, such as the first network (198) or the second network (199), may be selected from the plurality of antennas, for example, by the communication module (190). A signal or power may be transmitted or received between the communication module (190) and an external electronic device via the at least one selected antenna. In some embodiments, in addition to the radiator, another component (e.g., a radio frequency integrated circuit (RFIC)) may be additionally formed as a part of the antenna module (197).

[0038] According to various embodiments, the antenna module (197) may form a mmWave antenna module. In one embodiment, the mmWave antenna module may include a printed circuit board, an RFIC disposed on or adjacent a first side (e.g., a bottom side) of the printed circuit board and capable of supporting a designated high-frequency band (e.g., a mmWave band), and a plurality of antennas (e.g., an array antenna) disposed on or adjacent a second side (e.g., a top side or a side side) of the printed circuit board and capable of transmitting or receiving signals in the designated high-frequency band.

[0039] At least some of the above components can be interconnected and exchange signals (e.g., commands or data) with each other via a communication method between peripheral devices (e.g., a bus, GPIO (general purpose input and output), SPI (serial peripheral interface), or MIPI (mobile industry processor interface)).

[0040] According to one embodiment, commands or data may be transmitted or received between the electronic device (101) and an external electronic device (104) via a server (108) connected to a second network (199). Each of the external electronic devices (102 or 104) may be the same or a different type of device as the electronic device (101). According to one embodiment, all or part of the operations executed in the electronic device (101) may be executed in one or more of the external electronic devices (102, 104, or 108). For example, when the electronic device (101) is to perform a certain function or service automatically or in response to a request from a user or another device, the electronic device (101) may, instead of or in addition to executing the function or service itself, request one or more external electronic devices to perform the function or at least a part of the service. One or more external electronic devices that receive the request may execute at least a portion of the requested function or service, or an additional function or service related to the request, and transmit the result of the execution to the electronic device (101). The electronic device (101) may process the result as is or additionally and provide it as at least a portion of a response to the request. For this purpose, cloud computing, distributed computing, mobile edge computing (MEC), or client-server computing technology may be used, for example. The electronic device (101) may provide an ultra-low latency service by using distributed computing or mobile edge computing, for example. In another embodiment, the external electronic device (104) may include an Internet of Things (IoT) device. The server (108) may be an intelligent server utilizing machine learning and / or a neural network. According to one embodiment, the external electronic device (104) or the server (108) may be included in the second network (199).The electronic device (101) can be applied to intelligent services (e.g., smart home, smart city, smart car, or healthcare) based on 5G communication technology and IoT-related technology.

[0041] Electronic devices according to the various embodiments disclosed in this document may take various forms. Electronic devices may include, for example, portable communication devices (e.g., smartphones), computer devices, portable multimedia devices, portable medical devices, cameras, wearable devices, or home appliances. Electronic devices according to the embodiments of this document are not limited to the aforementioned devices.

[0042] The various embodiments of this document and the terminology used therein are not intended to limit the technical features described in this document to specific embodiments, but should be understood to include various modifications, equivalents, or substitutes of the embodiments. In connection with the description of the drawings, similar reference numerals may be used for similar or related components. The singular form of a noun corresponding to an item may include one or more of the items, unless the context clearly indicates otherwise. In this document, each of the phrases "A or B", "at least one of A and B", "at least one of A or B", "A, B, or C", "at least one of A, B, and C", and "at least one of A, B, or C" can include any one of the items listed together in the corresponding phrase among those phrases, or all possible combinations thereof. Terms such as "first," "second," or "first" or "second" may be used merely to distinguish one component from another, and do not limit the components in any other respect (e.g., importance or order). When a component (e.g., a first component) is referred to as "coupled" or "connected" to another (e.g., a second component), with or without the terms "functionally" or "communicatively," it means that the component can be connected to the other component directly (e.g., wired), wirelessly, or through a third component.

[0043] The term "module" used in various embodiments of this document may include a unit implemented in hardware, software, or firmware, and may be used interchangeably with terms such as logic, logic block, component, or circuit. A module may be an integral component, or a minimum unit or part of such a component that performs one or more functions. For example, according to one embodiment, a module may be implemented in the form of an application-specific integrated circuit (ASIC).

[0044] Various embodiments of the present document may be implemented as software (e.g., a program (140)) including one or more instructions stored in a storage medium (e.g., an internal memory (136) or an external memory (138)) readable by a machine (e.g., an electronic device (101)). For example, a processor (e.g., a processor (120)) of the machine (e.g., an electronic device (101)) may call at least one instruction among the one or more instructions stored from the storage medium and execute it. This enables the machine to operate to perform at least one function according to the at least one called instruction. The one or more instructions may include code generated by a compiler or code executable by an interpreter. The machine-readable storage medium may be provided in the form of a non-transitory storage medium. Here, 'non-transitory' simply means that the storage medium is a tangible device and does not contain signals (e.g., electromagnetic waves), and the term does not distinguish between cases where data is stored semi-permanently or temporarily on the storage medium.

[0045] According to one embodiment, the method according to various embodiments disclosed in this document may be provided as included in a computer program product. The computer program product may be traded as a product between a seller and a buyer. The computer program product may be distributed in the form of a machine-readable storage medium (e.g., compact disc read-only memory (CD-ROM)), or may be distributed online (e.g., downloaded or uploaded) through an application store (e.g., Play Store™) or directly between two user devices (e.g., smart phones). In the case of online distribution, at least a portion of the computer program product may be temporarily stored or temporarily generated in a machine-readable storage medium, such as the memory of a manufacturer's server, an application store's server, or an intermediary server.

[0046] According to various embodiments, each component (e.g., a module or a program) of the above-described components may include one or more entities, and some of the entities may be separated and placed in other components. According to various embodiments, one or more components or operations of the aforementioned components may be omitted, or one or more other components or operations may be added. Alternatively or additionally, a plurality of components (e.g., a module or a program) may be integrated into a single component. In such a case, the integrated component may perform one or more functions of each of the plurality of components identically or similarly to those performed by the corresponding component among the plurality of components prior to the integration. According to various embodiments, the operations performed by a module, program, or other component may be executed sequentially, in parallel, iteratively, or heuristically, or one or more of the operations may be executed in a different order, omitted, or one or more other operations may be added.

[0047] FIG. 2a is a block diagram illustrating the structure of a file system of an electronic device according to one embodiment.

[0048] According to one embodiment, an electronic device (e.g., the electronic device (101) of FIG. 1) may have a user space and a kernel space. Here, the user space and the kernel space do not mean physical elements, but may mean a virtual memory space when the processor (120) executes. When the electronic device (101) executes instructions stored in the memory (130) by the processor (120), the instructions may be separated into the user space and the kernel space and executed.

[0049] An electronic device (101) may include an application (210) located in user space and a FUSE daemon (212). FUSE may mean file system in user space. FUSE may mean a software framework that provides a function to implement a file system in user space. The FUSE daemon (212) may mean a program required to execute a FUSE file system in user space. The FUSE daemon (212) may be executed with the privileges of a mounting user. A user can control a file system without editing kernel code by using the FUSE daemon (212).

[0050] An application (210) can transmit requests related to input and output (I / O) of a file to a FUSE driver (220). The FUSE driver (220) can, as a kernel module, transmit the request of the application (210) to a FUSE daemon (212).

[0051] The FUSE driver (220) may include a request queue (222) for processing requests from an application (210). The request queue (222) may include a pending queue (201) having a list of pending requests and a processing queue (203) having a list of running requests. The FUSE driver (220) and the request queue (222) may operate in kernel space.

[0052] The processor (120) can transmit at least one request to the FUSE daemon (212) using the FUSE driver (220) and the request queue (222). The FUSE daemon (212) can perform input and output processes of files in the file system.

[0053] FIG. 2b is a block diagram illustrating a structure for processing a request in a file system of an electronic device according to one embodiment.

[0054] The request queue (222) may include a pending queue (201) having a list of waiting requests and a processing queue (203) having a list of executing requests.

[0055] The pending queue (201) may include at least one request (202). The requests included in the pending queue (201) may be sequentially moved to the processing queue (203). The processing queue (203) may sequentially process the requests (204) transmitted from the pending queue (201).

[0056] According to one embodiment, the FUSE daemon (212) may perform a request fetching operation while reading the first request (202) of the pending queue (201). The request fetching operation may refer to a process of receiving data for a request from a server.

[0057] The first request (202) in the pending queue (201) can be moved to the processing queue (203). Conversely, the FUSE daemon (212) can receive the processing result for the read request and perform a request completion operation.

[0058] Figure 3a illustrates a communication process between a daemon and a driver in a file system according to one embodiment.

[0059] According to FIG. 3A, a processor (e.g., processor (120) of FIG. 1) may perform a request queuing (302) operation using a FUSE driver (320) and a request queue (322) based on a request of an application (310). The request queuing (302) operation may mean an operation of determining the order of requests to be subjected to a pending operation and a processing operation.

[0060] The processor (120) can perform a request fetching (304) operation using the FUSE daemon (212). The request fetching (304) operation may refer to a process of receiving data for a request from a server.

[0061] According to one embodiment, the processor (120) may process (306) a request of an application (310) using the FUSE daemon (212).

[0062] According to one embodiment, the processor (120) may process a request from an application (310) and transmit the processing result to a FUSE driver (320) (308). The FUSE driver (320) may transmit the request processing result of the FUSE daemon (212) to the application (310).

[0063] Figure 3b illustrates self I / O that may occur during communication between a daemon and a driver in a file system according to one embodiment.

[0064] According to one embodiment, the electronic device (101) may be located in a user space and may include a FUSE daemon (312) that accesses a file system based on a specified time period after executing a kernel thread to process requests for input and output of files. In addition, the electronic device (101) may be located in a kernel space and may include a FUSE driver (320) that transmits user input to the FUSE daemon (312) and transmits a response of the FUSE daemon (312) to an application (310). The FUSE driver (320) may include a request queue (322) for processing requests of the application (210). The request queue (322) may include a pending queue (e.g., pending queue (201) of FIG. 2A) having a list of waiting requests and a processing queue (e.g., processing queue (203) of FIG. 2A) having a list of running requests. The FUSE driver (320) and the request queue (322) may operate in kernel space.

[0065] According to one embodiment, the electronic device (101) can determine that a thread has not been terminated for a specified period of time. The electronic device (101) can determine that at least one thread of the daemon performs self I / O based on a situation in which a request must be transmitted from a daemon to a driver and a request must be transmitted back to the daemon to process the request received from the driver. Self I / O can refer to a situation in which a request is transmitted back to the daemon to perform the request transmitted from the daemon to the driver. That is, in a self I / O situation, the subject who requested input and output for a file and the subject who processes the request may be the same.

[0066] FUSE (file system in user-space) can have a more complex protocol than the kernel file system. Since FUSE is a process that runs in user-space, it can be relatively more vulnerable to system exceptions (e.g., IO deadlock, segmentation fault due to code bugs, oom kill) compared to processes that run in kernel space. IO deadlock can mean a state where two or more processes are waiting for a resource. A segmentation fault can occur when a program tries to access a memory address that it cannot access. Alternatively, a segmentation fault can occur when allocated memory is not freed and continues to be used. oom (out of memory) kill can mean a command that forcibly terminates unused processes when the system is low on memory.

[0067] FUSE (file system in user-space) can structurally cause IO deadlock. For example, an application that does not have access rights to a specific file may require user consent. In this case, since the application cannot access the file, FUSE (file system in user-space) can directly open the file and pass it to the application. During this process, the application can send a request to FUSE (file system in user-space) to open the file. FUSE (file system in user-space) can send the request to the FUSE daemon (312) to open the file. The FUSE daemon (312) can send a response to the FUSE driver (320) that sets access rights to open the file. After the FUSE driver (320) is granted access rights, it can send a request to the FUSE daemon (312) to open the file. During this process, self I / O may occur in the FUSE daemon (312).

[0068] The FUSE daemon (312) can send a response to the FUSE driver (320) that sets access rights for opening a file. In addition, the FUSE daemon (312) can send a response to a request to open a file to the FUSE driver (320). In this process, the subject requesting input and output (I / O) of the file also becomes the FUSE daemon (312), and the subject processing the input and output (I / O) of the file also becomes the FUSE daemon (312), so self I / O can occur.

[0069] The FUSE daemon (312) transmits a response to the FUSE driver (320) that sets access rights for opening a file, and since the response has been completed, all threads can be terminated. The FUSE driver (320) can transmit a request to open a file to the FUSE daemon (312) and wait for a response from the FUSE daemon (312) while keeping at least one thread running. Since at least one thread included in the FUSE daemon (312) is running, the FUSE process may not be terminated. In order for at least one thread included in the FUSE driver (320) to be terminated, the request to open a file may have to be completed and a response may have to be received. However, since all threads of the FUSE daemon (312) are terminated, it may be difficult for the FUSE driver (320) to receive a response even if it sends a request to open a file. In this case, at least one thread of the FUSE driver (320) may continue to operate. Then, the FUSE may remain in an unprocessed state, making it difficult to perform other operations, and the electronic device (101) may remain difficult to use. The electronic device (101) according to the present document may identify an unresponsive state of the electronic device (101) and provide a method for resolving the unresponsive state. The process of identifying and resolving the unresponsive state by the electronic device (101) according to the present document will be described with reference to FIGS. 4 to 6.

[0070] FIG. 4 is a flowchart illustrating a method for operating a file system of an electronic device according to one embodiment.

[0071] The operations described through FIG. 4 can be implemented based on instructions that can be stored in a computer recording medium or memory (e.g., memory (130) of FIG. 1). The illustrated method (400) can be executed by the electronic device described above through FIGS. 1 to 3 (e.g., electronic device (101) of FIG. 1), and the technical features described above will be omitted below. The order of each operation of FIG. 4 can be changed, some operations can be omitted, and some operations can be performed simultaneously.

[0072] In operation 410, the electronic device (101) may execute a kernel thread in the kernel space under the control of a processor (e.g., the processor (120) of FIG. 1) and check whether a daemon has been terminated after a specified period of time. A kernel thread may refer to a thread executed within an operating system kernel. A thread may refer to a unit of execution flow executed within a process. Each thread may have an independent execution flow. Each thread may execute its own code and use resources of the electronic device (101). A thread may refer to a unit of work that can be independently executed in the processor (120).

[0073] In operation 420, the electronic device (101) may increase the counting number based on the user area daemon not being terminated and waiting for termination of at least one thread.

[0074] At operation 430, the electronic device (101) may determine that the daemon is unresponsive based on the counting number exceeding a specified level and may abort all ongoing requests through the file system.

[0075] According to one embodiment, the electronic device (101) may determine that the daemon's unresponsive state has been released based on all threads of the daemon being terminated.

[0076] In one embodiment, the electronic device (101) can determine whether the daemon is likely to become unresponsive. The electronic device (101) can increase a counting count based on the likelihood that the daemon is likely to become unresponsive. The electronic device (101) can determine whether the counting count exceeds a specified level, and if the counting count is below the specified level, wait a specified amount of time again and then determine again whether the daemon is likely to become unresponsive.

[0077] The electronic device (101) may increase a counting count based on the possibility that the daemon may become unresponsive, and then determine whether the counting count exceeds a specified level. The electronic device (101) may determine that the daemon is unresponsive based on the counting count exceeding the specified level, or may wait a specified time again based on the counting count being below the specified level, and then repeat the operation of determining whether the daemon may become unresponsive again.

[0078] The electronic device (101) according to this document does not simply determine that the daemon is in an unresponsive state if the kernel thread is running and the daemon's thread is not terminated after a specified period of time. The electronic device (101) according to this document can increase a counting count if the user area daemon is waiting for at least one thread while not being terminated, and then check again whether the user area daemon is in an unresponsive state. The electronic device (101) can determine that the daemon is in an unresponsive state if the user area daemon is not terminated and the counting count increases and reaches a certain level or higher.

[0079] Here, the counting count is set to increase when the daemon is waiting for at least one thread while not being terminated, but the conditions for increasing the counting count may vary depending on the settings. For example, the electronic device (101) may increase the counting count when the daemon is waiting for the completion of coredump of child threads. Coredump may refer to a memory dump file created when a process is terminated or crashed. Coredump is a type of file and may include at least one of information from the execution status of the process, memory contents, or stack information. Coredump may refer to a file created when a program is abnormally terminated. Coredump may record the state of the memory (130) at the time when the program is abnormally terminated. The electronic device (101) may use coredump to determine whether a specific thread has been abnormally terminated.

[0080] The electronic device (101) may determine that the request is not completed and increase the counting number if it is waiting for a coredump to be written for at least one thread.

[0081] According to one embodiment, the electronic device (101) may determine whether the daemon is likely to become unresponsive based on a specified period of time after executing a kernel thread. The electronic device (101) may control not to increase the counting number based on the probability that the daemon will become unresponsive. Based on the probability that the counting number is less than a specified level, the electronic device (101) may wait again for a specified period of time and repeat the operation of re-determining whether the daemon is likely to become unresponsive.

[0082] According to one embodiment, the electronic device (101) may be located in the user space and may include a daemon that accesses a file system based on a specified time period after executing a kernel thread and processes requests for input and output of files. In addition, the electronic device (101) may be located in the kernel space and may include a driver that transmits user input to the daemon and transmits the daemon's response to an application.

[0083] According to one embodiment, the electronic device (101) can determine that a thread has not been terminated for a specified period of time. The electronic device (101) can determine that at least one thread of the daemon performs self I / O based on a situation in which a request is transmitted from a daemon to a driver and a request must be transmitted back to the daemon to process the request received from the driver. Self I / O can refer to a situation in which a request is transmitted back to the daemon to perform the request transmitted from the daemon to the driver. That is, in a self I / O situation, the subject who requested input and output for a file and the subject who processes the request can be the same. This has been described in FIG. 3b.

[0084] According to one embodiment, the electronic device (101) determines that the daemon is likely to become unresponsive based on at least one thread of the daemon performing self I / O, and controls the counting number to increase.

[0085] According to one embodiment, the electronic device (101) may increase a counting count based on whether a daemon in the user space has not been terminated and is waiting for the termination of at least one thread. The electronic device (101) may determine whether the counting count exceeds a specified level, and, based on whether the counting count does not exceed the specified level, determine whether the daemon has been terminated in the user space after a specified period of time. The electronic device (101) may control the termination of a running kernel thread based on the termination of a daemon in the user space.

[0086] According to one embodiment, the electronic device (101) may increase a counting count based on whether the daemon in the user space has not been terminated and is waiting for the termination of at least one thread. The electronic device (101) may determine whether the counting count exceeds a specified level, and based on whether the counting count does not exceed the specified level, may determine whether the daemon has been terminated in the user space after a specified period of time. The electronic device (101) may increase the counting count based on whether the daemon in the user space has not been terminated and is waiting for the termination of at least one thread. Based on whether the counting count exceeds the specified level, the electronic device (101) may determine that the daemon is in an unresponsive state and may suspend all requests in progress through the file system. Based on whether all threads of the daemon have been terminated, the electronic device (101) may determine that the unresponsive state of the daemon has been released.

[0087] FIG. 5 is a flowchart illustrating a method for determining an unresponsive state by detecting the state of a daemon in an electronic device according to one embodiment.

[0088] The operations described through FIG. 5 can be implemented based on instructions that can be stored in a computer recording medium or memory (e.g., memory (130) of FIG. 1). The illustrated method (500) can be executed by the electronic device described above through FIGS. 1 to 4 (e.g., electronic device (101) of FIG. 1), and the technical features described above will be omitted below. The order of each operation of FIG. 5 can be changed, some operations can be omitted, and some operations can be performed simultaneously.

[0089] In operation 502, the electronic device (101) may execute a kernel thread under the control of a processor (e.g., processor (120) of FIG. 1).

[0090] A kernel thread can refer to a thread that runs within the operating system kernel. Kernel threads can be distinguished from threads that run in user space. Typically, kernel threads can have a relatively higher execution priority than user space threads. The kernel can refer to a part of the operating system. The kernel can manage computing resources, including the CPU, memory, files, and the network. User space can refer to the area where applications run by users reside. Applications (or programs) running in user space can access computing resources through interfaces provided by the kernel.

[0091] A thread may refer to a unit of execution flow executed within a process. Each thread may have an independent execution flow. Each thread may execute its own code and utilize the resources of the electronic device (101). A thread may refer to a unit of work capable of independent execution on the processor (120).

[0092] In operation 504, the electronic device (101) may execute a kernel thread and remain in a waiting state for a specified period of time. The specified period of time may be, for example, x seconds and may vary depending on the settings.

[0093] In operation 510, the electronic device (101) can determine whether the daemon has terminated after a specified period of time.

[0094] The electronic device (101) may terminate all operations (500) of FIG. 5 based on the determination that the daemon has terminated after a specified period of time. (Operation 510-No)

[0095] In operation 520, the electronic device (101) may determine whether the processor (120) is waiting for termination of at least one thread based on the daemon not being terminated even after a specified period of time has elapsed. (Operation 510-Yes) A ​​thread may mean a work unit that can be independently executed in the processor (120).

[0096] At operation 522, the electronic device (101) may increment the counting number based on whether the processor (120) is waiting for termination of at least one thread (operation 520-Yes).

[0097] In operation 530, the electronic device (101) can determine whether the total number of counts is greater than or equal to a specified level (e.g., a first level). The first level may be a unit representing the number of counts, and the specific number may vary depending on the setting.

[0098] At operation 532, the electronic device (101) may terminate all requests between the kernel and the user space based on the count being greater than or equal to a certain number (operation 530 - Yes). The request may mean, for example, a request for a task related to reading or writing a file.

[0099] In one embodiment, the electronic device (101) may return to operation 504 and remain in a waiting state for a specified period of time based on the total count being less than a specified level (e.g., a first level) (operation 530 - No). The electronic device (101) may then return to operation 510 to determine whether the daemon has terminated after the specified period of time has elapsed.

[0100] FIG. 6 is a flowchart illustrating a method for determining a non-responsive state using ping and a timer in an electronic device according to one embodiment.

[0101] The operations described through FIG. 6 can be implemented based on instructions that can be stored in a computer recording medium or memory (e.g., memory (130) of FIG. 1). The illustrated method (600) can be executed by the electronic device described above through FIGS. 1 to 5 (e.g., electronic device (101) of FIG. 1), and the technical features described above will be omitted below. The order of each operation of FIG. 6 can be changed, some operations can be omitted, and some operations can be performed simultaneously.

[0102] In operation 610, the electronic device (101) can check whether there is a pending request under the control of a processor (e.g., processor (120) of FIG. 1). The request may mean, for example, a request for a task related to reading or writing a file. The requests may be stored in a pending queue (e.g., pending queue (201) of FIG. 2A). The electronic device (101) can check whether there is a pending request by checking the pending queue (201).

[0103] At step 612, the electronic device (101) may set a timer function for a pending request based on whether there is a pending request (step 610 - Yes). The time of the timer may be, for example, y seconds and may vary depending on the setting.

[0104] In operation 614, the electronic device (101) may generate a request for the purpose of performing a ping based on the absence of a request in a standby state (operation 610 - No). The electronic device (101) may set a timer function for the request for the purpose of performing a ping.

[0105] In operation 620, the electronic device (101) can check whether a request for the purpose of performing a pending request or ping has been completed for a set timer time (e.g., y seconds).

[0106] At operation 622, the electronic device (101) may cancel the set timer based on the request being completed during the set timer time (operation 620 - Yes).

[0107] At operation 624, the electronic device (101) may determine that the file system is normal based on the set timer being canceled.

[0108] In operation 630, the electronic device (101) may execute a timer callback function based on whether the request is completed within the set time of the timer (operation 620 - No). The timer callback function may refer to a function that is automatically called by the processor (120) when a specific event occurs. For example, the electronic device (101) may execute a function that performs at least one function based on the passage of time specified by the timer. The electronic device (101) may use the timer callback function to execute at least one function.

[0109] At operation 632, the electronic device (101) may determine that the daemon is unresponsive based on the execution of the timer callback function and terminate the daemon.

[0110] At operation 634, the electronic device (101) may abort any requests being processed by the daemon based on the determination that the daemon is unresponsive.

[0111] According to one embodiment, the electronic device (101) may set a timer having a first preset period for a pending request. The first period may vary depending on the setting. The electronic device (101) may cancel the timer based on completion of the pending request within the first period and determine that the file system of the electronic device (101) is normal. The electronic device (101) may determine that the daemon is unresponsive based on incomplete completion of the pending request within the first period and may stop all requests in progress through the file system of the electronic device.

[0112] According to one embodiment, the electronic device (101) may generate a request for performing a ping using the processor (120) based on the absence of a pending request. The electronic device (101) may set a timer having a first predetermined period for the request for performing a ping. The first period may vary depending on the setting. The electronic device (101) may cancel the timer based on the completion of the pending request within the first period, and determine that the file system of the electronic device is normal.

[0113] According to one embodiment, the electronic device (101) may set a timer having a first predetermined period for a request for the purpose of performing a ping. The electronic device (101) may periodically transmit a ping between the driver and the daemon and check the communication status within the file system through a response thereto. The electronic device (101) may determine that the daemon is unresponsive based on the fact that a pending request is not completed within the first period, and may stop all requests in progress through the file system of the electronic device (101).

[0114] According to one embodiment, the electronic device (101) may set a timer having a first preset period for a pending request, and execute a timer callback function based on the expiration of the first period. Based on the execution of the timer callback function, the electronic device (101) may determine that the daemon is unresponsive, and may stop all requests in progress through the file system of the electronic device (101). The timer callback function may refer to a function that is automatically called by the processor (120) when a specific event occurs. For example, the electronic device (101) may execute a function that performs at least one function based on the elapse of a time specified by the timer. The electronic device (101) may use the timer callback function to execute at least one function.

[0115] An electronic device may include at least one processor that stores instructions, a memory that includes one or more storage media, and processing circuitry. The instructions, when individually or collectively executed by the at least one processor, may control the electronic device to execute a kernel thread using the processor in a kernel space, determine whether a daemon has terminated in a user space after a specified period of time has elapsed after the execution of the kernel thread, increase a counting count based on the user space daemon not having terminated but is waiting for termination of at least one thread, determine that the daemon is in a non-responsive state based on the counting count exceeding a specified level, abort all requests in progress through the file system, and determine that the non-responsive state of the daemon has been released based on the termination of all threads of the daemon.

[0116] An electronic device may include at least one processor storing instructions, a memory including one or more storage media, and processing circuitry. The instructions, when individually or collectively executed by the at least one processor, may be configured to set a timer having a first predetermined period for a pending request, cancel the timer based on completion of the pending request within the first period, determine that a file system of the electronic device is normal, determine that a daemon is unresponsive based on incomplete completion of the pending request within the first period, and control to stop all pending requests through the file system of the electronic device.

Claims

1. In electronic devices, A memory that stores instructions and includes one or more storage media; At least one processor comprising processing circuitry, The above instructions, when individually or collectively executed by the at least one processor, cause the electronic device to Execute a kernel thread using the above processor in the kernel space, After a specified amount of time has passed since the kernel thread was executed, the user space checks whether the daemon has terminated. Increment the count based on the fact that the above user space daemon is not terminating and is waiting for the termination of at least one thread, Based on the above count exceeding a specified level, the daemon is determined to be unresponsive and all requests in progress through the file system are aborted; An electronic device that controls the determination that the unresponsive state of the daemon has been released based on the termination of all threads of the daemon.

2. In paragraph 1, The above instructions, when executed by the processor, cause the electronic device to Check if the above daemon is likely to become unresponsive, Increment the count based on the possibility that the above daemon may become unresponsive, Check if the above counting number exceeds the specified level, After waiting for the specified time again based on the above count being below the specified level, it checks again whether the above daemon is likely to become unresponsive. Increment the count based on the possibility that the above daemon may become unresponsive, Again, check if the above counting number exceeds the specified level, The daemon is determined to be unresponsive based on the above count exceeding a specified level, or An electronic device that controls an operation to wait a specified period of time again based on the counting number being below a specified level and then to check again whether the daemon is likely to become unresponsive.

3. In paragraph 1, The above instructions, when executed by the processor, cause the electronic device to After executing the kernel thread, it checks whether the daemon is likely to become unresponsive based on the specified time elapsed. Control not to increase the counting number based on the possibility that the above daemon will become unresponsive, An electronic device that controls an operation to wait a specified period of time again based on the counting number being below a specified level and then to check again whether the daemon is likely to become unresponsive.

4. In paragraph 1, The above electronic device A daemon that processes requests for input and output of files by accessing the file system based on a specified time elapsed after executing a thread; and A driver is included that transmits user input to the daemon and transmits the daemon's response to the application, wherein the daemon is located in the user space and the driver is located in the kernel space. The above instructions, when executed by the processor, cause the electronic device to It is determined that the daemon is likely to become unresponsive based on the fact that the threads of the daemon do not terminate for a specified period of time and at least one of the threads of the daemon is performing self I / O, Controlling the increment of the counting count based on the determination that the above daemon is likely to become unresponsive; The above self I / O is In response to a user request for an application from the above daemon, check whether the application has permission to open the file, An electronic device that processes a user request by transmitting the user request to the driver when the application has the authority to open a file.

5. In paragraph 1, The above instructions, when executed by the processor, cause the electronic device to Increment the count based on the fact that the above user space daemon is not terminating and is waiting for the termination of at least one thread, Check if the above counting number exceeds the specified level, After a specified amount of time, the daemon is checked in user space to see if it has been terminated, based on the above count not exceeding the specified level. An electronic device that controls the termination of a kernel thread running based on the termination of the daemon in the user area.

6. In paragraph 5, The above instructions, when executed by the processor, cause the electronic device to Increment the count based on the fact that the above user space daemon is not terminating and is waiting for the termination of at least one thread, Check if the above counting number exceeds the specified level, After a specified amount of time, the daemon is checked in user space to see if it has been terminated, based on the above count not exceeding the specified level. Increment the count based on the fact that the above user space daemon is not terminating and is waiting for the termination of at least one thread, Based on the above count exceeding a specified level, the daemon is determined to be unresponsive and all requests in progress through the file system are aborted; An electronic device that controls the determination that the unresponsive state of the daemon has been released based on the termination of all threads of the daemon.

7. In electronic devices, Memory that stores instructions; comprising a processor operatively connected to said memory, The above instructions, when executed by the processor, cause the electronic device to Set a timer with a preset first period for pending requests, Cancel the timer based on the completion of the request in the pending state within the first period, It is determined that the file system of the above electronic device is normal, The daemon is determined to be unresponsive based on the fact that the pending request is not completed within the above first period, An electronic device that controls the file system of said electronic device to stop all ongoing requests.

8. In paragraph 7, The above instructions, when executed by the processor, cause the electronic device to Generate a request for the purpose of performing a ping using the processor based on the absence of a pending request, Setting a timer having a first predetermined period for a request for the purpose of performing a ping, Cancel the timer based on the completion of the request in the pending state within the first period, An electronic device that controls the file system of the electronic device to determine that it is normal.

9. In paragraph 8, The above instructions, when executed by the processor, cause the electronic device to Setting a timer having a first predetermined period for a request for the purpose of performing a ping, The daemon is determined to be unresponsive based on the fact that the pending request is not completed within the first period, An electronic device that controls the file system of said electronic device to stop all ongoing requests.

10. In paragraph 7, The above instructions, when executed by the processor, cause the electronic device to Set a timer with a preset first period for pending requests, Executes a timer callback function based on the expiration of the first period, The daemon is determined to be unresponsive based on the execution of the timer callback function, An electronic device that controls the file system of said electronic device to stop all ongoing requests.

11. In a computer-readable non-transitory storage medium storing one or more programs including instructions executable by a processor of an electronic device, Executes a kernel thread using the above processor in the kernel space, After a specified amount of time has passed since the kernel thread was executed, the daemon is checked in user space to see if it has terminated. Increment the count based on the fact that the above user space daemon is not terminating and is waiting for the termination of at least one thread, Based on the above count exceeding a specified level, the daemon is determined to be unresponsive and all requests in progress through the file system are aborted; A computer-readable non-transitory storage medium that controls the determination that the unresponsive state of the daemon is lifted based on the termination of all threads of the daemon.

12. In paragraph 11, When the above instructions are executed by the processor of the electronic device, the electronic device Check if the above daemon is likely to become unresponsive, Increment the count based on the possibility that the above daemon may become unresponsive, Check if the above counting number exceeds the specified level, After waiting for the specified time again based on the above count being below the specified level, it checks again whether the above daemon is likely to become unresponsive. Increment the count based on the possibility that the above daemon may become unresponsive, Again, check if the above counting number exceeds the specified level, The daemon is determined to be unresponsive based on the above count exceeding a specified level, or A computer-readable non-transitory storage medium that controls the operation of waiting a specified time again based on the above counting number being below a specified level and then checking again whether the daemon is likely to become unresponsive.

13. In paragraph 11, When the above instructions are executed by the processor of the electronic device, the electronic device After executing the kernel thread, it checks whether the daemon is likely to become unresponsive based on the specified time elapsed. Control not to increase the counting number based on the possibility that the above daemon will become unresponsive, A computer-readable non-transitory storage medium that controls the operation of waiting a specified time again based on the above counting number being below a specified level and then checking again whether the daemon is likely to become unresponsive.

14. In paragraph 11, The above electronic device A daemon that processes requests for input and output of files by accessing the file system based on a specified time elapsed after executing a thread; and A driver is included that transmits user input to the daemon and transmits the daemon's response to the application, wherein the daemon is located in the user space and the driver is located in the kernel space. When the above instructions are executed by the processor of the electronic device, the electronic device It is determined that the daemon is likely to become unresponsive based on the fact that the threads of the daemon do not terminate for a specified period of time and at least one of the threads of the daemon is performing self I / O, Controlling the increment of the counting count based on the determination that the above daemon is likely to become unresponsive; The above self I / O is In response to a user request for an application from the above daemon, check whether the application has permission to open the file, A computer-readable non-transitory storage medium that refers to a situation in which a user request is processed by transmitting the user request to the driver when the application has the authority to open a file.

15. In paragraph 11, When the above instructions are executed by the processor of the electronic device, the electronic device Increment the count based on the fact that the above user space daemon is not terminating and is waiting for the termination of at least one thread, Check if the above counting number exceeds the specified level, After a specified amount of time, the daemon is checked in user space to see if it has been terminated, based on the above count not exceeding the specified level. A computer-readable non-transitory storage medium that controls terminating a kernel thread running based on the termination of the daemon in the user area.

Images