File system storage allocation based on regions of a memory device

Abstract

The present application relates to file system storage allocation based on regions of a memory device. An example method involves a host system performing the following operations: receiving region characteristic data from a memory subsystem including a memory device, wherein the memory device includes a plurality of regions and wherein the region characteristic data includes one or more locations in the memory device corresponding to the plurality of regions; identifying, by the host system, a write request including file system data for a file system; determining, by the host system, whether the file system data is associated with at least one of the plurality of regions; allocating, by the host system, storage units in a region based on the region characteristic data; and providing, by the host system, the locations of the storage units to the memory subsystem to store the file system data on the memory device.

Description

Technical Field

[0001] Embodiments of the present disclosure relate generally to memory subsystems, and more particularly, to file system allocation based on regions of memory devices. Background Art

[0002] The memory subsystem may include one or more memory devices that store data. The memory devices may be, for example, non-volatile memory devices and volatile memory devices. Generally speaking, the host system may utilize the memory subsystem to store data at the memory devices and retrieve data from the memory devices. Summary of the Invention

[0003] In one aspect, the present application provides a method comprising: receiving, by a host system, region characteristic data from a memory subsystem comprising a memory device, wherein the memory device comprises a plurality of regions, and wherein the region characteristic data comprises one or more locations in the memory device corresponding to the plurality of regions; identifying, by the host system, a write request comprising file system data for a file system; determining, by the host system, whether the file system data is associated with at least one of the plurality of regions; allocating, by the host system, a storage unit in a region based on the region characteristic data; and providing, by the host system, the location of the storage unit to the memory subsystem to store the file system data on the memory device.

[0004] On the other hand, the present application further provides a system comprising: a memory device; and a processing device operatively coupled to the memory device to perform operations comprising: configuring the memory device using a region namespace having multiple regions, wherein the multiple regions include a region storing file system data of a file system; transmitting region characteristic data to a host system, wherein the region characteristic data includes a write pointer for the region; transmitting a copy of the file system data stored in the region to the host system; receiving a request to allocate a storage unit at a location selected by the host system, wherein the storage unit is in the multiple regions; receiving an updated copy of the file system data, wherein the updated copy is maintained by the host system and includes changes; and storing the updated copy of the file system data at the location received from the host system.

[0005] On the other hand, the present application further provides a non-transitory computer-readable medium storing instructions, which, when executed by a processing device, causes the processing device to perform operations including: receiving region characteristic data from a memory subsystem including a memory device, wherein the memory device includes multiple regions, and wherein the region characteristic data includes one or more locations in the memory device corresponding to the multiple regions; identifying a write request including file system data for a file system; determining whether the file system data is associated with at least one of the multiple regions; allocating a storage unit in a region based on the region characteristic data; and providing the location of the storage unit to the memory subsystem to store the file system data on the memory device. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] The present disclosure will be more fully understood from the detailed description given below and the accompanying drawings of various embodiments of the present disclosure. However, the accompanying drawings should not be considered to limit the present disclosure to specific embodiments, but are only for explanation and understanding.

[0007] Figure 1 An example computing system including a host system and a memory subsystem is shown according to some embodiments of the present disclosure.

[0008] Figure 2 According to some embodiments of the present disclosure Figure 1 Detailed block diagram of the computing system.

[0009] Figure 3 According to some embodiments of the present disclosure Figure 2 Detailed block diagram of the storage allocator of the file system.

[0010] Figure 4 A flowchart of a method for file system storage allocation based on regions of a memory device according to some embodiments of the present disclosure is provided.

[0011] Figure 5 Another flow chart of a method for file system storage allocation based on regions of a memory device according to some embodiments of the present disclosure.

[0012] Figure 6 A diagram illustrating a computing system including associating a stream identifier (ID) with a data type and a stream ID with a specific region of a host file system according to some embodiments of the present disclosure.

[0013] Figure 7 is a block diagram of an example computer system in which embodiments of the present disclosure may operate. DETAILED DESCRIPTION

[0014] Various aspects of the present disclosure are directed to file system storage allocation based on regions of a memory subsystem. The memory subsystem may be a storage device, a memory module, or a combination of a storage device and a memory module. Figure 1 Examples of storage devices and memory modules are described. In general, a host system can utilize a memory subsystem that includes one or more memory devices that store data. The host system can provide data to be stored at the memory subsystem and can request data to be retrieved from the memory subsystem.

[0015] Memory subsystems and memory devices can store data from a host system in a storage medium, such as an integrated circuit (IC) die having individually addressable memory cells that store data. Processing in some current memory subsystems is often performed through random allocations to memory devices and in small increments of data, such as four kilobytes (KB). These random allocations of pages or blocks of data include non-sequential and / or random writes to the memory devices. This practice results in high costs in memory, such as dynamic random access memory (DRAM), static random access memory (SRAM), or persistent memory, for storing mapping data structures that track the logical-to-physical (LTP) address mapping between the IC die's logical block address (LBA) space and its physical address space. For example, mapping overhead is approximately gigabytes (GB) per terabyte (TB) of host-addressable media, and thus, a 16TB solid-state drive (SSD) requires a substantial 16GB of memory mapping overhead. Furthermore, periodic snapshots and logging are performed to preserve the mapping data structures throughout shutdowns and unexpected power failures. This adds additional write overhead to the IC die and performance loss.

[0016] Storage stacking is a process being modified to exploit the efficiency of sequential input-output (IO) memory devices. For example, storage stacks are included in file system group data by location (e.g., by thread, process, or application) and write data sequentially to the storage device. The file system can then write the differently located data to the storage device as parallel sequential streams, each stream with its own location. Reference to location can refer to either temporal location or spatial location. Data with temporal location is data that the processor tends to access repeatedly at the same memory location within a short period of time, such as data that is written, overwritten, and adjusted at approximately the same time. Data with spatial location captures the tendency that when a memory device references a particular memory location at a specific time, it is likely that the memory device has recently referenced nearby memory locations. In this case, the processor can attempt to determine the size and shape of the area surrounding the current reference to prepare for faster access for subsequent references. Reference to sequential location is a special case of spatial location that occurs when data elements are arranged and accessed linearly (e.g., when iterating through the elements of a one-dimensional array).

[0017] When writing data with alignment sequentially, for simplicity, the data is written to groups of memory cells, also referred to as zones, where each zone can store multiple physical blocks of data. Therefore, mappings can be recorded at a higher granularity (megabytes rather than kilobytes) to map specific data groups to zones in the LBA space, significantly reducing the amount of recorded metadata. The mapping space associated with the LBA space at this granularity can be referred to as a zone name space (ZNS), and a memory device written in this manner is referred to as a ZNS memory device. In one example, a data group consists of multiple data blocks with temporal and / or spatial alignment, where each data block corresponds to a physical block (e.g., an erase unit) of the IC die. In one embodiment, the size of a physical block of a memory device can be approximately 16 megabytes (MB). A group (or zone) of memory cells can be at least two to four times (or more) the size of a physical block. Thus, a zone can store at least 64MB of data (e.g., 64MB, 128MB, 256MB, 512MB, or more), each of which is significantly larger than four kilobytes (KB).

[0018] In some host operating systems, a file system handles the management of files from the operating system, files from applications running on the operating system, and metadata generated by the file system, with the goal of organizing the files and allocating the space in the memory device necessary to write the files and metadata as they are generated. The file system of some host operating systems (e.g., Linux, Unix, etc.) allocates block groups (e.g., file system storage units) to a range of physical addresses on the memory device where the block groups are stored. A file may include file data, file metadata (e.g., inodes (index sections)), directory structures, free space managers, etc., as well as other data structures (or objects) capable of encapsulating data / metadata and writing to the memory device, which will be discussed in more detail. The file system typically allocates certain types of block groups to a specific range of physical addresses on the memory device based on whether the block group contains data or metadata, and attempts to prevent intermixing of data and metadata within these specific ranges of physical addresses.

