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

In computing (specifically data transmission and data storage), a block,[1] sometimes called a physical record, is a sequence of bytes or bits, usually containing some whole number of records, having a fixed length; a block size.[2] Data thus structured are said to be blocked. The process of putting data into blocks is called blocking, while deblocking is the process of extracting data from blocks. Blocked data is normally stored in a data buffer, and read or written a whole block at a time. Blocking reduces the overhead and speeds up the handling of the data stream.[3] For some devices, such as magnetic tape and CKD disk devices, blocking reduces the amount of external storage required for the data. Blocking is almost universally employed when storing data to 9-track magnetic tape, NAND flash memory, and rotating media such as floppy disks, hard disks, and optical discs.

Most file systems are based on a block device, which is a level of abstraction for the hardware responsible for storing and retrieving specified blocks of data, though the block size in file systems may be a multiple of the physical block size. This leads to space inefficiency due to internal fragmentation, since file lengths are often not integer multiples of block size, and thus the last block of a file may remain partially empty. This will create slack space. Some newer file systems, such as Btrfs and FreeBSD UFS2, attempt to solve this through techniques called block suballocation and tail merging. Other file systems such as ZFS support variable block sizes.[4][5]

Block storage is normally abstracted by a file system or database management system (DBMS) for use by applications and end users. The physical or logical volumes accessed via block I/O may be devices internal to a server, directly attached via SCSI or Fibre Channel, or distant devices accessed via a storage area network (SAN) using a protocol such as iSCSI, or AoE. DBMSes often use their own block I/O for improved performance and recoverability as compared to layering the DBMS on top of a file system.

On Linux the default block size for most file systems is 4096 bytes. The stat command part of GNU Core Utilities can be used to check the block size.

In Rust a block can be read with the read_exact method.[6] 

const BLOCK_SIZE: usize = 4096;

if let Ok(mut file) = File::open("example.bin")
{
    let mut buf = [0u8; BLOCK_SIZE];
    file.read_exact(&mut buf);
}

In Python a block can be read with the read method. 

BLOCK_SIZE = 4096

with open("example.bin", "rb") as file:
    block = file.read(BLOCK_SIZE)

In C# a block can be read with the FileStream class.[7] 

const int BLOCK_SIZE = 4096;

using FileStream stream = File.Open("example.bin", FileMode.Open);
var block = new byte[BLOCK_SIZE];
await stream.ReadAsync(block, 0, BLOCK_SIZE);

References

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Block (data storage)

View on Grokipedia
from Grokipedia
In , a block is a fixed-length of bytes or bits that serves as the fundamental unit for storing, addressing, and transferring on storage devices such as hard disk drives or solid-state drives. The physical sector size—the smallest unit a can read or write—is commonly 4096 bytes (4 KiB) on modern storage devices, although 512-byte emulation (512e) is often used for . Logical block sizes used by operating systems and file systems are typically 4096 bytes or larger, such as 8192 bytes, to optimize performance and reduce overhead. Each block is assigned a or address, enabling direct access without needing to traverse a file hierarchy. Block storage architectures, which rely on these units, decouple from specific user environments and store blocks independently across systems, often in storage area networks (SANs) or cloud infrastructures. This approach allows for high-speed, low-latency operations, making it ideal for applications requiring raw performance, such as relational databases, virtual machines, and enterprise workloads that demand consistent operations per second (). Unlike file storage, which organizes into hierarchical structures, or , which treats as discrete objects with metadata, block storage provides a raw, unstructured volume akin to a virtual hard drive. The concept of blocks has evolved with storage technology; early magnetic tapes and disks used variable-length records, but fixed-size blocks became standard in modern systems to simplify addressing and error handling. Block sizes influence storage efficiency: larger blocks reduce metadata overhead but can waste space for small files (internal fragmentation), while smaller blocks minimize waste at the cost of increased management complexity. In contemporary cloud environments, block storage services like Amazon Elastic Block Store (EBS) or Block Storage provision scalable volumes with configurable performance tiers.

Definition and Characteristics

Core Definition

