Hubbry Logo
Fragmentation (computing)Fragmentation (computing)Main
Open search
Fragmentation (computing)
Community hub
Fragmentation (computing)
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Fragmentation (computing)
Fragmentation (computing)
Fragmentation (computing)
View on Wikipedia
from Wikipedia

In computer storage, fragmentation is a phenomenon in the computer system which involves the distribution of data in to smaller pieces which storage space, such as computer memory or a hard drive, is used inefficiently, reducing capacity or performance and often both. The exact consequences of fragmentation depend on the specific system of storage allocation in use and the particular form of fragmentation. In many cases, fragmentation leads to storage space being "wasted", and programs will tend to run inefficiently due to the shortage of memory.

Basic principle

[edit]

In main memory fragmentation, when a computer program requests blocks of memory from the computer system, the blocks are allocated in chunks. When the computer program is finished with a chunk, it can free it back to the system, making it available to later be allocated again to another or the same program. The size and the amount of time a chunk is held by a program varies. During its lifespan, a computer program can request and free many chunks of memory.

Fragmentation can occur when a block of memory is requested by a program, and is allocated to that program, but the program has not freed it.[1] This leads to theoretically "available", unused memory, being marked as allocated - which reduces the amount of globally available memory, making it harder for programs to request and access memory.

When a program is started, the free memory areas are long and contiguous. Over time and with use, the long contiguous regions become fragmented into smaller and smaller contiguous areas. Eventually, it may become impossible for the program to obtain large contiguous chunks of memory.

Types

[edit]

There are three different but related forms of fragmentation: external fragmentation, internal fragmentation, and data fragmentation, which can be present in isolation or conjunction. Fragmentation is often accepted in return for improvements in speed or simplicity. Analogous phenomena occur for other resources such as processors; see below.

Internal fragmentation

[edit]

Memory paging creates internal fragmentation because an entire page frame will be allocated whether or not that much storage is needed.[2] Due to the rules governing memory allocation, more computer memory is sometimes allocated than is needed. For example, memory can only be provided to programs in chunks (usually a multiple of 4 bytes), and as a result if a program requests perhaps 29 bytes, it will actually get a chunk of 32 bytes. When this happens, the excess memory goes to waste. In this scenario, the unusable memory, known as slack space, is contained within an allocated region. This arrangement, termed fixed partitions, suffers from inefficient memory use - any process, no matter how small, occupies an entire partition. This waste is called internal fragmentation.[3][4]

Unlike other types of fragmentation, internal fragmentation is difficult to reclaim; usually the best way to remove it is with a design change. For example, in dynamic memory allocation, memory pools drastically cut internal fragmentation by spreading the space overhead over a larger number of objects.

External fragmentation

[edit]

External fragmentation arises when free memory is separated into small blocks and is interspersed by allocated memory. It is a weakness of certain storage allocation algorithms, when they fail to order memory used by programs efficiently. The result is that, although free storage is available, it is effectively unusable because it is divided into pieces that are too small individually to satisfy the demands of the application. The term "external" refers to the fact that the unusable storage is outside the allocated regions.

For example, consider a situation wherein a program allocates three continuous blocks of memory and then frees the middle block. The memory allocator can use this free block of memory for future allocations. However, it cannot use this block if the memory to be allocated is larger in size than this free block.

External fragmentation also occurs in file systems as many files of different sizes are created, change size, and are deleted. The effect is even worse if a file which is divided into many small pieces is deleted, because this leaves similarly small regions of free spaces.

Time 0x0000 0x1000 0x2000 0x3000 0x4000 0x5000 Comments
0 Start with all memory available for storage.
1 A B C Allocated three blocks A, B, and C, of size 0x1000.
2 A C Freed block B. Notice that the memory that B used cannot be included for a block larger than B's size.
3 A C Block C moved into block B's empty slot, allowing the remaining space to be used for a larger block of size 0x4000.

Data fragmentation

[edit]
Main article: File system fragmentation

Data fragmentation occurs when a collection of data in memory is broken up into many pieces that are not close together. It is typically the result of attempting to insert a large object into storage that has already suffered external fragmentation. For example, files in a file system are usually managed in units called blocks or clusters. When a file system is created, there is free space to store file blocks together contiguously. This allows for rapid sequential file reads and writes. However, as files are added, removed, and changed in size, the free space becomes externally fragmented, leaving only small holes in which to place new data. When a new file is written, or when an existing file is extended, the operating system puts the new data in new non-contiguous data blocks to fit into the available holes. The new data blocks are necessarily scattered, slowing access due to seek time and rotational latency of the read/write head, and incurring additional overhead to manage additional locations. This is called file system fragmentation.

When writing a new file of a known size, if there are any empty holes that are larger than that file, the operating system can avoid data fragmentation by putting the file into any one of those holes. There are a variety of algorithms for selecting which of those potential holes to put the file; each of them is a heuristic approximate solution to the bin packing problem. The "best fit" algorithm chooses the smallest hole that is big enough. The "worst fit" algorithm chooses the largest hole. The "first-fit algorithm" chooses the first hole that is big enough. The "next fit" algorithm keeps track of where each file was written. The "next fit" algorithm is faster than "first fit," which is in turn faster than "best fit," which is the same speed as "worst fit".[5]

Just as compaction can eliminate external fragmentation, data fragmentation can be eliminated by rearranging data storage so that related pieces are close together. For example, the primary job of a defragmentation tool is to rearrange blocks on disk so that the blocks of each file are contiguous. Most defragmenting utilities also attempt to reduce or eliminate free space fragmentation. Some moving garbage collectors, utilities that perform automatic memory management, will also move related objects close together (this is called compacting) to improve cache performance.

There are four kinds of systems that never experience data fragmentation—they always store every file contiguously. All four kinds have significant disadvantages compared to systems that allow at least some temporary data fragmentation:

  1. Simply write each file contiguously. If there isn't already enough contiguous free space to hold the file, the system immediately fails to store the file—even when there are many little bits of free space from deleted files that add up to more than enough to store the file.
  2. If there isn't already enough contiguous free space to hold the file, use a copying collector to convert many little bits of free space into one contiguous free region big enough to hold the file. This takes a lot more time than breaking the file up into fragments and putting those fragments into the available free space.
  3. Write the file into any free block, through fixed-size blocks storage. If a programmer picks a fixed block size too small, the system immediately fails to store some files—files larger than the block size—even when there are many free blocks that add up to more than enough to store the file. If a programmer picks a block size too big, a lot of space is wasted on internal fragmentation.
  4. Some systems avoid dynamic allocation entirely, pre-storing (contiguous) space for all possible files they will need—for example, MultiFinder pre-allocates a chunk of RAM to each application as it was started according to how much RAM that application's programmer claimed it would need.