[0019] Conventional file systems (e.g., BTRFS) are not well-suited for allocating block groups mapped to zones (e.g., where the block group is the size of the zone) or for sequential writes to zones, as is done within zones on ZNS-managed memory devices. To date, sequential writes to ZNS-managed memory devices have been managed at the memory device level by a memory subsystem controller (e.g., which acts as an intermediary between the host's file system and the storage device). Management within the memory subsystem controller adds a level of complexity, including LTP address mapping, recording metadata, and corresponding resource requirements for handling non-sequential IO writes, even though the majority of IO writes are sequential write operations.

[0020] At least some aspects of the present disclosure address the above and other deficiencies by configuring a host system (e.g., a file system of a host operating system) with the ability to more efficiently store data for file system objects in regions of a memory device. Some aspects of the present disclosure additionally or alternatively configure the host system with the ability to associate one or more regions with specific data types and allocate storage space (e.g., a group of memory cells) in each region to store these specific data types. In this manner, the file system manages and stores the allocated regions using file / data structures within the memory device for ZNS management of the memory device.

[0021] Furthermore, copy-on-write (COW) management of storage devices is generally best suited for sequential writes because after writing data, it is not overwritten (e.g., the data is never overwritten). More specifically, COW is a resource management technique in computer programming that efficiently performs duplication or copy operations on modifiable resources in memory. If a resource is copied but not modified, a new resource does not need to be created; the resource can be shared between the copy and the original. In the case of file systems that write sequentially to storage devices, using COW management to perform this operation is more efficient. For example, similar types of data may be written as a group and, therefore, may also eventually be overwritten elsewhere as a group until they become obsolete and undergo garbage collection (including erasure). Therefore, writing data of the same data type as a group can minimize garbage collection and reduce write amplification. Furthermore, in some embodiments, the kernel of the host operating system includes device mapping logic that can directly write file system data to the physical addresses of individual regions and thus map logical addresses to the physical addresses of sequentially written regions, transferring the need for this mapping to the memory subsystem controller.

[0022] Advantages of the present disclosure include, but are not limited to, significantly minimizing garbage collection and reducing write amplification by sequentially writing data of similar data types in groups by region. Furthermore, load balancing writes across multiple regions for different data types enables predictable write performance, where writes are often a bottleneck in current file systems. In one example, the operations of organizing data type files into streams and directing these streams to be written to identified regions are performed at the host's file system, including ZNS device mapping capabilities performed by the kernel of the host operating system. Other advantages include significantly reducing mapping overhead and reducing periodic snapshots and logging that would otherwise be performed to maintain mapping data structures in the event of a power outage / shutdown. Those skilled in the art will appreciate the additional advantages of memory allocation and mapping of memory devices discussed below.

[0023] Figure 1 An example computing system 100 is shown that includes a memory subsystem 110 and a host system 120 according to some embodiments of the present disclosure. The memory subsystem 110 may include media such as one or more non-volatile memory devices (e.g., memory device 130), one or more volatile memory devices (e.g., memory device 140), or a combination thereof. Each memory device 130 or 140 may be one or more memory components.

[0024] The memory subsystem 110 may be a storage device, a memory module, or a combination of a storage device and a memory module. Examples of storage devices include solid-state drives (SSDs), flash drives, universal serial bus (USB) flash drives, embedded multimedia controller (eMMC) drives, universal flash storage (UFS) drives, secure digital (SD) cards, and hard disk drives (HDDs). Examples of memory modules include dual inline memory modules (DIMMs), small outline DIMMs (SO-DIMMs), and various types of non-volatile dual inline memory modules (NVDIMMs).

[0025] The computing system 100 can be a computing device, such as a desktop computer, a laptop computer, a network server, a mobile device, a vehicle (e.g., an airplane, drone, train, car, or other transportation vehicle), an Internet of Things (IoT)-enabled device, an embedded computer (e.g., an embedded computer included in a vehicle, industrial equipment, or a networked commercial device), or such a computing device that includes a memory and a processing device.

[0026] The computing system 100 may include a host system 120 coupled to one or more memory subsystems 110. In some embodiments, the host system 120 is coupled to memory subsystems 110 of different types. Figure 1An example of a host system 120 coupled to one memory subsystem 110 is shown. As used herein, "coupled to" or "coupled with" generally refers to a connection between components or devices, which can be an indirect communication connection or a direct communication connection (e.g., without intervening components or devices), whether wired or wireless, including connections such as electrical connections, optical connections, magnetic connections, etc.

[0027] The host system 120 may include a processor chipset and a software stack executed by the processor chipset. The processor chipset may include one or more cores, one or more caches, a memory controller (e.g., an NVDIMM controller), and a storage protocol controller (e.g., a PCIe controller, a SATA controller). The host system 120 uses the memory subsystem 110, for example, to write data to the memory subsystem 110 and read data from the memory subsystem 110.

[0028] The host system 120 can be coupled to the memory subsystem 110 via a physical host interface that can communicate on a system bus. Examples of the physical host interface include, but are not limited to, a Serial Advanced Technology Attachment (SATA) interface, a Peripheral Component Interconnect Express (PCIe) interface, a Universal Serial Bus (USB) interface, Fibre Channel, Serial Attached SCSI (SAS), a Double Data Rate (DDR) memory bus, a Small Computer System Interface (SCSI), a Dual In-line Memory Module (DIMM) interface (e.g., a DIMM socket interface supporting Double Data Rate (DDR)), an Open NAND Flash Interface (ONFI), Double Data Rate (DDR), Low Power Double Data Rate (LPDDR), or any other interface. The physical host interface can be used to transfer data between the host system 120 and the memory subsystem 110. When the memory subsystem 110 is coupled to the host system 120 via a physical host interface (e.g., a PCIe bus), the host system 120 can further utilize an NVM Express (NVMe) interface to access components (e.g., the memory device 130). The physical host interface may provide an interface for transferring control, address, data, and other signals between the memory subsystem 110 and the host system 120 . Figure 1 Memory subsystem 110 is shown as an example. In general, host system 120 can access multiple memory subsystems via the same communication connection, multiple separate communication connections, and / or a combination of communication connections.

[0029] Memory devices 130 and 140 may include any combination of different types of non-volatile memory devices and / or volatile memory devices. Volatile memory devices (e.g., memory device 140) may be, but are not limited to, random access memory (RAM), such as dynamic random access memory (DRAM) and synchronous dynamic random access memory (SDRAM).

[0030] Some examples of non-volatile memory devices (e.g., memory device 130) include NAND-type flash memory and write-in-place memory, such as three-dimensional cross-point ("3D cross-point") memory. A cross-point array of non-volatile memory can perform bit storage based on changes in bulk resistance in conjunction with a stackable cross-grid data access array. In addition, in contrast to many flash-based memories, cross-point non-volatile memory can perform write-in-place operations, where non-volatile memory cells can be programmed without first erasing the non-volatile memory cells. NAND-type flash memory includes, for example, two-dimensional NAND (2D NAND) and three-dimensional NAND (3D NAND).

[0031] Each of the memory devices 130 may include one or more memory cell arrays. One type of memory cell, such as a single-level cell (SLC), may store one bit per cell. Other types of memory cells, such as multi-level cells (MLC), triple-level cells (TLC), quad-level cells (QLC), and penta-level cells (PLC), may store multiple bits per cell. In some embodiments, each memory device 130 may include one or more memory cell arrays, such as SLC, MLC, TLC, QLC, PLC, or any combination thereof. In some embodiments, a particular memory device may include an SLC portion of memory cells, as well as an MLC portion, a TLC portion, a QLC portion, or a PLC portion. The memory cells of the memory devices 130 may be grouped into pages, which may refer to logical units of a memory device for storing data. For some types of memory (e.g., NAND), pages may be grouped to form blocks.

[0032] Although nonvolatile memory components such as a 3D cross-point array of nonvolatile memory cells and NAND-type flash memory (e.g., 2D NAND, 3D NAND) are described, the memory device 130 may be based on any other type of nonvolatile memory, such as read-only memory (ROM), phase-change memory (PCM), selectable memory, other chalcogenide-based memories, ferroelectric transistor random access memory (FeTRAM), ferroelectric random access memory (FeRAM), magnetic random access memory (MRAM), spin transfer torque (STT)-MRAM, conductive bridging RAM (CBRAM), resistive random access memory (RRAM), oxide-based RRAM (OxRAM), NOR (NOR) flash memory, and electrically erasable programmable read-only memory (EEPROM).

[0033] The memory subsystem controller 115 (or, for simplicity, controller 115) can communicate with the memory device 130 to perform operations, such as reading data, writing data, or erasing data at the memory device 130, as well as other such operations. The memory subsystem controller 115 can include hardware, such as one or more integrated circuits and / or discrete components, buffer memory, or a combination thereof. The hardware can include digital circuitry with dedicated (i.e., hard-coded) logic to perform the operations described herein. The memory subsystem controller 115 can be a microcontroller, dedicated logic circuitry (e.g., a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), etc.), or other suitable processor.

[0034] The memory subsystem controller 115 may include a processing device including one or more processors (e.g., processor 117) configured to execute instructions stored in local memory 119. In the example shown, the local memory 119 of the memory subsystem controller 115 includes embedded memory configured to store instructions for executing various processes, operations, logic flows, and routines that control the operation of the memory subsystem 110, including handling communications between the memory subsystem 110 and the host system 120.

[0035] In some embodiments, local memory 119 may include memory registers that store memory pointers, fetched data, etc. Local memory 119 may also include read-only memory (ROM) for storing microcode. Figure 1 The example memory subsystem 110 in FIG. 1 has been shown as including a memory subsystem controller 115, but in another embodiment of the present disclosure, the memory subsystem 110 does not include a memory subsystem controller 115 and may rely on external control (e.g., provided by an external host or by a processor or controller separate from the memory subsystem).

[0036] In general, the memory subsystem controller 115 may receive commands or operations from the host system 120 and convert the commands or operations into instructions or appropriate commands to achieve the desired access to the memory device 130. The memory subsystem controller 115 may be responsible for other operations such as wear leveling operations, garbage collection operations, error detection and error correction code (ECC) operations, encryption operations, cache operations, and address conversion between logical block addresses (e.g., logical block addresses (LBAs), namespaces) and physical addresses (e.g., physical block addresses) associated with the memory device 130. The memory subsystem controller 115 may also include host interface circuitry to communicate with the host system 120 via a physical host interface. The host interface circuitry may convert commands received from the host system into command instructions to access the memory device 130, and convert responses associated with the memory device 130 into information for the host system 120.

[0037] The memory subsystem 110 may also include additional circuitry or components not shown. In some embodiments, the memory subsystem 110 may include a cache or buffer (e.g., DRAM) and address circuitry (e.g., row decoders and column decoders) that may receive addresses from the memory subsystem controller 115 and decode the addresses to access the memory device 130.

[0038] In some embodiments, memory device 130 includes a local media controller 135 that operates in conjunction with memory subsystem controller 115 to perform operations on one or more memory cells of memory device 130. An external controller (e.g., memory subsystem controller 115) can externally manage memory device 130 (e.g., perform media management operations on memory device 130). In some embodiments, memory subsystem 110 is a managed memory device, which is a raw memory device 130 with on-die control logic (e.g., local media controller 135) and a controller for memory management within the same memory device package (e.g., memory subsystem controller 115). An example of a managed memory device is a managed NAND (MNAND) device.