In data storage, a block is defined as a fixed-length sequence of bytes or bits that serves as the fundamental unit for organizing and accessing on storage media. This structure allows storage systems to treat the block as an indivisible, atomic entity during read and write operations, enabling efficient management of physical storage space. The primary purpose of using blocks is to minimize overhead in handling, transmission, and storage by aggregating multiple smaller or units into a single contiguous chunk, thereby reducing the frequency of individual I/O operations and associated control information. For instance, on magnetic tapes, blocking groups logical to decrease the number of physical tape movements and inter-block gaps, optimizing and lowering processing time. Unlike variable-length records or continuous data streams, which require dynamic sizing and metadata for each unit, blocks enforce a uniform, predetermined size that simplifies addressing and ensures predictable performance in both sequential and random access scenarios. Block sizes can vary depending on the storage technology and system requirements, typically 512 bytes for physical sectors on hard disks or 4096 bytes for logical blocks in file systems. On traditional media such as magnetic tapes or hard disks, blocks facilitate reliable data retrieval by aligning with the device's native transfer mechanisms, such as sector groupings on disks for random access or record bundling on tapes for streaming.

Key Properties

Blocks in data storage are defined by their structural properties as contiguous sequences of bytes, forming fixed-granularity units that enable uniform across storage media. This organization treats each block as a self-contained, equal-sized chunk with a , allowing independent storage and retrieval without dependency on adjacent data. Operations on these blocks exhibit atomicity, where reads and writes occur entirely on the block level, preventing partial access or modification to maintain consistency during I/O transactions. Error handling in block storage relies on blocks as the primary units for integrity mechanisms, including checksums and error-correcting codes (ECC). Checksums, such as CRC32, are calculated over each block to detect corruptions like bit rot or misdirected writes, with verification performed on every read. In redundant configurations like , blocks within a stripe incorporate parity data for error correction, enabling reconstruction of corrupted blocks by XORing valid ones while re-verifying their checksums. Blocks frequently encompass multiple logical records or file fragments, optimizing space utilization in file systems. To accommodate varying record sizes, unused portions of a block are filled with bytes or delimited to prevent overlap, thereby reducing internal fragmentation without altering the block's fixed structure. By grouping into blocks, storage systems improve in I/O operations, particularly by minimizing seek times through reordered access patterns that prioritize contiguous or nearby block reads. This approach also lowers buffer overhead, as larger block transfers amortize the cost of disk head movements and memory allocations, enhancing throughput for sequential workloads. Alignment of blocks to hardware boundaries further ties into gains by avoiding partial sector reads, though detailed optimization depends on specific system configurations.

Historical Development

Origins in Early Computing

The concept of organizing data into fixed units emerged in the mid-20th century from mechanical data processing precedents, influencing early digital storage designs. In the 1950s, punch cards standardized by IBM at 80 columns per card provided a fixed-size unit for batch data entry and tabulation, ensuring mechanical compatibility and reliability in electromechanical systems like the IBM 407 accounting machine. Similarly, early magnetic tape systems, such as the IBM 726 drive introduced in 1952, grouped data into records mimicking punch card lengths, with blocks separated by interblock gaps of about 25 mm (1 inch) to allow reliable start-stop operations under high acceleration forces exceeding 500 g, thereby minimizing tape wear and errors in vacuum-tube-era hardware. These approaches were motivated by the inefficiencies of byte-by-byte or character-level access in early computing hardware, constrained by limitations and nascent technology, which made frequent mechanical movements slow and prone to failure. Block organization enabled bulk data transfers that approximated natural record sizes, reducing overhead from and detection while optimizing throughput in systems handling large volumes of sequential data. The formal introduction of the "block" as a fundamental unit in digital data storage is credited to Werner Buchholz in IBM's 1962 Project Stretch documentation, where it was defined as the quantity of data—often a multiple of 64 bits—transferred to or from an input-output unit in a single operation, facilitating efficient processing by aligning with typical record lengths and avoiding partial-word transmissions. This definition supported high-speed applications, such as IBM's SABRE airline reservation system deployed in 1964, which relied on block transfers across tapes and disks for real-time transaction handling on IBM 7090 mainframes. One of the earliest standardized implementations of block-based storage was IBM's 9-track format, launched with the 2401 drive in 1964, which structured data into blocks of 8-bit bytes separated by gaps, providing a reliable framework for mainframe data interchange and with prior 7-track systems.

Evolution Across Storage Media