Comparison

[edit]

Compared to external fragmentation, overhead and internal fragmentation account for little loss in terms of wasted memory and reduced performance. It is defined as:

Fragmentation of 0% means that all the free memory is in a single large block; fragmentation is 90% (for example) when 100 MB free memory is present but largest free block of memory for storage is just 10 MB.

External fragmentation tends to be less of a problem in file systems than in primary memory (RAM) storage systems, because programs usually require their RAM storage requests to be fulfilled with contiguous blocks, but file systems typically are designed to be able to use any collection of available blocks (fragments) to assemble a file which logically appears contiguous. Therefore, if a highly fragmented file or many small files are deleted from a full volume and then a new file with size equal to the newly freed space is created, the new file will simply reuse the same fragments that were freed by the deletion. If what was deleted was one file, the new file will be just as fragmented as that old file was, but in any case there will be no barrier to using all the (highly fragmented) free space to create the new file. In RAM, on the other hand, the storage systems used often cannot assemble a large block to meet a request from small noncontiguous free blocks, and so the request cannot be fulfilled and the program cannot proceed to do whatever it needed that memory for (unless it can reissue the request as a number of smaller separate requests).

Problems

[edit]

Storage failure

[edit]

The most severe problem caused by fragmentation is causing a process or system to fail, due to premature resource exhaustion: if a contiguous block must be stored and cannot be stored, failure occurs. Fragmentation causes this to occur even if there is enough of the resource, but not a contiguous amount. For example, if a computer has 4 GiB of memory and 2 GiB are free, but the memory is fragmented in an alternating sequence of 1 MiB used, 1 MiB free, then a request for 1 contiguous GiB of memory cannot be satisfied even though 2 GiB total are free.

In order to avoid this, the allocator may, instead of failing, trigger a defragmentation (or memory compaction cycle) or other resource reclamation, such as a major garbage collection cycle, in the hope that it will then be able to satisfy the request. This allows the process to proceed, but can severely impact performance.

Performance degradation

[edit]

Fragmentation causes performance degradation for a number of reasons. Most basically, fragmentation increases the work required to allocate and access a resource. For example, on a hard drive or tape drive, sequential data reads are very fast, but seeking to a different address is slow, so reading or writing a fragmented file requires numerous seeks and is thus much slower, in addition to causing greater wear on the device. Further, if a resource is not fragmented, allocation requests can simply be satisfied by returning a single block from the start of the free area. However, if it is fragmented, the request requires either searching for a large enough free block, which may take a long time, or fulfilling the request by several smaller blocks (if this is possible), which results in this allocation being fragmented, and requiring additional overhead to manage the several pieces.

A subtler problem is that fragmentation may prematurely exhaust a cache, causing thrashing, due to caches holding blocks, not individual data. For example, suppose a program has a working set of 256 KiB, and is running on a computer with a 256 KiB cache (say L2 instruction+data cache), so the entire working set fits in cache and thus executes quickly, at least in terms of cache hits. Suppose further that it has 64 translation lookaside buffer (TLB) entries, each for a 4 KiB page: each memory access requires a virtual-to-physical translation, which is fast if the page is in cache (here TLB). If the working set is unfragmented, then it will fit onto exactly 64 pages (the page working set will be 64 pages), and all memory lookups can be served from cache. However, if the working set is fragmented, then it will not fit into 64 pages, and execution will slow due to thrashing: pages will be repeatedly added and removed from the TLB during operation. Thus cache sizing in system design must include margin to account for fragmentation.

Memory fragmentation is one of the most severe problems faced by system managers.[citation needed] Over time, it leads to degradation of system performance. Eventually, memory fragmentation may lead to complete loss of (application-usable) free memory.

Memory fragmentation is a kernel programming level problem. During real-time computing of applications, fragmentation levels can reach as high as 99%, and may lead to system crashes or other instabilities.[citation needed] This type of system crash can be difficult to avoid, as it is impossible to anticipate the critical rise in levels of memory fragmentation. However, while it may not be possible for a system to continue running all programs in the case of excessive memory fragmentation, a well-designed system should be able to recover from the critical fragmentation condition by moving in some memory blocks used by the system itself in order to enable consolidation of free memory into fewer, larger blocks, or, in the worst case, by terminating some programs to free their memory and then defragmenting the resulting sum total of free memory. This will at least avoid a true crash in the sense of system failure and allow the system to continue running some programs, save program data, etc.

Fragmentation is a phenomenon of system software design; different software will be susceptible to fragmentation to different degrees, and it is possible to design a system that will never be forced to shut down or kill processes as a result of memory fragmentation.

Analogous phenomena

[edit]

While fragmentation is best known as a problem in memory allocation, analogous phenomena occur for other resources, notably processors.[6] For example, in a system that uses time-sharing for preemptive multitasking, but that does not check if a process is blocked, a process that executes for part of its time slice but then blocks and cannot proceed for the remainder of its time slice wastes time because of the resulting internal fragmentation of time slices. More fundamentally, time-sharing itself causes external fragmentation of processes due to running them in fragmented time slices, rather than in a single unbroken run. The resulting cost of process switching and increased cache pressure from multiple processes using the same caches can result in degraded performance.

In concurrent systems, particularly distributed systems, when a group of processes must interact in order to progress, if the processes are scheduled at separate times or on separate machines (fragmented across time or machines), the time spent waiting for each other or in communicating with each other can severely degrade performance. Instead, performant systems require coscheduling of the group.[6]

Some flash file systems have several different kinds of internal fragmentation involving "dead space" and "dark space".[7]

See also

[edit]

References

[edit]

Sources

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Fragmentation (computing)