[0039] The computing system 100 includes a file system 124 in a host system 120 that is configured with the file organization and storage allocation functionality discussed herein throughout the figures. In some embodiments, the host system 120 includes at least a portion of the file organization and storage allocation functionality. In other embodiments, or in combination, the controller 115 and / or processing device of the host system 120 includes at least a portion of the file organization and storage allocation functionality. For example, the controller and processing device (processor) of the host system 120 may be configured to execute instructions stored in memory for performing operations of the file organization and storage allocation functionality described herein.

[0040] Figure 2 Detailed block diagram of a computing system 100 including a file system that uses multiple regions of a memory subsystem to more efficiently store data. In the example shown, a host system 120 includes a file system 124, one or more applications 225, and a memory subsystem 110 including multiple regions 232A-232Z spread across one or more memory devices 130A-130Z.

[0041] The file system 124 can manage the storage and retrieval of data from the memory subsystem 110. The file system 124 can include data structures and rules for organizing data and can involve separating data into individually identifiable and accessible storage units. The file system 124 can be integrated into the kernel, device drivers, applications, other parts of the operating system 220, or a combination thereof. The file system 124 can be executed as one or more system processes (e.g., kernel processes), user processes (e.g., application processes), or a combination thereof.

[0042] The file system 124 may include multiple layers, and the multiple layers may include a logical file system (e.g., a logical layer), a virtual file system (e.g., a virtual layer), a physical file system (e.g., a physical layer), or other layers. The logical file system may manage interactions with application programs 225 and may provide an application programming interface (e.g., file system API 222) that exposes file system operations (e.g., open, close, create, delete, read, write, execute) to other computer programs. The logical layer of the file system 124 may manage security and permissions and maintain open file table entries and per-process file descriptors. The logical file system may pass requested operations (e.g., write requests) to one or more other layers for processing. The virtual file system may enable the operating system 220 to support multiple concurrent instances of the physical file system, each of which may be referred to as a file system implementation. The physical file system may manage the physical operations of storage devices (e.g., memory subsystem 110). The physical file system may handle buffering and manage main memory and may be responsible for the physical placement of storage units in specific locations on memory devices 130A-130Z. The physical file system may include device mapping logic 228 and may interact with a device driver or with a channel to interact with the memory subsystem 110. One or more of the file system layers may be explicitly separated or may be combined together to store file system data 224.

[0043] File system data 224 may be any data associated with file system 124 and may include data received by file system 124 or data generated by file system 124. File system data 224 may represent data of one or more external file system objects, internal file system objects, or a combination thereof. External file system objects may be file system objects that are externally accessible by a computer program (e.g., application 225) using file system API 222. External file system objects may include files (e.g., file data and metadata), directories (e.g., folders), links (e.g., soft links, hard links), or other objects. Internal file system objects may be file system objects that remain internal to the file system and are not accessible using file system API 222. Internal file system objects may include storage tree objects (e.g., extent map, extent tree, block tree), stream objects (e.g., stream identifiers), file group data (e.g., file-like groups), storage units, block groups, extents, or other internal data structures.

[0044] Each file system object may be associated with object data and object metadata. The object data may be the content of the object (e.g., file data), and the object metadata may be information about the object (e.g., file metadata). The object metadata may indicate attributes of the object, such as a storage location (e.g., region, block group, storage unit), a data source (e.g., stream, application, user), a data type (e.g., text, image, audio, video), a size (e.g., file size, directory size), a time (e.g., creation time, modification time, access time), ownership (e.g., user ID, group ID), permissions (e.g., read, write, execute), a file system location (e.g., parent directory, absolute path, local path), other attributes, or a combination thereof. In one example, the file system data 224 may include data for a new file, and the new file may include file data and file metadata. The file data may include the content of the file (e.g., image content, audio content), and the file metadata may include one or more attributes of the content (e.g., an identifier corresponding to region z, stream s, and / or application a).

[0045] Object data and object metadata (e.g., attributes, tree nodes) may be stored together in the same data structure at the same storage location, or may be stored separately in different data structures at different storage locations. For example, the file system 124 may store object metadata in an index node (e.g., an index section) data structure, and the index node data structure may have one or more pointers to the object data. An index section may be a data structure that describes a file system object in a Unix-style file system. Each index section may indicate the attributes and storage location (e.g., block address) of the data for the file system object. A directory may be represented as an "index section" and may contain its own entry, its parent entry (e.g., a parent directory), and each of its child entries (e.g., a subdirectory or file). The file system 124 may store file system data 224 as one or more storage units 226.

[0046] Storage units 226 may be contiguous or non-contiguous portions of file system data to be stored in a memory device. A storage unit may be referred to as a file system storage unit and may be of any size (e.g., 4KB, 128KB, 16MB, 128MB, 1GB), and the size may or may not be based on the size (e.g., an integer multiple) of one or more memory storage units (e.g., a cell, block, page, region, die, device, or subsystem). File system 124 may use fixed sizes (e.g., constant or static sizes) for storage units, where all storage units may be the same size, or may use variable sizes (e.g., resizable or dynamic sizes), where storage units used by file system 124 may be of different sizes. The size of a storage unit may be determined (e.g., selected or detected) by storage allocator 227, file system 124, host system 120, memory subsystem 110, memory device 130, other entities, or a combination thereof. The size of storage unit 226 may be determined by an entity before, during, or after development, manufacturing, installation, initialization, configuration, formatting, other events, or a combination thereof. In one example, each of the storage units 226 can be the same as or similar to a file system block group.

[0047] The file system 124 can divide the allocated space into block groups that can be allocation areas of variable size. Allocation areas can be used to store object metadata (e.g., disk tree nodes, index sections) and object data (e.g., file contents, disk areas). A block group (BG) can be understood as a contiguous area allocated to a memory device and reserved for a contiguous portion of a file system object (e.g., a series of LBAs) used for file system data of the file system 124. This contiguous area can be represented as a range of block numbers (e.g., physical addresses). Larger files can be split into individually tracked block groups so that the allocation and management of files is feasible when a series of necessary allocations and writes are performed on the memory devices 130A to 130Z. The default ratio of object data to object metadata can be 1:2. It is intended to use the concept of the Orlov block allocator to allocate related file system objects together and to resist fragmentation by leaving free space between groups. (However, Ext3 block groups have fixed locations calculated according to the size of the file system, while those in a b-tree file system are dynamic and created as needed.) Each block group can be associated with a block group identifier (e.g., a block group entry). An index node in the file system tree can contain a reference (e.g., a pointer to a storage unit) to the corresponding block group.

[0048] A disk extent is a contiguous area of ​​storage space reserved for file system objects of the file system 124. Each file system object may be composed of zero or more disk extents, and each disk extent may store fragments, segments, or portions of a file system object. Each disk extent may be represented by one or more numbers (e.g., a pair of numbers), and each of the numbers may be a location, position, address, other numerical value, or a combination thereof. In one example, each disk extent may be represented by a pair of numbers representing a range (e.g., the start and end of a block range). Representing disk extents as a pair of numbers may be more efficient than conventionally storing each block number in a range. Using disk extents may also enable the file system to reduce metadata overhead for large files. For example, disk extents may be allocated within block groups (BGs). For example, suppose a large file of 10 gigabytes (GB) is broken into 128 megabyte (MB) segments. Multiple blocks in the 128MB blocks may be grouped together as disk extents in a disk extent map that is linked to the larger file and contains metadata. The file system 124 may construct and maintain a disk extent map to manage these disk extents or block groups. In some embodiments, the extent tree is designed to divide the available storage space of the memory device 130 into several flexible allocation strategies. Each extent tree may own a segment of the underlying memory device and may be assigned to a series (or a single) tree root, directory, or inode (index node). The manner in which the file system 124 allocates and deallocates storage units (e.g., extents, block groups) may depend on whether the file system is a copy-on-write file system.

[0049] A copy-on-write file system may be a file system that implements a copy-on-write (COW) feature for managing file system operations. The copy-on-write feature can be contrasted with more traditional techniques that enable in-place writing of file system data. Copy-on-write can be referred to as implicit sharing or hiding and can be a resource management technique that implements a copy operation (e.g., duplication) for modified resources. This can involve creating a copy of object data (e.g., file data) before modifying the object data. In one example, a copy-on-write file system can detect whether an incoming resource is a duplicate of an existing resource and avoid creating a new resource by sharing access to the existing resource. For example, the file system 124 may receive a request to store a new file that is identical to an existing file, but rather than storing a copy of the new file's data, the file system may associate the new file with the existing file's data. When a request is received to access the new file's data, the file system may return the data from the existing file. Thus, storage resources can be shared between the duplicate copy of the data and the original copy. Any write request received for either the new or existing file may result in the creation of a copy, and the two files may no longer share a single copy. A write request may include changes that are applied to the original copy (eg, source storage space) or to a new copy (eg, target storage space), depending on the implementation.

[0050] By sharing resources in this way, it is possible to significantly reduce the resource consumption of unmodified copies while adding a small amount of overhead to resource modification operations (e.g., write requests). Copy-on-write file systems are more suitable for sequential writes because once data is written, it cannot be overwritten. When the file system writes sequentially to the storage device, it is more efficient to use COW management to perform this operation. For example, similar types of data can be written as a group, and therefore can also eventually be overwritten elsewhere as a group until it becomes obsolete and undergoes garbage collection (including erasure). Therefore, writing data of the same data type as the group can minimize garbage collection and reduce write amplification. In addition, in some embodiments, the kernel of the operating system 220 may include device mapping logic 228, which can directly write file system data to the physical addresses of individual areas, and thus map logical addresses to physical addresses of sequentially written areas, which is handled by the transfer memory subsystem controller's need to handle this mapping.