In the , the introduction of hard disk drives (HDDs) marked a significant shift toward more reliable and higher-capacity block storage, with IBM's 3340 model—known for its architecture—pioneering sealed, lubricated disk designs that reduced contamination and enabled consistent block access. This architecture influenced subsequent HDD developments, leading to the widespread of 512-byte sectors as the fundamental block unit by the late 1970s and early , particularly as HDDs transitioned from mainframe environments to broader applications. During the 1980s, removable media like floppy disks further adapted block-based storage to personal computing needs, with sector sizes varying by format: early single-density 5¼-inch disks often used 256-byte sectors with around 10 sectors per track, evolving to 512-byte sectors and 9 to 18 sectors per track in double- and high-density variants by the mid-to-late decade. Optical media emerged concurrently, with compact discs (CDs) introduced in 1982 for audio and in 1985; the standard (1988) specified fixed 2048-byte logical blocks to optimize data density on the 120 mm discs and support up to 74 minutes of audio or equivalent data capacity. This approach carried over to digital versatile discs (DVDs) in the , maintaining 2048-byte blocks while accommodating layered structures for increased storage, up to 4.7 GB per single-layer disc. The transition from mainframe to personal computing in the 1980s and 1990s saw operating systems like UNIX and integrate block storage as a core abstraction, treating disks and tapes as sequences of fixed-size blocks for efficient I/O operations, with 's system originating around 1980 to manage clusters as multiples of 512-byte sectors on HDDs and floppies. UNIX variants similarly adopted block devices during this period to support portable file systems like ext, enabling seamless data handling across diverse hardware. Standardization efforts by ANSI and ISO reinforced these adaptations, with ANSI X3.27 (first issued in 1969 and revised through the 1980s and 1990s) defining labels and file structures for interchange, including block-level record formats up to updates for compatibility with evolving densities. For disks, ISO standards like 9660 (1988) and subsequent amendments through the established block protocols for optical media, ensuring in and transfer.

Technical Implementation

Block Size and Alignment

In data storage systems, the block size refers to the fixed unit of data that storage devices and file systems manage for read and write operations. Historically, hard disk drives (HDDs) used a sector size of 512 bytes as the standard unit, established as the smallest addressable storage element since the inception of modern HDDs. This size facilitated compatibility across early computing hardware and software. In contemporary systems, block sizes have shifted to larger defaults for improved efficiency; for instance, the Linux ext4 file system typically employs a 4 KB (4096 bytes) block size when created with default parameters on modern hardware. Similarly, Microsoft's NTFS file system defaults to a 4 KB cluster size for volumes up to 16 TB, balancing storage density and access speed. Several factors determine block size selection, primarily driven by hardware constraints and performance considerations. Hardware limitations, such as NAND flash memory page sizes ranging from 4 KB to 16 KB in solid-state drives (SSDs), necessitate block sizes that align with these to optimize erase and program operations. Performance trade-offs also play a key role: larger blocks reduce the overhead of metadata management and seek times on HDDs by amortizing fixed costs per I/O operation, but they can increase internal waste for small files. Conversely, smaller blocks minimize unused space per file but elevate the ratio of metadata to data, potentially degrading throughput in high-volume workloads. Block alignment ensures that logical block boundaries in the or coincide with the physical sector boundaries of the underlying storage device, preventing inefficient access patterns. Misalignment occurs when a write operation spans partial sectors, triggering a read-modify-write (RMW) cycle: the reads the entire sector, modifies the relevant portion, and rewrites the sector, which consumes additional bandwidth and latency. This penalty can significantly reduce I/O performance in misaligned scenarios, particularly on drives with 4 KB physical sectors emulating 512-byte logical sectors. Proper alignment, often achieved during partitioning or formatting, eliminates these cycles and enhances overall efficiency. A key implication of fixed block sizes is slack space, which represents internal fragmentation—the unused portion within the last allocated block for a file. The slack space for a given file is calculated as slack=B−(Fmod  B)\text{slack} = B - (F \mod B), where BB is the block size and FF is the file size, provided Fmod  B≠0F \mod B \neq 0; otherwise, slack is zero. For example, with a 4 KB block size, a 5 KB file occupies two blocks (8 KB total), resulting in 3 KB of slack in the second block. A smaller 1 KB file in the same system wastes nearly an entire 4 KB block, highlighting how slack accumulates disproportionately for small files and contributes to storage inefficiency.

Block Addressing and Allocation