View on Grokipedia
from Grokipedia
In computing, fragmentation refers to the inefficient utilization of storage or resources caused by non-contiguous allocation of data or blocks, resulting in wasted and degraded . This occurs when free becomes scattered into small, unusable segments due to repeated allocations and deallocations over time. Common in operating systems and storage management, fragmentation manifests in several key forms, including , file systems, and network protocols, each with distinct causes and mitigation strategies. Memory fragmentation, a core issue in dynamic memory allocation, arises during runtime when processes request and release variable-sized blocks from the heap. It is classified into two types: internal fragmentation, where allocated blocks contain unused space due to rounding up requests to fixed sizes (e.g., power-of-two alignments in buddy systems, leading to approximately 25% waste on average), and external fragmentation, where free exists in scattered holes too small for new requests despite sufficient total free space. Causes include poor allocation policies like next-fit scanning, which fails to coalesce adjacent free blocks effectively, potentially resulting in over 50% fragmentation in simple segregated allocators. Effects encompass increased consumption, frequent page faults, and reduced system throughput, though modern allocators (e.g., those using best-fit with address-ordered lists) can limit fragmentation to under 1%. File system fragmentation occurs when files are stored in non-adjacent disk clusters, often as disks fill and free space becomes dispersed. This leads to slower read/write operations, as disk heads must seek multiple locations, increasing access times and overall system latency. Larger cluster sizes mitigate fragmentation but exacerbate internal waste (slack space), for instance, a 69 KB file in 4 KB clusters wastes up to 3 KB per file. tools rearrange files into contiguous blocks; operating systems like Windows perform this automatically weekly, while macOS employs adaptive clustering to minimize the need. In networking, IP fragmentation divides oversized datagrams into smaller fragments to fit the (MTU) of intermediate links, such as when a packet exceeds bytes on Ethernet. Each fragment carries an identifier, offset, and flags to enable reassembly at the destination, but this process introduces overhead, vulnerability to attacks (e.g., via malformed fragments), and potential if not all parts arrive. Modern protocols like discourage fragmentation by relying on to avoid it altogether. Other contexts, such as database fragmentation, involve partitioning relations horizontally or vertically across distributed sites to optimize query performance and locality, reducing data transfer in multi-site environments. Overall, while fragmentation enhances flexibility in resource use, its management through techniques like compaction, coalescing, or preventive allocation policies remains essential for efficient computing systems.

Fundamentals

Definition and Basic Principle

Fragmentation in refers to the inefficient utilization of or storage resources, where available space becomes divided into non-contiguous blocks or includes underutilized portions within allocated units, resulting in wasted capacity and operational inefficiencies. This phenomenon arises primarily in operating systems during dynamic , where processes or files are loaded and unloaded, leaving behind fragmented free space that cannot be effectively reused for new requests despite sufficient total availability. The basic principle of fragmentation stems from the repeated allocation and deallocation of resources in systems employing contiguous . In fixed partitioning, memory is pre-divided into static blocks of equal or predefined sizes, where a may not fully utilize its assigned partition, creating internal waste; conversely, variable partitioning allows dynamic sizing of blocks to match needs, but repeated deallocations scatter free into small, isolated "holes" that aggregate external waste. This can be analogized to a where cars of varying lengths arrive and depart: after several cycles, empty spots become too small for larger vehicles, even if the total empty area suffices, illustrating how deallocation disrupts contiguity and . Key metrics for assessing fragmentation include the fragmentation index, which quantifies the degree of scatter in free —such as the free memory fragmentation index (FMFI) that measures the of fragmented free space to total free space, often approaching 1 in highly fragmented states—and compaction overhead, representing the time and resource costs of rearranging allocated blocks to consolidate free space. These metrics provide a foundational way to evaluate efficiency in schemes, serving as prerequisites for understanding fragmentation's broader implications across internal, external, and data variants.

Historical Development

Fragmentation in originated in the 1960s with early mainframe systems employing fixed memory partitioning, where memory was divided into static blocks to support multiprogramming, leading to internal fragmentation as unused portions within partitions went wasted. IBM's OS/360, introduced in , exemplified this approach, relying on fixed partitions without relocation hardware, which exacerbated fragmentation and necessitated manual management or swapping techniques to mitigate inefficiencies. The 1970s marked a pivotal shift with the advent of systems, introducing paging and segmentation to address limitations of fixed partitioning while inadvertently creating external fragmentation, particularly in swapping mechanisms where free memory holes accumulated. , developed from 1965 and operational by 1969, pioneered combined segmentation and paging on the 645, using 1024-word pages to reduce fragmentation by enabling demand loading and efficient space reclamation, though external holes persisted in non-contiguous allocations. Early UNIX implementations, starting in 1969 and evolving through the 1970s, initially relied on swapping entire processes, amplifying external fragmentation until paging was added in Version 6 (1975), drawing from influences to improve memory utilization. Influential analyses during this era, such as Donald Knuth's 1968 examination in The Art of Computer Programming, Volume 1, provided foundational insights into dynamic storage allocation, quantifying fragmentation risks in sequential-list and buddy systems, where allocation patterns led to irreducible waste averaging 50% or more in worst cases. Edsger Dijkstra's 1968 work on the THE multiprogramming system further advanced compaction algorithms, proposing layered structures with on-the-fly garbage collection to coalesce free space and combat external fragmentation in real-time environments. By the 1980s and 1990s, fragmentation extended to file systems with the widespread adoption of Microsoft's , originating in the late 1970s for floppy disks and formalized in by 1981, where linked cluster chains caused external fragmentation as files grew non-contiguously on hard disks. This prompted the creation of defragmentation tools, such as Norton's SpeedDisk introduced in 1987 as part of , which optimized PC disk layouts by rearranging files to minimize seek times. The shift to in 1993 with reduced but did not eliminate fragmentation through better allocation strategies like extent-based storage, though third-party defragmenters remained essential for performance maintenance. In the post-2000 era, solid-state drives (SSDs) diminished traditional fragmentation impacts due to the absence of mechanical seek penalties, with studies showing negligible performance degradation compared to HDDs, as times remained uniform. Cloud storage and databases introduced new fragmentation paradigms; for instance, MongoDB's sharding, maturing in the , fragmented data across nodes for scalability but required defragmentation commands to reclaim space from deleted or migrated documents, addressing inefficiencies in distributed environments.

Types of Fragmentation

Internal Fragmentation

Internal fragmentation arises in systems when fixed-size allocation units, such as pages or storage blocks, are assigned to or data that require less space than the full unit size, resulting in unused portions within the allocated blocks. This inefficiency occurs because allocation mechanisms often round up requests to the nearest fixed unit to simplify and avoid more complex variable-sized allocations. For instance, in , a requesting 5KB of space might be allocated a 8KB block, leaving 3KB wasted inside that block. A classic example of internal fragmentation appears in paging-based systems, where spaces are divided into fixed-size pages, typically 4KB, and mapped to physical frames of the same size. If a 's total memory needs do not align perfectly with page boundaries—such as a 10KB requiring three 4KB pages but using only 2KB in —the unused space in the last page represents internal fragmentation. Similarly, in file systems using allocation for disk blocks, files are stored in fixed-size clusters (e.g., 4KB), and any file shorter than a multiple of the cluster size will leave the remainder of its final cluster unused, contributing to wasted storage. The amount of internal fragmentation can be quantified for a single allocation as the difference between the block size and the actual payload size, with total waste across multiple blocks calculated as the sum of these differences: waste = \sum (block_size - payload_size) for each allocated block. Under a uniform distribution of request sizes modulo the block size, the expected internal fragmentation per block approaches half the block size on average, as the unused portion is equally likely to be any value from 0 to block_size - 1. This average waste underscores the space overhead inherent in fixed partitioning. While internal fragmentation trades off usable space for the benefits of eliminating external fragmentation—by ensuring no scattered free holes form between variable-sized allocations—it nonetheless increases overall or storage utilization, often by 10-50% depending on block size and workload. This approach is particularly prevalent in embedded systems, where fixed partitions simplify real-time allocation and reduce overhead in resource-constrained environments, prioritizing predictability over maximal efficiency. Unlike external fragmentation, which hinders allocation due to dispersed free space, internal fragmentation wastes space only within already-allocated units.