[0051] A B-tree file system (BTRFS) may be an example of a copy-on-write file system that uses a B-tree to handle data updates. A B-tree may be a self-balancing tree data structure that maintains sorted data and allows searches, sequential access, insertions, and deletions in logarithmic time. A B-tree may be similar to a binary search tree (e.g., a binary tree) and may enable nodes with more than two children. A b-tree file system may involve block management that may group blocks into block groups, and each block group (e.g., storage unit 226) may be composed of one or more device extents. The extents of a block group may belong to the same memory device or different memory devices (e.g., in the case of striping). A b-tree file system may support changing the default device storage unit size (e.g., extent size) to a region size so that storage units are aligned with regions. Allocation of blocks within a block group may involve allocating sequential blocks from the beginning of the block group, and allocation pointers may be added to the block group as allocation hints. Allocation pointers may enable sequential allocation of blocks within a block group (e.g., sequentially within a region). The b-tree file system may include a hierarchical list of write requests that can account for IOs received out of order. The hierarchical list can delay the execution of misaligned write requests within a block group. The region of a block group is reset to allow rewriting only when the block group is freed (i.e., when all blocks within the block group are unused).

[0052] exist Figure 2 In the example shown in FIG, the file system 124 may include a storage allocator 227 and a storage deallocator 229 to manage the storage space of the file system data 224. The storage allocator 227 may interact with the memory subsystem 110 to allocate storage space on the memory devices 130A to 130Z. Figures 3 to 5The storage allocator 227 and the storage allocation algorithm are discussed in more detail. The storage deallocator 229 can interact with the memory subsystem 110 to deallocate (e.g., free) storage space on the memory devices 130A to 130Z. The storage deallocator 229 can perform garbage collection of obsolete blocks of memory that can be erased and written to again. The storage allocator 227 and the storage deallocator 229 can be optimized for storing data in the regions 232A to 232Z of the memory subsystem 110.

[0053] The memory subsystem 110 may include a high-density non-volatile memory device, where data retention is required when no power is supplied to the memory device. An example of a non-volatile memory device is a NAND memory device. Figure 1 Memory device 130 of FIGURE 1 illustrates another example of a nonvolatile memory device. A nonvolatile memory device is a package of one or more dies having a set of blocks (e.g., physical blocks), and each block may include a set of pages. A page may include a set of cells (e.g., memory cells), and each cell may be an electronic circuit that stores information. Depending on the cell type, a cell may store one or more bits of binary information and may have various logical states related to the number of bits being stored. The logical states may be represented by binary values ​​(e.g., "0" and "1") or combinations of these values.

[0054] Memory devices 130A-130Z may be composed of bits arranged in a two-dimensional grid. Memory cells are etched onto a silicon wafer in an array of columns (hereinafter also referred to as bit lines) and rows (hereinafter also referred to as word lines). A word line may refer to one or more rows of memory cells of a memory device that are used in conjunction with one or more bit lines to generate an address for each of the memory cells. The intersection of a bit line and a word line constitutes the address of the memory cell. Block 234 may refer to a cell of a memory device (e.g., 130A) used to store data and may include groups of memory cells, groups of word lines, word lines, or individual memory cells. One or more blocks may be grouped together to form a region of a memory device.

[0055] Each of regions 232A-232Z may be a contiguous or non-contiguous portion of a memory device that is identified and managed as a single unit (e.g., a block range). Each region may correspond to region identification data that can be used to uniquely identify the region and may be the same as or similar to a region identifier (region ID), region descriptor, region tag, or other terminology. A region may be a unit of memory storage and may have a predefined size that may or may not be based on the size (e.g., an integer multiple) of another unit of memory storage (e.g., a cell, block, page, die, device, or subsystem). The memory subsystem 110 may use a fixed size (e.g., a constant size or static size) for the region, where all regions may have the same size, or a variable size (e.g., a resizable, dynamic size), where regions used by the memory subsystem 110 may have different sizes. The size of the region may be determined (e.g., selected or detected) by the memory subsystem 110, the memory device 130, the file system 124, the host system 120, the storage allocator 227, other entities, or a combination thereof. The size of the storage unit 226 may be determined by an entity before, during, or after the design, development, manufacturing, installation, initialization, configuration, formatting, other events, or a combination thereof.

[0056] Regions 232A through 232Z may enable more efficient management of storage space as the capacity of the memory device increases. For example, a set of one or more regions may be designated for use by a particular application (e.g., an application, process, or thread) executed by a host system or some other system having access to the memory device. Writes to the regions are typically performed sequentially. Sequential writes may be performed continuously from the top of the memory device (e.g., the lower addresses of the IC die) to the bottom of the memory device (e.g., the higher addresses of the IC die), the bottom of the memory device being illustrated by the patterned data blocks that have been written to the illustrated regions 232A through 232Z. In these embodiments, the device mapping logic 228 may track the block numbers (e.g., logical block addresses) of the namespace.

[0057] A namespace may include the address space of one or more of memory devices 130A-130Z. A namespace is a quantity of non-volatile memory that can be formatted into blocks (e.g., logical blocks or physical blocks). A controller for memory devices 130A-130Z (e.g., controller 115 or 135) may support multiple namespaces referenced using namespace identification data (e.g., namespace IDs). A namespace may be associated with a namespace data structure that is created, updated, or deleted using namespace management and namespace attach commands. The namespace data structure may indicate capabilities and settings specific to a particular namespace. In one example, the naming data structure and namespace may correspond to a partitioned namespace.

[0058] Zoned Namespace (ZNSTM ) can be provided by NVM Express TM (NVMe TM ) organization. A memory device configured with a zone namespace may be referred to as a zoned namespace memory device or a ZNS memory device and may implement the zoned namespace command set as defined by NVMe. In a zone namespace, the address space of each of the memory devices 130A-130Z may be divided into one or more zones 232A-232Z. When using a zone namespace, writes are performed sequentially starting at the beginning of a zone, may be performed at a larger granularity (e.g., 64 kilobytes), and may be inaccessible for the duration of the write operation. Therefore, if a read request for data stored in the same zone or a different zone is received while a write operation is in progress, the memory subsystem will have to pause the write operation in order to perform the read. In one example, the zone namespace may be implemented by a controller of a solid-state drive (SSD) and include zones 232A-232Z, where there may be one or more zones for each of the one or more memory devices 130A-130Z.

[0059] Each of regions 232A through 232Z may correspond to a write pointer (WP) that identifies the location within the region where a previous sequential write ended. A write pointer 233 may correspond to region 232A and may point to the beginning of a block (e.g., the first available block), the end of a block (e.g., the last block written to), a location within a block, or other locations. Write pointer 233 may be stored and accessible by a controller of memory device 130A (e.g., controller 135), a controller of memory subsystem 110 (e.g., controller 115), processing device 221 of host system 120 (e.g., in main memory 223), other devices or locations, or a combination thereof. The write pointer may be used to determine whether an IO write request was directed to the write pointer and, therefore, sequential, or was not directed to the write pointer and, therefore, non-sequential. The write pointer for each region may be accessed by file system 124 for the purpose of allocating storage space within memory device 130A. For example, the write pointer 233 can be stored as metadata of a file system object (eg, metadata of a file system block group) and used for sequential writing, as discussed in more detail below.

[0060] The file system 124 may include a file system API 222 that enables computer programs (e.g., application programs 225) to store or retrieve data. The file system API 222 may enable the file system 124 to receive data from external sources, including data from application programs 225 (also referred to as user data), data from the operating system (e.g., superblocks of data, file system metadata, etc.), which will be referred to as Figure 6Discussed in more detail. By accessing such metadata about these various files of different data types, the file system API 222 may be able to enable the file system 124 to perform organization and storage allocation.