In block storage systems, addressing schemes determine how data blocks are located on the underlying hardware. (LBA) is the predominant method in modern storage devices, where blocks are sequentially numbered from 0 to n-1, abstracting away physical details and allowing the operating system to treat the device as a simple array of blocks. This contrasts with physical addressing, which directly references hardware-specific locations, and the legacy (CHS) scheme used in early hard disk drives (HDDs), where blocks were identified by cylinder, head, and sector coordinates to navigate platter geometry. LBA emerged to overcome CHS limitations, such as the 8 GB addressable limit in older implementations, enabling scalable access without hardware reconfiguration. Block allocation methods track and assign free space to ensure efficient use of storage. Bitmap allocation uses a compact where each bit represents the status of one block—typically 1 for free and 0 for allocated—allowing quick scans for available space with minimal overhead for large volumes. Linked allocation chains blocks via pointers stored within each block, forming a list for each allocated unit, which supports dynamic sizing but can degrade performance due to non-contiguous access. Extent-based allocation improves on this by grouping contiguous blocks into extents, reducing metadata overhead and enhancing sequential read/write efficiency compared to purely linked or bitmap approaches alone. Metadata structures maintain mappings between logical addresses and allocated blocks. Superblocks store global information, such as total block count and free space summaries, while inodes serve as per-object descriptors containing block pointers. A representative example is the UNIX inode, which includes 12 direct pointers to data blocks for small allocations, plus single, double, and triple indirect pointers for larger files, enabling addressing of up to millions of blocks without excessive metadata bloat. Deallocation processes reclaim space while preventing overlaps or . In bitmap methods, deallocation flips the corresponding bit to indicate , updating free space counters in the superblock. For linked or extent allocations, pointers are severed, and chains are traversed to mark all affected blocks free. In managed storage like flash-based systems, garbage collection periodically identifies invalid blocks, relocates live data to new locations, and erases obsolete ones to maintain write performance and prevent wear imbalances. These mechanisms ensure atomic updates, often using journaling or to avoid partial failures during deallocation.

Applications in Storage Systems

Block Devices and Interfaces

Block devices are hardware components that provide to fixed-size units of data, known as blocks, typically used for such as hard disk drives (HDDs) and solid-state drives (SSDs). These devices abstract the underlying storage medium, allowing the operating system to interact with them as sequences of addressable blocks, often 512 bytes or multiples thereof, without regard to the physical layout. In systems, block devices are represented as special files in the /dev directory, such as /dev/sda for the first or disk, enabling direct addressing by logical block numbers. Common interfaces for block devices include the , which uses command descriptor blocks (CDBs) to perform operations like reading or writing specific blocks via commands such as READ(10) and WRITE(10). For consumer-grade HDDs, the AT Attachment (ATA) or Integrated Drive Electronics (IDE) interface facilitates block I/O through parallel data transfer modes, supporting up to PIO mode 4 for speeds around 16.6 MB/s in earlier implementations. Networked block access is enabled by protocols like , a high-speed serial interface for storage area networks (SANs) that encapsulates SCSI commands over fiber optic links for block-level transfers, and , which transports SCSI commands over TCP/IP for IP-based SANs. Modern developments include NVMe over Fabrics (NVMe-oF), which provides low-latency, high-performance block access over networks like Ethernet or Fibre Channel for environments. In contrast to character devices, which handle data as a continuous stream of bytes without inherent buffering—such as serial ports or keyboards—block devices employ kernel-level buffering to optimize I/O by caching blocks in memory, reducing direct hardware accesses. This distinction ensures efficient random access for storage operations, as block drivers manage requests in multiples of the block size, while character drivers process data byte-by-byte. Raw access to block devices bypasses higher-level caching in some cases; for instance, the dd command in Linux can copy blocks directly from a device like /dev/sda using syntax such as dd if=/dev/sda of=output.img bs=512, reading and writing fixed block sizes without filesystem intervention. Similarly, programming interfaces allow direct block I/O via the open() system call with the O_DIRECT flag, which enforces aligned buffer access to avoid the page cache and interact straight with the device driver.

Role in File Systems and Databases