External Fragmentation

External fragmentation arises in and storage systems when sufficient free space exists overall, but it is divided into non-contiguous blocks or "holes" separated by allocated regions, making it impossible to satisfy requests for large contiguous blocks. This phenomenon occurs primarily in allocation schemes that require contiguity, such as variable partitioning in memory or contiguous file allocation on disk, where repeated allocations and deallocations fragment the available space into smaller, unusable segments despite ample total free . For instance, in the , while designed to mitigate fragmentation through power-of-two block sizes and coalescing, external fragmentation can still emerge if buddy blocks are not perfectly matched, leading to inefficient use of larger requests. In dynamic memory allocation, algorithms like first-fit exacerbate external fragmentation by scanning the free list from the beginning and allocating the first suitable block, often leaving small holes after deallocations that accumulate over time. Similarly, in file systems employing contiguous allocation, the creation of many small files or frequent file modifications can result in scattered gaps between allocated blocks, where the free space is too dispersed to accommodate larger files without relocation. These examples illustrate how external fragmentation hinders system performance by forcing processes or I/O operations to either fail allocations or resort to costly alternatives like swapping or compaction. The severity of external fragmentation can be quantified using the ratio 1−largest free block sizetotal free space1 - \frac{\text{largest free block size}}{\text{total free space}}, which measures the proportion of free space that is unusable for large requests due to scattering; high values indicate the need for compaction to merge holes and restore contiguity. This metric highlights the inefficiency, as even 50% free space might yield a ratio approaching 1 if the largest hole is minimal compared to total free memory. Detection and mitigation of external fragmentation typically involve maintaining free lists or bitmaps to track available blocks, enabling the to identify and coalesce adjacent free holes immediately after deallocation or when fragmentation thresholds are reached. In explicit free list implementations, coalescing merges neighboring free blocks during scans for allocation or periodic checks, reducing the number of small holes and preserving larger contiguous regions for future requests. Such techniques are essential in both allocators and file systems to prevent progressive degradation, though they incur overhead in traversal and merging operations. Variable partitioning schemes, which adjust block sizes to match requests and thus minimize internal fragmentation, inherently increase the risk of external fragmentation due to the irregular holes they produce.

Data Fragmentation

Data fragmentation refers to the logical division of database tables into smaller, self-contained units called fragments, which are then distributed across multiple sites or nodes to enable parallelism, , and localized data access in systems. This process, often synonymous with sharding in modern contexts, allows portions of data to be processed independently, reducing the load on any single system while maintaining the overall logical structure of the database. The primary types of data fragmentation are horizontal, vertical, and mixed. Horizontal fragmentation involves splitting a table row-wise based on selection predicates, such as key ranges or geographic conditions, where each fragment contains a of rows that satisfy a specific criterion; for instance, records might be divided by to localize queries. Vertical fragmentation partitions the table column-wise according to access patterns, grouping frequently queried attributes together while ensuring each fragment includes the for potential reconstruction; this is useful when different of columns are accessed by different applications. Mixed fragmentation applies both techniques sequentially, first dividing vertically and then horizontally (or vice versa), to create more granular distributions tailored to complex workloads. In relational databases like , table partitioning supports horizontal fragmentation through mechanisms such as range, , or hash partitioning, allowing large tables to be divided for improved manageability and query performance. Similarly, systems like employ horizontal fragmentation via , where data is partitioned into shards assigned to nodes in a ring topology based on hash values of partition keys, ensuring even distribution and without a . Data fragmentation introduces implications for query processing and system design, notably increasing complexity in executing operations that span multiple fragments, such as distributed joins or unions required to reconstruct full relations from scattered pieces. To mitigate access fragmentation and enhance , replication of fragments across nodes is commonly used, though it necessitates mechanisms to maintain consistency, which can add overhead to updates and require careful trade-offs between latency and . This approach parallels inefficiencies in physical storage fragmentation by potentially complicating paths, though it is optimized through query and localization strategies in management systems.

Causes and Mechanisms

In Memory Management

In memory management, fragmentation emerges from the dynamic allocation and deallocation of memory blocks within operating systems, leading to inefficient use of available space. Allocation algorithms play a central role in this process: the first-fit strategy selects the first free block sufficiently large for the request, often resulting in higher external fragmentation by prematurely splitting larger blocks and creating numerous small, scattered holes near the beginning of the free list. In contrast, the best-fit algorithm chooses the smallest adequate free block to minimize immediate waste, though it can still generate many tiny remnants that contribute to external fragmentation over time, with studies showing fragmentation rates around 14% in real traces. The worst-fit approach allocates the largest available block, which tends to deplete sizable free areas and exacerbate external fragmentation by leaving smaller, less usable fragments, performing poorly across various request patterns. Deallocation further intensifies fragmentation by returning used blocks to the free pool as isolated "holes," which, if not merged with adjacent free spaces, remain scattered and unusable for larger requests. Without immediate coalescing— the process of combining neighboring free holes into larger contiguous blocks—these holes persist, accumulating external fragmentation and reducing overall memory utilization, as seen in allocators lacking this mechanism that reach up to 174% fragmentation in synthetic benchmarks. Coalescing upon deallocation is thus critical to reclaiming contiguous space and preventing the long-term scattering of free memory. Virtual memory systems mitigate some fragmentation issues through paging, which divides both virtual and physical into fixed-size pages, thereby reducing external fragmentation by enabling non-contiguous allocation without creating gaps between . However, paging introduces internal fragmentation within individual pages, especially in the last page of a where partial usage wastes an average of half a page per segment. Under high memory pressure from fragmented resources or overcommitment, this can escalate to thrashing, an extreme outcome where the system excessively swaps pages in and out, devoting more cycles to management than computation and severely degrading performance. A notable modern approach to minimizing fragmentation in kernel-level is the slab allocator, adopted in the during the late 1990s, which employs object caching to pre-initialize and store fixed-size kernel objects in contiguous slabs. By segregating objects by size and lifetime, the slab allocator limits internal fragmentation to at most 12.5% per slab—often far less, such as 2.4% for 400-byte objects on 4KB pages—and reduces external fragmentation through efficient reuse and simple reclamation without complex coalescing. This design, originally developed for , enhances allocation speed and memory efficiency in high-frequency kernel operations.