[0061] Applications 225 may include different types of computer programs or architectures that function differently with respect to the hardware and supporting software of computing system 100. In one embodiment, applications 225 may include a record structure merge (LSM) based architecture, such as a database (e.g., Apache Cassandra). TM ), hierarchical event-driven architectures (e.g., SEDA), distributed storage and replication architectures (e.g., Dynamo), data and storage engine models (e.g., , or other such storage engines designed to process and organize structured data, including, for example, Big Data. In some embodiments, using an LSM-based architecture as an example, applications 225 can handle various files containing data and / or metadata of different data types. Each of applications 225 can therefore create, access, and / or manage files of one or more data types.

[0062] Figure 3 FIG2 is a block diagram illustrating an exemplary storage allocator 227 of a file system 124 implementing a storage allocation algorithm according to some embodiments of the present disclosure. Figure 3 The features discussed with respect to the components and modules in the examples may be implemented in software (e.g., computer code) or hardware (e.g., circuitry) of the host system 120 or the memory subsystem 110. More or fewer components or modules may be included without loss of generality. For example, two or more of the components may be combined into a single component, or features of a component may be divided into two or more components. In the illustrated example, the storage allocator 227 may be configured to communicate with the host system 120 or the memory subsystem 110. Figure 2 The storage allocator 227 is the same as or similar to the storage allocator 227 and may include a write request component 310, a region analysis component 320 and an update component 330.

[0063] The write request component 310 can enable the file system to analyze write requests and make a determination on how to handle the write requests. The determination can be based on an analysis of data associated with the write requests 342, the file system 124, the areas 232A to 232Z, the host system 120, the memory subsystem 110, the memory devices 130A to 130Z, other parts of the computer system 100, or a combination thereof. Each of the write requests 342 can correspond to one or more commands (e.g., operations, instructions, opcodes), and the commands can be used to write, append copy, move, modify, update, delete, erase, reset, remove, other commands, or a combination thereof. The write request can be represented as a data structure that includes the file system data 224 discussed above and can include or be associated with one or more attributes (e.g., linked to metadata). Attributes can be updated as write requests are processed and can include attributes based on time (e.g., an incoming timestamp), size (e.g., write size), status (e.g., received, processed, applied), data type (e.g., the type of data to be stored), region (e.g., the region associated with the data), other attributes, or a combination thereof. In one example, the write request component 310 can include a request identification module 312, a data type determination module 314, and a region association module 316.

[0064] The request identification module 312 can identify one or more write requests 342 to be processed by the file system 124. One or more of the write requests 342 can be received from a source external to the file system (e.g., an application or other operating system source), a source internal to the file system (e.g., a unit executing data deduplication, defragmentation, or garbage collection code), other sources, or a combination thereof. The write requests can be initially stored in a temporary storage device, which can include one or more queues (e.g., a modification queue), buffers (e.g., a write buffer), logs (e.g., a file system log), records (e.g., a write record), other storage structures, or a combination thereof. The request identification module 312 can access the write requests 342 from the temporary storage device and select one or more of the write requests to be processed. The order in which the write requests are selected (e.g., identified) can be based on the content and attributes of the write requests.

[0065] The data type determination module 314 can determine one or more data types associated with the file system data 224 of the write request 342. The data type can be determined based on the source (e.g., application process, kernel process), modification frequency (e.g., read-only permission), file system object type (e.g., file, directory, link), file type (e.g., executable, library), file extension (e.g., DOC, XCL, DLL), data encoding (e.g., video, audio, text), formatting, encryption, other aspects, or a combination thereof. In one example, the file system data 224 of the write request can include file data (e.g., file content) and file metadata (e.g., file attributes), and the data type determination module 314 can determine which portions of the file system data include which data types. This can be advantageous because data of a first data type (e.g., file metadata) can be stored at a first location, and data of a second data type (e.g., file content) can be stored at a second location.

[0066] The zone association module 316 can determine whether the file system data of the write request is associated with any zones. Determining whether an associated zone exists can involve identifying a source entity or a target object associated with the file system data of the write request. The source entity can be identified based on entity identification data (e.g., stream ID, application ID, process ID, user ID, device ID, host ID), and the target object can be identified based on object identification data (e.g., index section, file name, ID). The zone association module 316 can then use the identification data to access data about the entity or object, which can indicate the presence or absence of associated zones. In one example, the zone association module 316 can determine that the file system data of the write request corresponds to an existing file system object associated with a zone (e.g., a stream or file with an assigned zone) and can associate the zone with the file system data of the write request. In another example, the zone association module 316 can determine that the file system data of the write request corresponds to a new file system object that is not yet associated with a zone (e.g., does not exist, has no assigned zone, or has lost the assigned zone). In either example, the region association module 316 can indicate the presence or absence of a region by updating a property accessible by the region analysis component 320 .

[0067] The region analysis component 320 can analyze regions in response to a write request 342 to determine which regions are available for storing file system data 224. Regions can be previously associated with file system objects associated with the write request, or can be selected by the region analysis component to add regions or modify previously associated regions. The region analysis component 320 can analyze regions based on region characteristic data 346. The region characteristic data 346 can indicate physical, logical, virtual, or other characteristics of the memory subsystem 110 and memory devices 130A-130Z. For example, the region characteristic data 346 can include data that includes or indicates characteristics related to storage amount (e.g., occupied amount, available amount, size, capacity), location (e.g., start address, end address, write pointer address), state (e.g., open, closed, full, empty), speed (e.g., connection speed, write speed, read speed), other data, or a combination thereof. The characteristics can correspond to one or more specific regions 232A-232Z, blocks 234, memory cells, controllers, other portions of the memory subsystem 110, or a combination thereof. The region characteristics data 346 may include or indicate a physical location (e.g., a physical address), a logical location (e.g., a logical address), a virtual location (e.g., a virtual address), or a combination thereof. The region characteristics data 346 may include data that implements garbage collection, error correction, wear leveling, address translation, other functions, or a combination thereof. In the illustrated example, the region analysis component 320 may include a characteristics data module 322, a space determination module 324, and a region selection module 326.

[0068] The characteristics data module 322 can enable the file system to receive and store region characteristics data. The region characteristics data can be received by the file system 124 of the host system 120 from the controller of the memory subsystem. The data received from the controller can be transformed, aggregated, filtered, sorted, organized, enhanced, supplemented, or modified before, during, or after it is stored in the main memory 223 as region characteristics data 346. The region characteristics data 346 can be received when the host system 120 or the memory subsystem 110 is powered on, initialized, communicated with, accessed, modified, or requested. The region characteristics data can be received in response to a request sent by a portion of the host system (e.g., a file system, a device driver, a kernel, an application), or automatically transmitted by the memory subsystem 110 in the absence of a request from the host system 120.

[0069] The space determination module 324 may enable the file system to determine whether one or more regions have available storage space. The space determination module 324 may determine whether the available storage space in a region is sufficient or insufficient for a storage unit (e.g., a 4KB, 1MB, 1GB block). In one example, determining whether the available storage space is sufficient may involve determining whether the region has a contiguous portion of the space that is large enough to fit within a storage unit. A region where multiple portions of the storage space are smaller than a storage unit but are larger overall than a storage unit may provide insufficient space. In another example, determining whether the available storage space is sufficient may involve aggregating the storage space of one or more portions of the available storage space. When the aggregated available storage amount (e.g., size or capacity) is equal to or greater than a storage unit, the space determination module 324 may indicate that the region has sufficient available storage space, even if none of the contiguous portions of the available storage space is large enough to fit within a storage unit. Conversely, when the aggregated available storage amount (e.g., size or capacity) is less than a storage unit, the space determination module 324 may indicate that the region has insufficient available storage space.

[0070] Determining available storage space may involve analyzing the region characteristics data 346 and performing one or more comparisons, calculations, checks, other operations, or a combination thereof. In one example, the space determination module 324 may determine whether there is sufficient space in the region based on a write pointer for the region, and may compare the position of the write pointer with the end position of the region. In another example, the space determination module 324 may determine whether there is sufficient space in the region by analyzing a portion of the region characteristics data indicating the amount of available storage space for the region (e.g., unoccupied, empty, blank, unwritten storage space) or the amount of unavailable storage space for the region (e.g., occupied, written, in use, a failure has occurred on the provided storage space). The amount of unavailable storage space may be compared to the total capacity of the region to determine the available storage space (e.g., region capacity-unavailable storage space=available storage space). In yet another example, the space determination module may communicate a size (e.g., storage unit size, block group size) with the memory subsystem 110 and receive a response indicating whether the region has sufficient storage space. In either of these examples, the space determination module 324 can indicate whether the region has sufficient space or insufficient space, and the region selection module 326 may or may not use this information.

[0071] The region selection module 326 can enable the file system 124 to select a set of one or more regions of the memory subsystem 110 to store the file system data 224. The set of regions can include a single region or can include multiple regions on the same memory device or on different memory devices. The region selection module 326 can access data from one of the other modules and can select one or more regions based on previously associated regions (or lack thereof), data type matching, sufficiency of storage space, data striping, other aspects, or a combination thereof. The region selection module 326 can select the same region associated with the file system data 224, as discussed above with respect to the region association module 316, or can select a different region.

[0072] The region selection module 326 may select a set of one or more regions based on the type of data being written to the memory device. The region selection module 326 may determine one or more data types associated with the regions. Each of the regions may be associated with one or more data types, and the association with the data type may be reflected by data from the file system 124, region characteristic data 346, or a combination thereof. The region selection module 326 may compare the data type of the file system data 224 with the data type of the regions and select a set of one or more regions based on the comparison. In one example, the write request 342 may include file system data of different data types. A first portion of the file system data may have a first data type (e.g., file data), and a second portion of the file system data may have a different data type (e.g., file metadata). The region selection module 326 may select different regions based on the different data types and may select a first set of regions (e.g., one or more regions) for the first portion and a second set of regions (e.g., one or more regions) for the second portion. The regions selected by the region selection module 326 may be accessed by the update component 330.

[0073] The update component 330 can enable the file system 124 to communicate with the memory subsystem 110 to allocate storage space and store file system data on the memory device. In the illustrated example, the update component 330 can include a storage unit module 332, a host copy module 334, a region reset module 336, a location provision module 338, and a sequential write module 339.

[0074] The storage unit module 332 can enable the file system 124 to allocate space to storage units in selected areas of one or more memory devices. As discussed above, a storage unit can be a contiguous portion of a memory device reserved for a portion of a file system object. The storage unit module 332 can identify a location in the one or more memory devices based on the selected area, area characteristic data (e.g., a write pointer, the start of the area, the end of the area), other data, or a combination thereof. The storage unit module 332 can enable the file system to communicate with the memory subsystem to allocate storage space at the identified location. The file system can use the storage unit module 332 to allocate storage space and can perform one or more operations such as formatting, updating, adding, removing, clearing, assigning, or other operations that modify the memory subsystem, memory devices, or file system.

[0075] When processing each write request, the storage unit module 332 may allocate one or more portions. This may be particularly applicable when the file system uses copy-on-write technology. For example, when processing a request to overwrite data in a single storage unit, the storage unit module 332 may allocate multiple new storage units (e.g., multiple different disk zones). The first storage unit may be smaller and contain the overwritten data, and there may be one or more larger storage units (e.g., a second storage unit and a third storage unit) storing unmodified data on either side of the first storage unit. To avoid having to overwrite unmodified data, the storage unit module 332 may allocate bookend storage units (e.g., disk zones that are fragments of existing disk zones), and the location of the bookend storage units may be identified using a combination of values ​​including a first position value (e.g., an offset value) and a second position value (e.g., a value of a block, region, or memory device).

[0076] The host copy module 334 can enable the file system to maintain a copy of the data stored in the area of ​​the memory device. The copy may be referred to as a "host copy," "host system copy," "temporary copy," or other terms. The copy may be a short-lived copy stored in the host system's main memory (e.g., a primary storage device) and may be copied from a permanent copy in the memory subsystem (e.g., a secondary storage device). The copy in the memory subsystem may be an original copy (e.g., an original version), and the copy in the main memory may be a duplicate copy (e.g., a duplicate version). The original copy and the duplicate copy may be identical (e.g., all bits have the same value) or may be substantially similar, with some bits in different copies being different. This may occur when the original copy includes padding or an unused portion storing unused data (e.g., residual data written in the past).

[0077] The host system can maintain the replica by creating a copy and by updating the copy. The host system can create a copy in the main memory before, during, or after modifying the copy in the memory subsystem. The host system can also update the copy in response to one or more write requests 342 to the file system data 224. After resetting the region with the original copy using the region reset module 336, the updated copy can then be persistently stored by the memory subsystem.

[0078] The region reset module 336 can enable the host system to reset one or more regions of the memory subsystem. Resetting a region can involve one or more operations, including erasing, updating, configuring, or formatting the region or the region's data (e.g., content or metadata). The region reset module 336 can enable the host system to communicate with the memory subsystem, and one or more of the operations can be performed by the host system, the memory subsystem (e.g., controller 115), the memory device (e.g., controller 135), another processor, or a combination thereof. In one example, resetting a region can update the location of a write pointer for the region to a new location (e.g., resetting the write pointer to the beginning of the region).

[0079] The location provision module 338 can enable the host system to provide the location in the memory device to the memory subsystem. In conventional memory subsystems, the host system can provide data to be stored without providing the location where the data is stored. As disclosed herein, the host system can provide the location of the storage unit to the memory subsystem to control the location where the memory subsystem stores the file system data 224. The location can be a value (e.g., a number, address, or identifying data) of a specific area, block, device, subsystem, other location, or a combination thereof.

[0080] The sequential write module 339 enables the host system to initiate sequential writes of file system data 224 to a selected set of one or more regions of the memory subsystem. As discussed above, the file system data of the write request can be applied to the copy in the main memory. The sequential write module 339 can then durably store the copy in the main memory by providing (e.g., refreshing) the copy from the main memory to the memory subsystem. The host system can provide the sequentially written data in the form of one or more storage units, block groups, data streams, information blocks, fragments, blocks, pages, bytes, bits, other portions, or combinations thereof. In one example, the sequential write module 339 can sequentially write the updated copy from the main memory to one or more storage units in a single region. In another example, the sequential write module 339 can write the updated copy to multiple storage units from different regions. The latter example can involve striping data across different regions.

[0081] The host system 120 and the file system 124 may implement data striping to better store file system data in the memory devices. Data striping may involve striping data for a file system object or a group of file system objects across a set of regions. The set of regions may include multiple regions that may be on the same or different memory devices, memory subsystems, other devices, or a combination thereof. In one example, the storage unit module 332 may allocate multiple storage units in different memory devices and write to the multiple storage units sequentially. The different memory devices may be part of the same memory subsystem or part of different memory subsystems. In another example, the storage unit module 332 may allocate multiple storage units in a set of non-adjacent regions of a single memory device and write to the multiple storage units sequentially. Regions in a set may be non-adjacent when the regions in the set are separated from all other regions in the set in at least one or more spatial directions (e.g., up / down, left / right, forward / backward). Thus, regions may be horizontally non-adjacent (by being separated by regions along a row) or vertically non-adjacent (e.g., by being separated by regions along a column). In either instance, data striping may iterate and loop through a set of selected regions.

[0082] Cycling through the regions may involve splitting a file system object or a group of similar file system objects into a plurality of storage units (e.g., 10 storage units) and selecting a group of non-adjacent regions (e.g., region 0, region 3, region 10) to store the file system object. The host system may execute the storage allocator 227 to allocate and write a first storage unit to a first region (e.g., region 0) in the group, allocate and write a second storage unit to a second region (e.g., region 3) in the group, and allocate and write a third storage unit to a third region (e.g., region 10). The storage allocator 227 may then loop back and store the fourth storage unit in the first region (e.g., region 0). This iteration and looping back may continue until all storage units are allocated and written.

[0083] Figure 4 Flowchart of a method 400 for file system storage allocation based on regions of a memory device according to an embodiment. The method 400 may be performed by processing logic, which may include hardware (e.g., a processing device, circuitry, dedicated logic, programmable logic, microcode, hardware of a device, an integrated circuit, etc.), software (e.g., instructions running or executed on a processing device), or a combination thereof. In some embodiments, the method 400 is performed by Figure 2Executed by the host system 120 (e.g., via execution of the file system 124 by the processing device 221). Although shown in a particular order or sequence, the order of the processes may be modified unless otherwise specified. Therefore, the illustrated embodiments should be understood as examples only, and the illustrated processes may be performed in a different order, and some processes may be performed in parallel. In addition, one or more processes may be omitted in various embodiments. Therefore, not all processes are required in every embodiment. Other process flows are possible.

[0084] At operation 410, a processing device of a host system may receive zone characteristic data from a memory subsystem including a memory device. The memory device may include a plurality of zones, and the zone characteristic data may include one or more locations in the memory device corresponding to the zones. Receiving the zone characteristic data may involve the host system receiving the zone characteristic data from a controller of the memory subsystem. The zone characteristic data may indicate characteristics (e.g., physical characteristics) of the memory device and include garbage collection data (e.g., obsolete blocks) and one or more physical memory locations on the memory device. The zone characteristic data may additionally or alternatively indicate a size, status, or write pointer for each of the zones. The write pointer may be a location (e.g., a logical block address (LBA)) of the memory device. In one example, the memory subsystem may be a solid-state drive (SSD), and the zones may be zones that conform to a zone name space (ZNS).

[0085] At operation 420, a processing device of the host system may identify a write request comprising file system data for a file system. In one example, the file system may be a copy-on-write (COW) file system that copies file data before modifying it. A copy-on-write file system may use a B-tree and is referred to as a B-tree file system (BTRFS). The write request may be received from a source external to the file system (e.g., an application or other operating system source), a source internal to the file system (e.g., data deduplication, defragmentation, or garbage collection code), other sources, or a combination thereof. The write request may be initially stored in a temporary storage device, which may include one or more queues, buffers, logs, records, other storage structures, or a combination thereof.

[0086] At operation 430, the processing device of the host system may determine whether the file system data is associated with at least one of the zones. Determining whether an associated zone exists may involve identifying a source entity (e.g., a specific stream or application) or a target object (e.g., a specific file or directory) associated with the file system data of the write request. Operation 430 may detect data of the source entity or target object to determine whether it is associated with a zone that can then be attributed to the file system data.

[0087] In one example, the write request may be a set of multiple write requests with changes to different portions of a Super Block of the file system, and the host system may determine that the Super Block is associated with a particular region. The host copy may then make a copy of all the data in the region in main memory and update the copy to reflect the changes from the write request. The host system may then erase all the data in the region from the memory device and initiate a single sequential write of the updated copy in main memory to the region of the memory device.

[0088] At operation 440, the processing device of the host system may allocate storage units based on the region characteristic data. In one example, allocating storage units based on the region characteristic data may involve the host system determining whether the region of the memory device has sufficient space for the storage units. The determination may be based on a write pointer for the region and an end position of the region. The host system may allocate storage units in the region in response to the region having sufficient space, or allocate storage units in another region in response to the region having insufficient space. In another example, allocating storage units may involve determining that the file system data includes different data types, and a first portion of the file system data may include file data, and a second portion of the file system data may include file metadata. The host system may select different regions based on the different data types, and the first region may be used for the data of the file and the second region may be used for the metadata of the file. In either example, the storage units may be the same as or similar to a block group or disk extent of a file system, and may be a contiguous group of blocks of a memory device that stores a portion of a file system object (e.g., a file).

[0089] At operation 450, the processing device of the host system may provide the locations of the storage units to the memory subsystem for storing the file system data on the memory device. In one example, the plurality of storage units in non-contiguous regions may have been allocated, and providing the locations may involve providing the locations of each of the plurality of storage units to a controller of the memory subsystem for striping the file system data across the non-contiguous regions. In another example, the plurality of storage units in regions of different memory devices may have been allocated, and providing the locations may involve providing the locations of the plurality of storage units to the controller of the memory subsystem for striping the file system data across regions of the different memory devices.

[0090] Figures 5 to 6 An example of a file system that allocates and writes file system storage units (eg, groups of blocks) to regions of one or more memory devices is provided. Figure 5Flowchart of method 500 for allocating storage units that are contiguous portions of a file system object into groups of memory units (or regions) according to some embodiments. Method 500 may be performed by processing logic that may include hardware (e.g., a processing device, circuitry, dedicated logic, programmable logic, microcode, hardware of a device, an integrated circuit, etc.), software (e.g., instructions running or executed on a processing device), or a combination thereof. In some embodiments, method 500 is performed by Figures 1 to 2 The processes are executed by the host system 120 (e.g., via the execution file system 124). Although shown in a particular order or sequence, the order of the processes may be modified unless otherwise specified. Therefore, the illustrated embodiments should be understood as examples only, and the illustrated processes may be performed in a different order, and some processes may be performed in parallel. In addition, one or more processes may be omitted in various embodiments. Therefore, not all processes are required in every embodiment. Other process flows are possible.

[0091] At operation 510, processing logic retrieves storage units (SUs) to be written to a memory device. This may involve writing to one or more integrated circuit (IC) dies of a memory device (e.g., memory devices 130A-130Z). A storage unit may be the same as or similar to a group of blocks and may be a contiguous portion of a file system object (e.g., a file) to be written to the memory device.

[0092] At operation 520, processing logic determines whether the storage unit is associated with a file system object (e.g., an index, a file group, a stream). To do this, processing logic may access metadata associated with the storage unit (e.g., block group metadata) to determine an identifier of a file system object (e.g., a stream identifier) ​​associated with the storage unit.

[0093] At operation 530, processing logic determines whether there is available space in the region associated with the file system object in response to retrieving the file system object identifier (e.g., stream ID). If there is space, at operation 540, processing logic accesses a write pointer associated with the region within the storage unit metadata, the region being associated with the file system unit. Furthermore, at operation 545, processing logic allocates a contiguous range of physical addresses within the region for sequentially writing to the storage units beyond the write pointer. Processing logic may further generate an input / output (IO) write request to sequentially write the storage units to the contiguous range of physical addresses within the region, the write request starting at the write pointer.

[0094] In some embodiments, processing logic may associate a storage unit with a region, a region with a storage unit, or a combination thereof. This may involve direct association or indirect association. A direct association may add region identification data to a storage unit, or a storage unit identification data to a region. An indirect association may add identification data of a file system object to metadata of a storage unit, a region, or a combination thereof.

[0095] Returning to operation 520, in response to the storage unit not being associated with an existing file system object (e.g., metadata without a stream ID), or returning to operation 530, in response to the absence of available space in the region, processing logic transitions to operation 535. At operation 535, processing logic determines whether there is an available region with sufficient storage space. If not, at operation 550, processing logic performs traditional storage unit allocation (e.g., traditional block group allocation) to include garbage collection, block fragmentation, random writes, etc.

[0096] If at operation 535 there is an available second group of memory cells having space for a storage cell allocation, processing logic allocates storage space for the storage cell in the available region at operation 560. At operation 565, processing logic associates identification data of the available region with the storage cell.

[0097] Method 500 may then loop back to operation 530, where processing logic determines that there is available space in an available region (e.g., a second region). At operation 540, processing logic accesses a second write pointer associated with the second region within the storage unit metadata. And, at operation 545, processing logic allocates a contiguous range of physical addresses of a sequential write block group within the second region that extends beyond the second write pointer.

[0098] Method 500 may loop back to operation 510, where processing logic retrieves a second storage unit to be written to the IC die of the memory device, the second storage unit being associated with a second file system object (e.g., a file). In one embodiment, at operation 520, processing logic accesses storage unit metadata associated with the second storage unit to determine that the second storage unit has not yet been assigned to a region, causing processing logic to transition again to operation 535. At operation 535, processing logic determines that a second region is available for new allocation. At operation 560, processing logic allocates the second storage unit to the second region. At operation 565, processing logic assigns a file system object identifier (e.g., a stream ID) associated with the second region to the second storage unit.

[0099] Method 500 may loop back to operation 530, where processing logic determines that there is available space in the second region that can be allocated. At operation 540, processing logic accesses a second write pointer associated with the second region within the storage unit metadata associated with the second storage unit. At operation 545, processing logic allocates a contiguous range of physical addresses within the second region that are sequentially written to the second storage unit beyond the second write pointer.

[0100] Figure 6 Schematic diagram illustrating a computing system 600 including a host file system association including a stream identifier (ID) and a data type, and a stream ID and a specific region (or group of memory cells) according to various embodiments. In various embodiments, the computing system 600 includes a file system 124 of an operating system 220, at least one application 225, and a kernel 628, which can be operated by, for example, a processing device 221 ( Figure 2 ) is executed by a processing device. The computing system 100 may further include a memory device 130A, which may have a similar structure to the memory device 130A ( Figure 2 ) of a non-volatile memory device having multiple IC bare chips.

[0101] For the purpose of explanation, the application 225 is a database based on the LSM architecture (e.g., Cassandra TM ) or similar software applications. Thus, in this embodiment, the application 225 handles files of several different data types, including, for example, administrative files 603, data files 605, commit logs 607, and system logs 609. The commit logs 607 may be a record of transactions executed by the database application.

[0102] In some embodiments, the file system 124 can manage and perform allocation for several data types, including, but not limited to, superblocks 610 for data and system metadata 615 (generated by the operating system 220), file system (FS) metadata 618 (e.g., inodes, tree roots, extent maps, etc.), and user data 620 (which in this example are different types of extents). Files generated by applications 225 can be associated with user data 620.

[0103] like Figure 2As described in

[15] , file system 124 can partition files of each data type into different storage units (e.g., block groups) or a series of storage units (e.g., a series of block groups), and can assign each storage unit to a different region (e.g., a group of memory units) in memory device 130A, thereby generating a stream of data (or metadata) of each data type written to the assigned region as a group. A stream ID can be assigned to each storage unit and to the region to which the storage unit is assigned. Partitioned files can also be associated with the same stream ID, for example, by tagging the file with the stream ID in some manner. In this way, the mapping between storage units and regions is transitive and straightforward, and sequential writes to regions can be striped across IC dies according to storage units (or files), resulting in load balancing that enhances performance. At the same time, because each storage unit has the same data type, the data written to each region is of the same type (or from the same application and therefore has data locality), has a similar lifespan, and is likely to be modified at approximately the same rate for the purpose of efficient garbage collection.

[0104] While the files / storage units of the superblock 610, the system metadata 614, the inodes (of the FS metadata 618), and the extent maps (of the FS metadata 618) can each be assigned to a separate stream (e.g., a different stream ID), the files / storage units of the user data 620 can include multiple data types that can be individually assigned to different stream IDs. Table 1 illustrates possible stream ID assignments for different types of user data 620 associated with the application 225 in different embodiments.

[0105] Data Type Stream ID Management Files 0 Submit records 1 System logs 2 Data Directory Group Based on LSM ID, for example, 3+

[0106] Table 1

[0107] Each LSM ID may be associated with a different data directory and therefore assigned a separate stream ID. It is contemplated that additional types of stream IDs will be assigned to different data types.

[0108] In various embodiments, the file system 124 generates IO write requests to an allocated contiguous range of physical addresses that exceeds the current WP. In some embodiments, the kernel 628 can use the device mapping logic 228 to intercept and direct these IO write requests to start sequential writes to the appropriate region at the current region WP, otherwise the IO write request is treated as a non-sequential write request. In other embodiments, the device mapping logic 228 is integrated within the file system 124, which can directly manage the device mapping to the appropriate region.

[0109] After an area becomes fully written, for example, there is no longer room for further sequential IO writes, the file system 124 may allocate space in another area where files / storage units of a specific data type can continue to be written sequentially. Assume that a first stream ID (e.g., stream ID_0) is assigned to the area that becomes full, and the first file / storage unit is assigned to the area with the first stream ID. In response to the group of memory cells becoming fully written, the file system 124 may allocate a second group (new area) of memory cells of the IC die to the file / storage unit. The file system 124 may further assign a second stream assigned to the new (e.g., second) area to the first file / storage unit. The file system 124 may further cause additional files / storage units in the file / storage unit to be written sequentially to the second group of memory cells based on the second stream ID.

[0110] Figure 7 An example machine illustrating a computer system 700 within which a set of instructions for causing the machine to perform any one or more of the methodologies discussed herein may be executed. In some embodiments, the computer system 700 may correspond to a host system (e.g., Figures 1 to 2 120) that includes, is coupled to, or utilizes a memory subsystem (e.g., Figure 1 In some embodiments, the machine may be connected (e.g., using a network) to other machines. The machine may operate in the capacity of a server or a client machine in a client-server network environment, or in the capacity of a peer machine in a peer-to-peer (or distributed) network environment, or as a server or a client machine in a cloud computing infrastructure or environment.

[0111] The machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a cellular phone, a network appliance, a server, a network router, a switch or a bridge, or any machine capable of executing (sequentially or otherwise) a set of instructions that specify actions to be taken by the machine. Further, while a single machine is described, the term "machine" shall also be taken to include any collection of machines that individually or collectively execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

[0112] The example computer system 700 includes a processing device 702, a main memory 704 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM), such as synchronous DRAM (SDRAM) or Rambus DRAM (RDRAM)), etc.), a static memory 706 (e.g., flash memory, static random access memory (SRAM), etc.), and a data storage system 718, which communicate with each other via a bus 730.