In file systems, blocks serve as the fundamental units for organizing and storing both file data and metadata on storage devices. File systems abstract the underlying block devices by mapping logical file structures to these fixed-size blocks, enabling efficient allocation and retrieval. For instance, the (FAT) file system treats clusters—variable-sized groups of blocks—as the basic allocation unit, where each cluster holds file data or directory entries, with the allocation tracked via a table that links clusters sequentially for each file. Similarly, the file system employs blocks for metadata like inodes, which store and pointers to data blocks, while supporting extents—contiguous sequences of blocks—for large files to reduce fragmentation in metadata. In database management systems (DBMS), blocks form the core of data organization, particularly for storing table rows, indexes, and other structures within files or tablespaces. Oracle Database divides storage into data blocks, with a default size of 8 KB, which contain headers, row data, and row directory information; these blocks are grouped into extents and segments to manage table and index storage efficiently. MySQL's InnoDB storage engine uses pages—effectively 16 KB blocks—as the unit for B-tree indexes and clustered tables, where leaf pages hold row data and non-leaf pages store index keys, optimizing for both range scans and point queries. Log-structured merge-trees (LSM-trees), employed in systems like certain NoSQL databases, organize data into immutable block-based sorted string tables (SSTables) that are periodically merged, allowing high write throughput by appending sequential blocks before compaction. To address space inefficiency with small files that do not fill entire blocks, file systems implement suballocation techniques. (now obsolete and removed from the as of 2024) used tail packing, which stores the tail portions of small files or entire small files (up to the available space in a tree node, typically several kilobytes for 4 KB blocks) in unused space within formatted blocks, thereby accommodating multiple small files per block and reducing internal fragmentation. In contrast, leverages (COW) mechanisms, where modifications to small files create new blocks without overwriting originals, enabling efficient snapshotting and deduplication while packing small extents into larger block allocations to minimize waste. Access patterns in file systems significantly influence block I/O efficiency, particularly when comparing journaling and non-journaling designs. Journaling file systems, such as , commit metadata changes to a sequential log before applying them to the main structure, converting random metadata writes into sequential block appends for faster recovery after crashes, though data writes may still involve random block updates. Non-journaling systems, like traditional , rely on direct in-place block modifications, which can lead to slower random access for scattered updates but simpler sequential reads for contiguous files without the overhead of log .

Advanced Concepts and Modern Developments

Fragmentation, Optimization, and Performance

In block storage systems, two primary types of fragmentation affect efficiency and performance. Internal fragmentation, also known as slack space, occurs within allocated blocks when the fixed block size exceeds the actual data size, leaving unused portions wasted. This inefficiency arises because storage allocation rounds up to the nearest full block, resulting in underutilized space that cannot be allocated to other data. External fragmentation, in contrast, involves scattered free blocks across the device, which prevents the allocation of large contiguous regions despite sufficient total free space and increases mechanical seek overhead on traditional hard disk drives. External fragmentation's performance impacts stem from its effect on I/O patterns, where non-contiguous access amplifies latency. In aged systems, fragmentation can cause significant degradation through elevated seek times and I/O bottlenecks, as observed in studies of file system workloads due to scattered block access. Optimization techniques address these issues by reorganizing storage and improving allocation strategies. tools consolidate scattered blocks to restore contiguity; for example, the Windows Defragment and Optimize Drives tool rearranges files to reduce access times. Extent allocation further mitigates external fragmentation by assigning contiguous ranges of blocks as single units rather than individual blocks, as implemented in file systems like , which lowers metadata overhead and seek operations. This approach, building on traditional block allocation methods, groups related data to prevent scattering over time. Block-level caching in operating system kernels provides another layer of performance enhancement by buffering data in memory. In , the stores file blocks as pages, enabling faster reads and writes by serving repeated requests from RAM instead of disk, with readahead mechanisms prefetching blocks to boost sequential I/O throughput by factors of 2-5 in benchmarks. This caching reduces the effective impact of fragmentation by minimizing physical disk accesses during common operations.

Integration with Emerging Technologies