In File Systems and Storage

File system fragmentation arises primarily from routine operations such as file creation, growth, and deletion, which disrupt contiguous block allocation on disk. During file creation, especially when multiple files are written simultaneously, the allocator may fail to secure adjacent blocks, resulting in initial non-contiguous extents; this is exacerbated in systems like , where extents represent up to 128 MB of contiguous blocks but can splinter under concurrent workloads. File growth through appends or extensions often leads to scattered allocation, as intervening writes from other processes fragment available space, forcing new extents to remote locations; for instance, delayed appends after system activity can increase the number of extents per file significantly over time. Deletion further contributes by creating scattered free space holes, which the allocator reuses inefficiently, promoting non-contiguous placement for subsequent allocations and mirroring challenges in dynamic memory allocation where holes lead to external fragmentation. In traditional disk layouts like the (UFS), fragmentation manifests as seek-time issues due to the organization into cylinder groups—sets of consecutive s designed to localize related data and minimize head movement. By allocating file blocks preferentially within the same cylinder group, UFS aims to reduce seek times for accesses, but repeated creations, deletions, and growths scatter blocks across groups, amplifying seek distances and thus seek-time fragmentation as the ages. This layout-induced fragmentation persists even in modern contexts, where non-localized extents increase rotational latency on HDDs. For solid-state drives (SSDs), wear-leveling algorithms distribute writes evenly across flash cells to prevent premature , effectively masking some fragmentation effects by abstracting physical placement; however, this does not eliminate underlying issues, as fragmented extents still trigger more I/O operations and die-level collisions, degrading parallel access efficiency. Studies show fragmentation can reduce SSD performance by over 14 times in severe cases, despite wear-leveling, due to amplified request handling at the controller level. In contemporary environments, such as , object fragmentation occurs when data is stored as numerous small objects, often from incremental writes or streaming processes, leading to inefficient storage and access patterns akin to extent splintering. configurations can amplify these issues, as striping and parity computations require additional I/O across drives for each fragmented extent, increasing and overall overhead during operations like growth or deletion. Fragmentation in file systems like is measured using tools that analyze extent counts, where a file is deemed fragmented if it spans multiple non-contiguous extents; for example, the built-in Optimize Drives utility reports the percentage of fragmented files based on this metric, while ' Contig tool provides per-file extent details to quantify dispersion.

Impacts

Performance Degradation

Fragmentation significantly degrades performance in storage systems by increasing access delays, particularly in hard disk drives (HDDs) where data scattering requires multiple seek operations by the mechanical read/write head. In contiguous layouts, a single seek suffices to access a file, but fragmented files demand seeks for each non-adjacent extent, amplifying latency. Typical HDD seek times range from 4 to 12 milliseconds per operation, but fragmentation can add 10-50 milliseconds or more per additional fragment depending on the number of extents and disk geometry, leading to overall read times that are substantially longer—up to 15 times in severe cases. Throughput suffers as fragmentation elevates computational overhead across system components. In , external fragmentation triggers compaction processes to consolidate free space, incurring linear-time costs proportional to the size of affected blocks and consuming notable CPU cycles—often resulting in reduced allocation and higher latency for memory-intensive applications. Similarly, in databases, index fragmentation disrupts query execution by forcing excessive page reads and scans across scattered , particularly for operations like joins that span multiple fragments, which can halve read throughput for mid-sized objects (e.g., 256 KB to 1 MB) compared to defragmented states. Benchmarks such as those evaluating SQL Server against file systems demonstrate these impacts, showing fragmentation dominating long-term performance as extent counts rise to around 4 per file. The quantitative effects on I/O operations can be modeled conceptually as an increase in total time given by T=tb×(1+f×os)T = t_b \times (1 + f \times o_s), where tbt_b is the base I/O time for contiguous access, ff is the fragmentation factor (e.g., average number of extents minus one), and oso_s is the seek overhead per additional operation; this highlights how even modest fragmentation amplifies costs in random-access workloads. Storage benchmarks, including adaptations of SPEC suites for file-system evaluation, reveal throughput drops of 30-50% or more under fragmented conditions due to elevated I/O counts— for instance, fragmented reads may require 32 times more operations for the same data volume. External fragmentation also contributes to these issues by worsening seek patterns in HDD-based storage. System-wide, fragmentation exacerbates thrashing in environments, where scattered physical frames lead to higher rates as the system struggles to allocate contiguous blocks for incoming pages, diverting CPU resources from useful computation to fault handling and swapping. This feedback loop intensifies under memory pressure, with fragmentation indirectly boosting fault frequency by complicating efficient frame allocation, ultimately throttling overall system responsiveness.

Storage Inefficiency and Reliability Issues

Fragmentation in storage systems contributes to significant capacity waste by rendering portions of available space unusable. Internal fragmentation occurs when fixed-sized allocation blocks, such as pages or clusters in file systems, are assigned to data that does not fully utilize the block, leaving residual unused space within each allocated unit. In paging systems, this waste averages half the page size per allocation under uniform distribution assumptions, potentially reducing overall usable capacity by 10-20% in systems with typical 4KB blocks and mixed workload sizes. External fragmentation exacerbates this inefficiency by scattering free space into non-contiguous small blocks across the disk, preventing the allocation of larger contiguous regions for new files or processes even when total free space exceeds the request size. This can lead to underutilization rates of up to 50% in severely fragmented environments, as the system fails to consolidate free areas effectively. Reliability risks arise from fragmentation's impact on storage media , particularly in contemporary solid-state drives (SSDs). In SSDs, fragmentation strains overprovisioning—the reserved hidden capacity used for and garbage collection—by generating scattered invalid blocks that complicate efficient erasure, potentially accelerating NAND flash and reducing drive lifespan. However, recent studies (as of 2024) show that severe file fragmentation can degrade SSD read performance by up to 79% due to reduced parallelism from die-level collisions, potentially complicating garbage collection and accelerating . Over time, fragmentation manifests in allocation failures and heightened corruption risks, compounding storage challenges. File s may report as full for new allocations despite substantial free space existing in fragmented form, as contiguous blocks of sufficient size are unavailable, leading to denied writes and operational disruptions in environments like Spectrum Scale. Incomplete compaction processes, intended to mitigate fragmentation by reorganizing data, can introduce if interrupted or flawed, particularly in volumes where fragmented compressed files exceed metadata limits, resulting in lost or inconsistent data blocks. Similarly, database s undergoing defragmentation or global compaction have reported issues, including overwritten or inaccessible records due to partial execution on fragmented storage.

