Sources
Defrag Lab is a teaching model. This file says where each number and each claim on the page comes from. Anything marked “model value” is a number chosen to show the shape of an effect. It is not a measurement of any drive. Where a primary source did not confirm a claim, the page says less than the claim, and the item is listed under “Open items resolved”.
Papers and specifications
- Park and Eom, “FragPicker: A New Defragmentation Tool for Modern Storage Devices”, SOSP 2021, pages 280 to 294. DOI 10.1145/3477132.3483593. Used for: most defrag tools migrate whole files, which writes a lot and shortens device life; FragPicker analyzes an application’s I/O and migrates only the data it needs. The SOSP abstract was read (2026-10-04, sigops.org program page) and contains no percentages: it says FragPicker “efficiently reduces the amount of I/Os for defragmentation while achieving a similar level of performance improvement”. The same abstract says the authors found that the slowdown on modern devices “mainly stems from request splitting”. That is the authors’ claim. A FAST 2024 paper (Jun et al., “We Ain’t Afraid of No File Fragmentation”) reports the opposite: request splitting costs little once commands are queued, and the main slowdown on real SSDs comes from die-level collisions, because fragmented files land on non-consecutive dies. The lab models request splitting at queue depth 1 only. The paper does measure a per-request cost at queue depth 1 (85 microseconds per extra request on NVMe), but the lab simulates no die collisions: it assumes every command’s pages spread evenly over the dies.
- Park and Eom, “Filesystem Fragmentation on Modern Storage Systems”, ACM Transactions on Computer Systems 41(1-4), article 3, December 2023. DOI 10.1145/3611386. Used for: FragPicker analyzes the I/O behavior of each application and defragments only necessary pieces; it reduced the I/O spent on defragmentation by around 66% in its YCSB workload C result. Reconfirmed 2026-10-04 from the TOCS abstract: “around 66%” less I/O and “around 84%” less elapsed time on YCSB workload C. The lab does not reproduce either number.
- Hahn et al., “Improving File System Performance of Mobile Storage Systems Using a Decoupled Defragmenter” (janusd), USENIX ATC 2017, pages 759 to 771. Used for: logical fragmentation causes most of the slowdown; janusdL changes the device’s logical-to-physical map to defragment logically without data copies; it needs new commands (its defrag command takes a list of source LBAs and a list of destination LBAs), added through the custom command facilities of SATA and NVMe. The paper evaluated it on emulated eMMC and UFS devices (simeMMC and simUFS, built on an extended Samsung 843T SSD), and reports app launch time cut by up to 53% with under 1% of e4defrag’s data copies. Reconfirmed 2026-10-04 from the paper text. The USENIX page abstract also mentions real Android smartphones, which the lab does not rely on.
- Bjorling et al., “ZNS: Avoiding the Block Interface Tax for Flash-based SSDs”, USENIX ATC 2021. Used for: ZNS groups logical blocks into zones that are written sequentially and erased as a whole, which removes the need for in-device garbage collection.
- NVMe TP4146, Flexible Data Placement, ratified in 2022 (the ratified TP file is dated 2022-11-30 and NVM Express’s bundle of ratified TPs 2022-12-12), and the SNIA white paper “Introduction to Storage Data Placement with FDP”. Used for: the host tags writes with a placement identifier so the drive can keep them in separate reclaim units. The CacheLib documentation reports a write amplification of 1.03 with FDP against 3.22 without it at a 100% cache size on a 1.88TB drive. The lab’s own numbers for placement are model values and are smaller. Reconfirmed 2026-10-04 on the CacheLib “FDP enabled cache” page: at a 930GB cache (50% of the device) the figures are 1.03 with FDP and 1.22 without, and at 1.88TB (100%) they are 1.03 and 3.22. Both are Meta key-value cache traces.
- NVMe Base Specification revision 2.3 (2025-08-01), Identify Controller, MDTS: “the maximum data transfer size for a command that transfers data between host-accessible memory and the controller”, in units of the minimum memory page size (CAP.MPSMIN), reported as a power of two, and “a value of 0h indicates that there is no maximum data transfer size.” The specification gives no default or typical value, so the lab’s 128KiB default and 32KiB to 512KiB range are model values. The earlier mention of one
nvme id-ctrllisting and of an OCP 256KB minimum could not be verified from a primary text and was removed. - NVMe NVM Command Set specification, Copy command (TP4065), read in full from revisions 1.0e (2024-07-29) and 1.2 (2025-07-30). Both: Copy copies data from source ranges to one consecutive destination range; the source LBAs are unchanged; “the number of logical blocks written by the Copy command” is the sum of the ranges; and “the read operations and write operations used to perform the copy may operate sequentially or in parallel”. Copy is a User Data Out command, so destination blocks become allocated like any write. Revision 1.0e says nothing about media writes or remapping. Revision 1.2 adds section 3.3.2.1 “Fast copy operations”: a fast copy is one expected to be no slower than host reads and writes, and its methods “include non-read/write methods such as copy on write snapshot and copy on write clone”. The host can require this with the Fast Copy Only (FCO) bit in a source range entry (the command then aborts with Fast Copy Not Possible if the drive cannot), and a controller sets NVMAFC in ONCS to say all its copies are fast. So the specification allows a drive to implement Copy with no data movement, but never requires it, and a plain Copy gives no guarantee about media writes. The Opcodes for NVM Commands table in 1.2 (Flush, Write, Read, Write Uncorrectable, Compare, Write Zeroes, Dataset Management, Verify, the Reservation commands, Cancel, Copy, I/O Management) has no command that re-points an LBA at existing data, and a text search of 1.2 finds no remap or deduplication command.
Windows
- Microsoft Learn, defrag (page updated 2026-02-16, re-read 2026-10-04), “Scheduled task” section: the process “runs scheduled task as a maintenance task, which typically runs every week”. For SSDs the task does “traditional optimization processes”, including traditional defragmentation and retrim, “once per month”, and “changing the frequency of the scheduled task doesn’t affect the once per month cadence for the SSDs”. A manual defrag between runs makes the next task run do analysis and retrim and skip the defrag. The page states no volume snapshot condition and no fragment threshold. The /L flag is retrim, /O optimizes for the media type, /D is traditional defrag, /K is slab consolidation, /X consolidates free space.
- First-hand check, Windows 11 Pro build 26300, 2026-10-04, read-only (Get-ScheduledTask, Get-WinEvent, reg query; nothing that modifies a volume was run). The task \Microsoft\Windows\Defrag\ScheduledDefrag runs
defrag.exe -c -h -o -$with MaintenanceSettings Period P7D and Deadline P1M, has no fixed trigger, and last ran 2026-10-03. The Application log (provider Microsoft-Windows-Defrag, event 258) holds a “completed defragmentation” and a “completed retrim” message for each of the four NVMe SSD volumes (C, D, E, F) on every run from 2026-07-25 to 2026-10-03: 07-25, 08-01, 08-08, 08-15, 08-22, 08-29, 09-05, 09-12, 09-19, 09-26, 10-03, a 7-day cadence. The pair is logged on D, E and F, which have no shadow copy events at all (the volsnap log has 34 events, all for C), as well as on C, which does have shadow copies. So on this machine the log shows a weekly pair, not a monthly one, and it does not depend on snapshots. The log records that the optimizer reported completion; it does not record how many files a defrag step moved, so it cannot show what the defrag step does to an SSD. The snapshot state of D, E and F is inferred from the absence of volsnap events, because vssadmin and Optimize-Volume -Analyze need elevation and were not run. - Microsoft Learn, Optimize-Volume: the default for an SSD with TRIM support is -ReTrim. -ReTrim generates TRIM and Unmap hints for all currently unused sectors. -Defrag consolidates fragmented regions.
- Scott Hanselman, “The real and complete story: Does Windows defragment your SSD?”, posted 2014-12-03. The statement is in the body of the post, written by an unnamed developer on the Windows storage team (Hanselman says he wrote the post with Windows storage developers). It is not a reader comment, and no name is given. Storage Optimizer will defrag an SSD once a month if volume snapshots are enabled, because of slow volume snapshot copy-on-write performance on fragmented SSD volumes. The post also says TRIM requests can be dropped when the queue is full, and that Storage Optimizer runs a retrim periodically to catch them.
- The lab’s snapshots switch models that 2014 statement as a what-if. It is history: Microsoft Learn lists the SSD defrag without the snapshot condition, the Windows 11 log above shows the same logged result with and without snapshots, and Microsoft publishes no fragment threshold, so the threshold of 6 fragments is a model value.
Model values
| Value | Setting | Source |
|---|---|---|
| Average read seek | 8.5ms | Seagate BarraCuda product manual, “Average seek, read (typical)” under 8.5ms, 7,200rpm. Confirmed 2026-10-04 |
| Half a rotation | 4.16ms | Same manual, average latency 4.16ms at 7,200rpm |
| Sustained transfer | 210MB/s | Seagate BarraCuda 3.5-inch data sheet, 7,200rpm models: “Max Sustained Data Rate, OD Read” 210MB/s to 220MB/s. That is the outer-track maximum, a best case. A product manual lists an average read/write rate of 156MB/s. Confirmed 2026-10-04 |
| NAND page read | 74µs | Frontgrade UT81NDQ512G8T data sheet (4Tb 3D TLC, ONFI 4.0, B17A die, 16KiB page): single-plane READ PAGE time 74µs typical without VPP (73µs with), multi-plane 88µs typical. Other parts differ. The lab applies the figure per page group, so its use is a model |
| Command overhead | 10µs | Model value. No standard or published figure exists: it depends on the host driver and controller firmware |
| Host link | 3.5GB/s | Model value, PCIe 3.0 x4 class |
| Maximum transfer size | 32KiB to 512KiB, default 128KiB | Model value. The NVMe specification defines MDTS but no default; each drive reports its own |
| Windows monthly threshold | 6 fragments | Model value. Not published |
| Geometry | 8 dies, 20 blocks per die, 8 pages per block | Model value. 1,280 pages for 1024 LBAs, so the flash holds 25% more than the volume. The plan’s 8 x 32 x 8 geometry gives 100% spare, and no garbage collection ever has to copy a page |
| Volume | 1024 LBAs of 4KiB | Model value. One LBA is one page |
| GC reserve | 4 free blocks | Model value. Garbage collection runs before a host write when fewer blocks are completely free |
| Garbage collection | Greedy: the closed block with the fewest valid pages, copies within the victim’s die | Standard textbook policy |
| File sizes | 24 to 96 blocks | Model value |
| Interleave chunk | 2 to 8 blocks | Model value. Two files written at once grow a chunk at a time |
| Short-lived files | 30% | Model value |
| A month of use | 40 rounds of delete-and-create, plus 500 random overwrites | Model value |
| Random overwrites in chapter 5 | 2000 random overwrites | Model value |
| A week of hot and cold writes | 8000 writes over 90% of the volume | Model value |
| Hot region | 10% of the live blocks take 90% of the writes | Model value |
| Access trace | 80 reads, 20% of the files taking 80% of the reads, 8 to 32 blocks each | Model value |
| Volume fullness slider | 30 to 90% in steps of 5 | Chosen so the drive always has room to work |
| Age slider | 0 to 12 rounds | Rounds of deleting a file and writing two new ones |
Existing site wording the lab stays consistent with
- Flash Foundations Part 7: TRIM does not erase anything on its own, and the controller decides when to erase. The lab says the same about TRIM. Part 7 gives write amplification ranges of 2.0 to 3.0 at 28% over- provisioning (one measured SSD, 2.466, Park et al.) and 4.0 to 10 or more at 7% (a model-derived range) for uniform random writes. The lab’s drive has 25% spare and a milder workload, so its numbers are lower and are model values.
- TRIM Check: ReTrim re-sends TRIM for all free space, the same job Windows runs on a schedule. The lab says ReTrim is not a defrag.
Open items resolved 2026-10-04
- Windows schedule: resolved. Learn says a weekly task, with SSD defrag and retrim once a month; this Windows 11 machine logs both weekly. The page reports both side by side and does not claim which is the real cadence of the defrag step.
- Windows snapshot dependence: resolved as not documented in any current source and not visible in this machine’s log. The page presents it only as the attributed 2014 statement and a what-if switch.
- 64MB fragment skip: cut, no source.
- NVMe Copy: resolved from the specification text, above.
- janusd and no standard remap: resolved. The paper needs new commands (read earlier from the ATC 2017 text), and NVM Command Set 1.2 lists none.
- NAND read time: resolved from a data sheet (74µs typical). Command overhead and default MDTS: no primary value exists, so both are labeled model values.
- SOSP 2021 abstract numbers: the abstract has none. The 66% is from the TOCS 2023 abstract only.
- Outside what the lab claims: whether FragPicker’s results hold on the drive generations the lab imagines (the lab models the idea, not the tool), and what the Windows defrag step actually moves on an SSD.