In solid-state drives (SSDs) based on NAND flash memory, block storage aligns with the underlying hardware architecture, where logical blocks map to physical pages typically sized between 4 KB and 16 KB to optimize read and write operations. This alignment ensures efficient data placement, as NAND flash operates on page-level reads and block-level erases, with blocks often comprising 128 to 256 pages. To manage the erase-before-write constraint of NAND cells, SSD controllers employ over-provisioning, reserving extra capacity (typically 7-28% beyond user-accessible space) to facilitate garbage collection and maintain performance. Wear leveling algorithms further distribute write operations evenly across blocks, preventing premature wear on frequently used cells and extending device endurance, often achieving drive writes per day (DWPD) ratings of 3-5 over five years with adequate over-provisioning. The Non-Volatile Memory Express (NVMe) protocol enhances block storage access in high-speed environments by leveraging the (PCIe) interface, enabling direct low-latency communication between host systems and SSDs without the overhead of legacy protocols like or AHCI. NVMe supports up to 64,000 parallel command queues with 64,000 commands per queue, allowing efficient handling of I/O-intensive workloads and reducing protocol latency to microseconds compared to milliseconds in traditional interfaces. This queueing mechanism minimizes CPU utilization and context-switching overhead, making it ideal for block-level operations in data centers where parallel access to storage blocks is critical. Cloud computing has integrated block storage through virtualized services that abstract physical hardware, providing scalable block devices for virtual machines. Amazon Elastic Block Store (EBS) offers persistent block-level storage volumes attachable to EC2 instances, supporting file systems and databases with automatic replication within an Availability Zone for . Similarly, Azure Managed Disks deliver block storage as high-performance volumes for Azure Virtual Machines, with options for premium SSDs achieving up to 20,000 per disk and zone-redundant storage ensuring 99.999% across replicas. These services enable by allowing dynamic volume resizing and multi-terabyte capacities, but distributed block management introduces challenges such as maintaining consistency across replicas and handling latency in cross-region . As of 2025, emerging trends in block storage include Zoned Namespaces (ZNS) in NVMe SSDs, which partition namespaces into fixed-size zones (e.g., 256 MB) for sequential block writes, aligning host commands with NAND erase block boundaries to bypass internal fragmentation. ZNS reduces , minimizes over-provisioning needs, and improves tail latency and throughput by offloading zone management to the host, as specified in the NVMe ZNS Command Set Revision 1.4. Additionally, AI-driven storage systems are incorporating dynamic for block management, using to adapt block sizing and allocation in real-time based on patterns, enhancing in AI training environments with exabyte-scale data.