[0113] Processing device 702 represents one or more general-purpose processing devices, such as a microprocessor, a central processing unit, or the like. More specifically, the processing device may be a complex instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, or a processor that implements other instruction sets, or a combination of instruction sets. Processing device 702 may also be one or more special-purpose processing devices, such as an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a digital signal processor (DSP), a network processor, or the like. Processing device 702 is configured to execute instructions 726 for performing the operations and steps discussed herein. Computer system 700 may further include a network interface device 708 for communicating via a network 720.

[0114] The data storage system 718 may include a machine-readable storage medium 724 (also referred to as a non-transitory computer-readable medium) on which is stored one or more sets of instructions 726 or software embodying any one or more of the methodologies or functions described herein. The instructions 726 may also reside, completely or at least partially, within the main memory 704 and / or within the processing device 702 during execution thereof by the computer system 700, with the main memory 704 and the processing device 702 also constituting machine-readable storage media. The machine-readable storage medium 724, the data storage system 718, and / or the main memory 704 may correspond to Figure 1 Memory subsystem 110.

[0115] In one embodiment, instructions 726 include instructions for implementing the instructions corresponding to Figures 1 to 2 The functional instructions of the file system 124 are stored in a manner that is consistent with the machine-readable storage medium 724. Although the machine-readable storage medium 724 is shown as a single medium in the example embodiment, the term "non-transitory machine-readable storage medium" should be considered to include a single medium or multiple media that store one or more sets of instructions. The term "machine-readable storage medium" should also be considered to include any medium that is capable of storing or encoding a set of instructions for execution by a machine and causing the machine to perform any one or more of the methods of the present disclosure. Thus, the term "machine-readable storage medium" should be considered to include, but not be limited to, solid-state memory, optical media, and magnetic media.