Mitigation and Solutions

Defragmentation Techniques

Defragmentation techniques in involve reorganizing fragmented resources to consolidate free space and improve allocation efficiency, primarily in and file systems. In , these methods address external fragmentation by relocating allocated blocks or merging adjacent free areas, while in storage, they rearrange file extents to reduce seek times and enhance I/O throughput. These reactive approaches are crucial for restoring performance lost to scattered data placement.

Memory Techniques

Memory defragmentation primarily relies on compaction and coalescing to mitigate external fragmentation, where free memory is divided into small, non-contiguous blocks unsuitable for larger allocations. Compaction involves relocating live objects to one end of the memory space, thereby consolidating free space into a single contiguous region. A notable example is the Compact-Fit system, which uses last-in-first-out (LIFO) relocation: upon deallocation, freed pages are added to a LIFO free list shared across size classes, allowing reuse without reinitialization and bounding fragmentation to at most one partially full page per class. This technique ensures predictable real-time behavior while reducing fragmentation overhead. Coalescing free lists, common in malloc implementations, merges adjacent free blocks during deallocation or allocation scans to prevent external fragmentation from accumulating. In explicit free list allocators, such as those using boundary tags, coalescing checks neighboring blocks upon freeing a block and combines them if both are free, updating the free list accordingly; deferred coalescing delays this until an allocation request to balance . This method is standard in systems like glibc's ptmalloc.

Storage Methods

File system defragmentation reorganizes scattered file blocks into contiguous extents, distinguishing between offline methods that require system downtime and online methods that operate on live volumes. Offline defragmentation, exemplified by the Windows Defrag utility (introduced in 6.0 in 1993), analyzes the disk layout and relocates files during scheduled maintenance, typically running weekly via Task Scheduler at low priority to minimize disruption. This utility processes and volumes by moving fragmented clusters to sequential positions, potentially improving sequential read speeds by 10-50% on HDDs, though it is less beneficial for SSDs. Online defragmentation enables continuous operation by migrating extents without full system locks, as in Btrfs, where the btrfs filesystem defragment command rewrites file data in the page cache to coalesce extents, leveraging copy-on-write semantics to create linear layouts. This extent migration process flushes dirty pages during syncs, respecting free space availability and avoiding extent sharing in reflinks or snapshots, which can increase storage use but enhances metadata efficiency on rotational drives.

Algorithms

Mark-sweep garbage collection integrates defragmentation through a compaction phase following marking and sweeping, which traces reachable objects and reclaims unreachable ones but leaves fragmented free space. In concurrent variants, such as those in the J9 JVM, post-sweep compaction incrementally slides objects toward the heap base, updating references in parallel to minimize pauses, efficiently reducing fragmentation in benchmarks while preserving throughput. This two-step marking and sweeping with relocation is foundational for languages like , addressing fragmentation that non-moving collectors exacerbate. The two-phase defragmentation algorithm separates analysis from migration to optimize file system reorganization. In the first phase, it scans the volume to identify fragmented files and map optimal contiguous free spaces; the second phase migrates blocks accordingly, minimizing I/O overhead. Tools like FragPicker implement this for modern storage, reducing defragmentation I/O by up to 66% while achieving similar performance improvements as traditional methods.

Tools and Evolution

Early defragmentation tools emerged in the 1980s with MS-DOS's DEFRAG utility in version 6.0, a command-line tool derived from Norton's SpeedDisk that graphically visualized and optimized partitions by sorting files and directories for faster access. Modern evolutions include macOS's automatic handling via the Hot File Adaptive Clustering system in HFS+ and APFS, which proactively defrags files under 20MB during normal operations without user intervention, though larger files may require third-party tools for manual optimization. In contemporary systems, Android's fstrim utility invokes the TRIM command on SSDs/eMMCs to notify the drive of deleted blocks, enabling garbage collection that mitigates write amplification and effective fragmentation, running periodically when idle (e.g., overnight) to sustain performance over time. For SSD-optimized environments, this replaces traditional defragmentation, as rearranging data can accelerate wear; instead, fstrim ensures efficient space reclamation.

Preventive Allocation Strategies

Preventive allocation strategies in systems aim to minimize fragmentation through proactive design choices in and storage management algorithms and hardware architectures. These approaches focus on optimizing how resources are initially assigned to avoid the creation of scattered free spaces or inefficient block usage, thereby maintaining higher utilization and performance over time. By selecting appropriate allocation policies and system structures, fragmentation—particularly external fragmentation in and file systems—can be curtailed without relying on post-allocation remedies. One key allocation policy involves choosing between fitting strategies like first-fit and best-fit to address external fragmentation in dynamic allocation. First-fit allocates the first available block that meets the request , which is computationally efficient but can lead to higher fragmentation by leaving small, unusable remnants scattered throughout . In contrast, best-fit searches for the smallest block that fits the request, theoretically reducing external fragmentation by preserving larger contiguous free spaces for future large allocations. Simulations have shown that best-fit outperforms first-fit in terms of fragmentation for uniform and normal request distributions, with time-memory-product efficiencies differing by 1-3%, though first-fit may be preferable for exponential distributions where large requests are less frequent. Additionally, employing variable block , such as in buddy systems or segregated allocators, helps mitigate internal fragmentation by aligning allocations closely to request , avoiding the waste inherent in fixed- blocks; for instance, power-of-two limits internal waste to less than 50% for larger objects. System-level designs further enhance prevention by structuring allocation mechanisms to promote locality and reuse. In the , the kmalloc function utilizes the slab allocator, which employs segregated free lists to organize memory into size-specific caches, each maintaining a dedicated list of pre-allocated objects. This segregation reduces external fragmentation by ensuring that allocations of similar sizes draw from dedicated pools, minimizing the mixing of small and large blocks that could splinter free space, and enables fast reuse of objects to avoid repeated splitting and coalescing. Similarly, file systems like incorporate (COW) semantics, where modifications create new blocks rather than overwriting existing ones in place, thereby preserving original data contiguity and allowing allocations from fresh, contiguous free space to sidestep incremental fragmentation from partial updates. Hardware adaptations also play a crucial role in concealing or preventing fragmentation at the . Solid-state drives (SSDs) integrate a flash translation layer (FTL) that maps logical addresses to physical pages, dynamically managing , garbage collection, and block remapping to hide fragmentation effects from the host system; advanced FTL designs, such as learning-based variants, further optimize this by compacting mappings and reducing invalid page accumulation, improving overall storage efficiency by up to 1.4 times under varied workloads. In (NUMA) architectures, localizing allocations to the nearest memory node via NUMA-aware allocators prevents cross-node fragmentation and remote access overheads; for example, partitioned approaches in multithreaded environments eliminate and reduce fragmentation by binding allocations to specific domains, enhancing in multi-socket systems. Recent advancements as of include machine learning-based models for predicting fragmentation, such as those using tracing and algorithms in embedded systems, enabling proactive mitigation under high loads. Additionally, extensions like VSwap introduce virtual swapping mechanisms to preemptively address swap fragmentation in virtualized environments. Trade-offs in free space management techniques must be balanced to optimize both fragmentation control and . Bitmap-based management represents free space as bits in an , enabling rapid scanning and allocation of contiguous blocks with constant-time operations for dense storage, but it incurs higher overhead for large address spaces and can struggle with sparse fragmentation patterns. Linked-list methods, conversely, chain free blocks explicitly, facilitating easy coalescing of adjacent frees to combat external fragmentation in sparse scenarios, though they may degrade under high contention due to traversal costs; simulations indicate that hybrid approaches combining bitmaps for small slabs with lists for larger frees can reduce overall fragmentation by several percent compared to pure linked lists. Evaluations through simulations of these preventive strategies, including segregated lists and fitting policies, demonstrate fragmentation reductions of up to 20% in utilization under realistic workloads, underscoring their impact on long-term .