References

  1. https://aws.amazon.com/what-is/block-storage/
  2. https://www.seagate.com/blog/advanced-format-4k-sector-hard-drives-master-ti/
  3. https://www.ibm.com/think/topics/block-storage
  4. https://www.redhat.com/en/topics/data-storage/file-block-object-storage
  5. https://aws.amazon.com/compare/the-difference-between-block-file-object-storage/
  6. https://www.netmeister.org/book/04-file-systems.pdf
  7. https://www.ibm.com/products/block-storage/features
  8. https://www.cs.ucdavis.edu/~ludaesch/ECS-165A-FQ13/handouts/6-storage.pdf
  9. https://deepblue.lib.umich.edu/bitstream/handle/2027.42/79582/MTSVol19-MagneticTapes-Oct1993.pdf?sequence=1&isAllowed=y
  10. https://digitalpreservation.gov/meetings/DSA2024/DSA2024_CommonTerms.pdf
  11. https://wiki.archlinux.org/title/Advanced_Format
  12. https://www.ibm.com/think/topics/object-vs-file-vs-block-storage
  13. https://pages.cs.wisc.edu/~bpkroth/cs736/md-checksums/md-checksums-paper.pdf
  14. https://www.linuxjournal.com/content/understanding-linux-filesystems-inodes-block-sizes-and-data-structures
  15. https://www.usenix.org/event/usenix09/tech/full_papers/vandebogart/vandebogart.pdf
  16. https://www.ibm.com/history/punched-card
  17. https://bitsavers.org/pdf/ibm/magtape/papers/IBM_TR-82_0243_Introduction_to_Computer_Tape_Recorders_Dec85.pdf
  18. https://ed-thelen.org/comp-hist/IBM-7030-Planning-McJones.pdf
  19. https://www.ibm.com/history/sabre
  20. https://www.computerhistory.org/storageengine/winchester-pioneers-key-hdd-technology/
  21. http://www.os2museum.com/wp/pc-disk-sector-sizes-and-booting/
  22. https://www.dosdays.co.uk/topics/floppy_drives.php
  23. https://elm-chan.org/docs/fat_e.html
  24. https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub79.pdf
  25. https://github.com/Seagate/openSeaChest/wiki/Format%2C-Fast-Format%2C-And-Sector-Sizes
  26. https://blogs.oracle.com/linux/understanding-ext4-disk-layout-part-1
  27. https://learn.microsoft.com/en-us/windows-server/storage/file-server/ntfs-overview
  28. https://documents.westerndigital.com/content/dam/doc-library/en_us/assets/public/western-digital/collateral/white-paper/white-paper-sandisk-flash101-management.pdf
  29. https://www.usenix.org/legacy/event/usenix08/tech/full_papers/agrawal/agrawal.pdf
  30. https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/6-5/performance-best-practices-for-vsphere-6-5/esxi-and-virtual-machines/esxi-storage-considerations/partition-alignment.html
  31. https://inria.hal.science/hal-01460605/document
  32. https://www.cs.williams.edu/~jannen/teaching/s21/cs333/meetings/HDDs.html
  33. https://ww2.coastal.edu/mmurphy2/oer/forensics/evidence/partitions/
  34. https://grouper.ieee.org/groups/802/802_tutorials/2015-11/IEEE802_Tutorial_3_Object_Storage_Drive_2015_11b.pdf
  35. https://web.cs.ucla.edu/classes/spring09/cs111/scribe/12/index.html
  36. https://users.cs.fiu.edu/~cpoellab/teaching/cop4610_fall23/Lecture12-FileSystems2.pdf
  37. https://compas.cs.stonybrook.edu/~nhonarmand/courses/fa17/cse306/slides/17-fs_impl.pdf
  38. https://web.stanford.edu/class/archive/cs/cs111/cs111.1232/lectures/3/Lecture3.pdf
  39. http://www.cs.columbia.edu/~nahum/w4118/s08final-solutions.pdf
  40. https://ranger.uta.edu/~jiang/publication/Journals/2022/IEEE-TCAD%28Remapping%29.pdf
  41. https://lass.cs.umass.edu/papers/pdf/2010RTCSA-flash.pdf
  42. https://man7.org/linux/man-pages/man8/raw.8.html
  43. https://www.t10.org/lists/2op.htm
  44. https://iec.net/home/technical-information/ide-drive-types-difference/
  45. https://www.techtarget.com/searchstorage/tip/iSCSI-vs-Fibre-Channel-What-is-best-choice-for-your-SAN
  46. https://www.enterprisestorageforum.com/hardware/what-is-iscsi-and-how-does-it-work/
  47. https://www.redhat.com/en/topics/storage/what-is-nvme-over-fabrics
  48. https://docs.oracle.com/cd/E19120-01/open.solaris/819-3159/fgoue/index.html
  49. https://www.geeksforgeeks.org/operating-systems/block-and-character-devices-in-operating-system/
  50. https://learn.microsoft.com/en-us/troubleshoot/windows-client/backup-and-storage/fat-hpfs-and-ntfs-file-systems
  51. https://docs.kernel.org/filesystems/ext4/overview.html
  52. https://docs.oracle.com/en/database/oracle/oracle-database/23/refrn/DB_BLOCK_SIZE.html
  53. https://dev.mysql.com/doc/refman/8.4/en/innodb-physical-structure.html
  54. https://www.cs.umb.edu/~poneil/lsmtree.pdf
  55. https://www.funtoo.org/Funtoo_Filesystem_Guide%2C_Part_2
  56. https://www.phoronix.com/news/ReiserFS-Deleted-Linux-6.13
  57. https://btrfs.readthedocs.io/en/latest/Introduction.html
  58. https://www.usenix.org/legacy/event/usenix05/tech/general/full_papers/prabhakaran/prabhakaran.pdf
  59. https://dl.acm.org/doi/10.1145/3611386
  60. https://learn.microsoft.com/en-us/windows/win32/fileio/defragmenting-files
  61. https://blogs.oracle.com/linux/extents-and-extent-allocation-in-ext4
  62. https://docs.kernel.org/filesystems/ext4/allocators.html
  63. https://www.kernel.org/doc/ols/2004/ols2004v2-pages-105-116.pdf
  64. https://download.semiconductor.samsung.com/resources/white-paper/S190311-SAMSUNG-Memory-Over-Provisioning-White-paper.pdf
  65. https://www.netapp.com/data-storage/nvme/what-is-nvme/
  66. https://aws.amazon.com/ebs/
  67. https://learn.microsoft.com/en-us/azure/virtual-machines/managed-disks-overview
  68. https://nvmexpress.org/specification/nvme-zoned-namespaces-zns-command-set-specification/
  69. https://iaeme.com/MasterAdmin/Journal_uploads/IJITMIS/VOLUME_16_ISSUE_2/IJITMIS_16_02_036.pdf
  70. https://www.netapp.com/media/139636-ai-ready-data-storage-infrastructure-idc.pdf
Add your contribution
Related Hubs
User Avatar
No comments yet.