[0116] Some portions of the previously described details have been presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means by which those skilled in the art of data processing can most effectively convey the substance of their work to others skilled in the art. An algorithm herein generally refers to a self-consistent sequence of operations that produces a desired result. An operation is an operation that requires physical manipulation of physical quantities. These quantities are typically, but not necessarily, in the form of electrical or magnetic signals that can be stored, combined, compared, and otherwise manipulated. Primarily for general reasons, it has proven convenient to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, etc.

[0117] It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. The present disclosure may refer to the actions and processes of a computer system or similar electronic computing device that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system's memories or registers or other such information storage systems.

[0118] The present disclosure also relates to an apparatus for performing the operations herein. This apparatus may be specially constructed for the desired purpose, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer-readable storage medium, such as, but not limited to, any type of disk, including floppy disks, optical disks, CD-ROMs and magnetic optical disks, read-only memory (ROM), random access memory (RAM), EPROM, EEPROM, magnetic or optical cards, or any type of medium suitable for storing electronic instructions, each coupled to a computer system bus.

[0119] The algorithms and displays presented herein are not inherently related to any particular computer or other device. Various general-purpose systems can be used in conjunction with the programs according to the teachings herein, or it may prove convenient to construct more specialized devices for performing the methods. The structures for various such systems will be presented as shown in the following description. In addition, the present disclosure is not described with reference to any particular programming language. It will be appreciated that the teachings of the present disclosure as described herein can be implemented using various programming languages.