Analogous Phenomena

In networking, packet fragmentation occurs when an IP datagram exceeds the (MTU) of a network link, requiring it to be divided into smaller fragments for transmission and reassembled at the destination. This process is defined in the IPv4 protocol through specific header fields, including the Identification, Fragment Offset, and More Fragments flags, which enable routers to split packets and endpoints to reconstruct them. MTU mismatches along the path often trigger this fragmentation, imposing reassembly overhead such as increased processing at the receiver, potential delays from lost fragments, and higher vulnerability to attacks like fragmentation-based denial-of-service. Similar inefficiencies arise in CPU caching, where cache line fragmentation happens due to misaligned or partial loads that do not fully utilize the fixed-size cache lines, typically 64 bytes on modern x86 processors. This leads to cache pollution, as unused portions of the line occupy space that could hold more relevant , evicting useful cache blocks and increasing miss rates. on spatial locality exploitation highlights how longer cache lines exacerbate pollution by bringing in extraneous , reducing overall hit rates in data-intensive workloads. Separate caching mechanisms have been proposed to mitigate pollution from operations like prefetching, which can fragment line utilization and degrade performance in virtualized environments. In graphics processing, texture fragmentation manifests in GPU memory allocation, where textures—large arrays of —are stored in dedicated pools but fragmented due to varying sizes and frequent allocations/deallocations during rendering pipelines. This reduces contiguous availability, leading to inefficient packing and higher overhead in , particularly in real-time applications like games or simulations. For virtual machines in environments, VM sprawl creates analogous resource fragmentation through scattered instance allocations across physical hosts, resulting in underutilized residual resources and inefficient consolidation. approaches to defragment these residuals model the problem as bin-packing with fragmentation penalties, improving allocation density without full reprovisioning. Emerging in biological computing, DNA storage faces fragmentation-like issues from strand breaks, where chemical degradation or radiation severs oligonucleotide sequences, mimicking data scattering and complicating retrieval. Post-2020 research addresses this by developing error-correcting codes tailored for composite DNA strands, treating breaks as positional errors that disrupt assembly during sequencing. De Bruijn graph-based de novo assembly techniques further enable robust recovery from breaks and rearrangements, ensuring in high-density archival systems despite environmental instabilities.

Comparisons with Other Computing Inefficiencies

Fragmentation in computing systems, particularly in and storage allocation, differs from general computational overheads such as context switching, which primarily consume CPU cycles without directly wasting physical resources. While fragmentation scatters data into non-contiguous blocks, leading to both spatial inefficiency and additional time costs for allocation and access, context switching incurs time overhead through transitions but does not fragment or waste space itself. This distinction highlights fragmentation's unique dual impact on resource utilization, as evidenced in operating systems where fragmented increases management overhead beyond mere switching costs. In contrast to , which uniformly expands program size through redundant or inefficient , leading to higher instruction cache pressure and overall , fragmentation scatters existing data without altering its total volume, exacerbating access latencies in storage or . For instance, in environments like Docker, image layers can introduce storage fragmentation by overlaying changes incrementally, resulting in scattered file representations across layers that hinder efficient I/O, unlike bloat's straightforward size from unoptimized . This layer-based scattering in containers can amplify inefficiencies in union filesystems, where fragmented files persist across snapshots without merging, distinct from bloat's uniform expansion. Data silos in enterprise computing resemble fragmentation superficially by creating access barriers and inefficiencies, but they arise from organizational policies and system isolation rather than physical or logical allocation scattering. Silos trap data in departmental repositories, impeding cross-unit analysis and integration, whereas fragmentation stems from allocation algorithms that break data into non-adjacent units on shared media. This policy-driven isolation in silos leads to duplicated efforts and incomplete views, without the contiguous access penalties inherent to fragmented storage layouts. In virtualized environments, hypervisor-induced fragmentation, such as in ESXi's memory overcommitment, extends beyond traditional allocation issues by involving techniques like ballooning, which reclaim pages from virtual machines under pressure but can fragment physical memory and trigger swapping inefficiencies. Overcommitment allows assigning more than physical availability, relying on ballooning to inflate drivers within VMs and return unused pages to the host; however, aggressive use in 2020s cloud deployments has led to performance degradation from fragmented large pages and increased latency. Studies show that without proactive page breaking, overcommitment exacerbates fragmentation, with techniques like proactive breaking improving performance by up to 2.1x in high-density scenarios, an aspect often underexplored in earlier analyses but critical for modern scaling.