[0120] The present disclosure may be provided as a computer program product or software, which may include a machine-readable medium having stored thereon instructions that can be used to program a computer system (or other electronic device) to perform a process according to the present disclosure. A machine-readable medium includes any mechanism for storing information in a form readable by a machine (e.g., a computer). In some embodiments, a machine-readable (e.g., non-transitory computer-readable) medium includes a machine (e.g., computer) readable storage medium, such as a read-only memory ("ROM"), a random access memory ("RAM"), a magnetic disk storage medium, an optical storage medium, a flash memory component, or the like.

[0121] In the foregoing description, the embodiments of the present disclosure have been described with reference to specific example embodiments thereof. It will be apparent that various modifications may be made to the present disclosure without departing from the broader spirit and scope of the embodiments of the present disclosure as set forth in the appended claims. Accordingly, the description and drawings are to be regarded as illustrative rather than restrictive.

Claims

1. A method for a memory, the method comprising: receiving, by a host system, region characteristic data from a memory subsystem including a memory device, wherein the memory device includes a plurality of regions, and wherein the region characteristic data indicates one or more locations in the memory device corresponding to the plurality of regions; identifying, by the host system, a write request comprising file system data for a file system; determining that the file system data is associated with a region within the plurality of regions; aggregating respective available storage spaces of one or more portions of the regions in the plurality of regions; determining that the aggregated available storage space is equal to or greater than a block group size; allocating, by the host system, a block group having the block group size in the zone of the plurality of zones based on the zone characteristic data and the file system data, wherein the zone includes a plurality of block groups; and A physical address of the group of blocks is provided to the memory subsystem by the host system, wherein the physical address references a location of the file system data in the group of blocks. 2 . The method of claim 1 , wherein the memory subsystem comprises a solid-state drive (SSD), and wherein the plurality of zones comprises a zoned namespace (ZNS). 3 . The method of claim 1 , wherein the file system comprises a copy-on-write file system that copies file data before modifying the file data, wherein the copy-on-write file system comprises a B-tree file system (BTRFS).

4. The method of claim 1, wherein the block group comprises one or more disk extents of the file system, wherein the one or more disk extents comprise a contiguous group of blocks that is a portion of a storage file of the memory device.

5. The method of claim 1 , wherein allocating the block groups based on the region characteristic data comprises: determining, by the host system, that the region of the memory device has sufficient space for the group of blocks, wherein the determination is based on a write pointer for the region and an end position of the region; and Responsive to the region having sufficient space, the group of blocks in the region is allocated.

6. The method of claim 1 , wherein the file system data comprises data for a new file, and wherein allocating the block group comprises: determining that the file system data includes different data types, wherein a first portion of the file system data includes file data and a second portion of the file system data includes file metadata; selecting different areas based on the different data types, wherein a first area is for data of a file and a second area is for metadata of the file; and The file data is written to the first area, and the file metadata is written to the second area, by the host system.

7. The method of claim 1 , wherein the write request comprises multiple write requests with changes to different portions of a superblock of the file system, and the method further comprising, determining, by the host system, that the super block is associated with the region; forming a copy of all data in the region in main memory; updating, by the host system, the replica to reflect the changes from the plurality of write requests; erasing all of the data in the area from the memory device; and A single sequential write of the updated copy in main memory to the region of the memory device is initiated by the host system.

8. The method of claim 1, wherein receiving the region characteristics data comprises the host system receiving the region characteristics data from a controller of the memory subsystem, the region characteristics data indicating a size, a write pointer, and a status of each of the plurality of regions.

9. The method of claim 1, wherein the region characteristic data sent from the memory subsystem to the host system indicates physical characteristics of the memory device and includes garbage collection data and one or more physical memory locations on the memory device.

10. The method of claim 1 , wherein allocating the block groups based on the region characteristic data comprises allocating multiple block groups in non-adjacent regions, and wherein providing the physical addresses comprises providing a physical address of each of the multiple block groups to a controller of the memory subsystem to stripe the file system data across the non-adjacent regions.

11. The method of claim 1 , wherein allocating the block groups based on the region characteristic data comprises allocating multiple block groups in regions of different memory devices, and wherein providing the physical addresses comprises providing the physical addresses of the multiple block groups to a controller of the memory subsystem to stripe the file system data across the regions of the different memory devices.

12. A memory system comprising: Memory; and a processing device operatively coupled to the memory to perform operations comprising: receiving region characteristic data from a memory subsystem including a memory device, wherein the memory device includes a plurality of regions, and wherein the region characteristic data indicates one or more locations in the memory device corresponding to the plurality of regions; identifying a write request comprising file system data for a file system; determining that the file system data is associated with a region within the plurality of regions; aggregating respective available storage spaces of one or more portions of the regions in the plurality of regions; determining that the aggregated available storage space is equal to or greater than a block group size; allocating block group storage units having the block group size in the region of the plurality of regions based on the region characteristic data and the file system data, wherein the region includes a plurality of block groups; and A physical address of a location of the block group storage unit is provided to the memory subsystem, wherein the physical address references a location of the file system data in the block group.

13. The memory system of claim 12 , wherein each region of the plurality of regions in the region namespace accepts sequential write operations from a host system, wherein a first region is associated with a first process executing on the host system, and wherein a second region is associated with a second process executing on the host system. 14 . The memory system of claim 12 , wherein the processing device is a controller of a solid-state drive (SSD), and wherein the plurality of zones include a zone name space (ZNS). 15 . The memory system of claim 12 , wherein the file system comprises a copy-on-write file system that copies file data before modifying the file data, wherein the copy-on-write file system comprises a B-tree file system (BTRFS).

16. The memory system of claim 12, wherein the block group comprises one or more extents of the file system, wherein the one or more extents comprise a contiguous group of blocks that is a portion of a storage file of the memory device.

17. A non-transitory computer-readable medium storing instructions that, when executed by a processing device, cause the processing device to perform operations comprising: receiving region characteristic data from a memory subsystem including a memory device, wherein the memory device includes a plurality of regions, and wherein the region characteristic data indicates one or more locations in the memory device corresponding to the plurality of regions; identifying a write request comprising file system data for a file system; determining that the file system data is associated with a region within the plurality of regions; aggregating respective available storage spaces of one or more portions of the regions in the plurality of regions; determining that the aggregated available storage space is equal to or greater than a block group size; allocating a block group having the block group size in the zone among the plurality of zones based on the zone characteristic data and the file system data, the zone including a plurality of block groups; and A physical address of the group of blocks is provided to the memory subsystem, wherein the physical address references a location of the file system data in the group of blocks.

18. The non-transitory computer-readable medium of claim 17, wherein the memory subsystem comprises a solid-state drive (SSD), and wherein the plurality of zones comprises a zoned namespace (ZNS).

19. The non-transitory computer-readable medium of claim 17, wherein the file system comprises a copy-on-write file system that copies file data before modifying the file data, wherein the copy-on-write file system comprises a B-tree file system (BTRFS).

20. The non-transitory computer-readable medium of claim 17, wherein the block group comprises one or more extents of the file system, wherein the one or more extents comprise a contiguous group of blocks that stores a portion of a file of the memory device.

Images