References

  1. https://dl.acm.org/doi/pdf/10.1145/363156.363158
  2. https://www.cs.tufts.edu/~nr/cs257/archive/paul-wilson/fragmentation.pdf
  3. https://www.open.edu/openlearn/science-maths-technology/computing-ict/introducing-computing-and-it/content-section-5.5
  4. https://www.cs.cornell.edu/courses/cs4410/2018su/lectures/lec21-fragmentation.html
  5. https://cseweb.ucsd.edu/classes/fa01/cse222/papers/shannon-frag-sigcommeas01.pdf
  6. https://www.rfc-editor.org/rfc/rfc8201.html
  7. https://dl.acm.org/doi/10.1145/103140.103143
  8. http://www.os-book.com/OS8/os8j/slide-dir/PDF-dir/ch8.pdf
  9. https://www.cs.uic.edu/~jbell/CourseNotes/OperatingSystems/8_MainMemory.html
  10. https://www.cs.gordon.edu/courses/cs322/lectures/memory.html
  11. https://cseweb.ucsd.edu/classes/sp17/cse120-a/applications/ln/lecture11and12.html
  12. https://www.usenix.org/system/files/conference/osdi16/osdi16-kwon.pdf
  13. http://denninginstitute.com/pjd/PUBS/VirtMem_1970.pdf
  14. https://multicians.org/multics-vm.html
  15. https://www.crystallabs.io/unix-history/
  16. https://www.cs.virginia.edu/~cr4bd/4414/S2019/files/fatspec.pdf
  17. https://image-us.samsung.com/SamsungUS/b2b/resource/2013/09/09/White_Paper_SSD-Advantage_Final.pdf
  18. https://www.mongodb.com/docs/manual/core/defragment-sharded-collections/start-defragmenting-sharded-collection/
  19. https://courses.cs.vt.edu/cs3214/videos/Lecture-MemoryAllocation.pdf
  20. https://compas.cs.stonybrook.edu/~nhonarmand/courses/fa17/cse306/slides/06-paging.pdf
  21. https://pages.cs.wisc.edu/~solomon/cs537-old/last/filesys1.html
  22. https://dl.acm.org/doi/pdf/10.1145/1408800.1408893
  23. https://www.cs.umd.edu/class/fall2020/cmsc420-0301/files/memmanage.pdf
  24. https://pontus.digipen.edu/~mmead/www/Courses/CS180/Memory-1.html
  25. https://dl.acm.org/doi/pdf/10.1145/359605.359626
  26. https://www.cs.hmc.edu/~oneill/gc-library/Wilson-Alloc-Survey-1995.pdf
  27. https://www.ece.iastate.edu/~morris/papers/10/ieeetc10.pdf
  28. https://www.cs.cmu.edu/afs/cs/academic/class/15213-f09/www/lectures/17-dyn-mem-6up.pdf
  29. https://www.khoury.northeastern.edu/~pjd/CS5600-text-240905.pdf
  30. https://academicworks.cuny.edu/cgi/viewcontent.cgi?article=1035&context=ny_oers
  31. https://www.postgresql.org/docs/current/ddl-partitioning.html
  32. https://users.cs.northwestern.edu/~pdinda/ics-s05/doc/dsa.pdf
  33. http://web.cs.ucla.edu/classes/spring16/cs111/slides/06_vmem.pdf
  34. https://people.eecs.berkeley.edu/~kubitron/courses/cs194-24-S14/hand-outs/bonwick_slab.pdf
  35. https://www.usenix.org/system/files/fast24-jun.pdf
  36. https://www.usenix.org/conference/fast17/technical-sessions/presentation/conway
  37. https://www.computerworld.com/article/1463629/unix-tip-fragmentation-and-unix-file-systems.html
  38. https://dl.acm.org/doi/10.1145/1555349.1555371
  39. https://aws.amazon.com/blogs/storage/optimizing-storage-costs-and-query-performance-by-compacting-small-objects/
  40. https://past.date-conference.com/proceedings-archive/2019/pdf/0404.pdf
  41. https://www.crucial.com/articles/about-ssd/should-you-defrag-an-ssd
  42. https://legacy.condusiv.com/disk-defrag/fragmentation-impact/
  43. https://www.usenix.org/legacy/event/usenix08/tech/full_papers/craciunas/craciunas_html/paper.html
  44. https://www.cidrdb.org/cidr2007/papers/cidr07p34.pdf
  45. https://www.hotstorage.org/2022/camera-ready/hotstorage22-32/pdf/hotstorage22-32.pdf
  46. https://www.usenix.org/event/fast09/tech/full_papers/agrawal/agrawal.pdf
  47. https://stackoverflow.com/questions/19031902/what-is-thrashing-why-does-it-occur
  48. https://home.adelphi.edu/~siegfried/cs553/553l8.pdf
  49. https://cis.temple.edu/~giorgio/old/cis307s97/readings/stormanagement.html
  50. https://www.geeksforgeeks.org/operating-systems/external-fragmentation-in-os/
  51. https://www.atpinc.com/blog/over-provisioning-ssd-benefits-endurance-and-performance
  52. https://www.ibm.com/docs/en/storage-scale/5.2.2?topic=systems-querying-reducing-file-system-fragmentation
  53. https://condusiv.com/fragmentation-and-data-corruption/
  54. https://www.intersystems.com/product-alerts-advisories/alert-possible-data-integrity-issues-after-compaction-or-defragmentation/
  55. https://www.usenix.org/legacyurl/compacting-real-time-memory-management-system
  56. https://courses.cs.washington.edu/courses/cse351/17au/lectures/25/CSE351-L25-memalloc-II_17au-6up.pdf
  57. https://www.computerhope.com/jargon/d/defrag.htm
  58. https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/defrag
  59. https://btrfs.readthedocs.io/en/latest/Defragmentation.html
  60. https://dl.acm.org/doi/10.1145/1029873.1029877
  61. https://dl.acm.org/doi/10.1145/3611386
  62. https://opensource.com/article/20/2/trim-solid-state-storage-linux
  63. https://arxiv.org/abs/2301.00072
  64. https://dl.acm.org/doi/10.1145/3703935.3704087
  65. https://www.mdpi.com/2076-3417/15/22/12049
  66. https://american.cs.ucdavis.edu/academic/readings/papers/kumar98exploiting.pdf
  67. https://www.nature.com/articles/s41467-022-33046-w
  68. https://dl.acm.org/doi/pdf/10.1145/301589.286864
  69. https://dl.acm.org/doi/10.1145/2362389.2362392
  70. https://people.ucsc.edu/~hlitz/papers/asmdb.pdf
  71. https://docs.docker.com/engine/storage/drivers/btrfs-driver/
  72. https://www.ibm.com/think/topics/data-silos
  73. https://www.oracle.com/database/data-silos/
  74. https://www.vmware.com/files/pdf/perf-vsphere-memory_management.pdf
  75. https://www.researchgate.net/publication/281669290_Proactively_Breaking_Large_Pages_to_Improve_Memory_Overcommitment_Performance_in_VMware_ESXi
  76. https://dl.acm.org/doi/10.1145/3769429
Add your contribution
Related Hubs
User Avatar
No comments yet.