Hubbry Logo
Disk mirroringDisk mirroringMain
Open search
Disk mirroring
Community hub
Disk mirroring
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Disk mirroring
Disk mirroring
Disk mirroring
View on Wikipedia
from Wikipedia
RAID 1 layout

In data storage, disk mirroring is the replication of logical disk volumes onto separate physical hard disks in real time to ensure continuous availability. It is most commonly used in RAID 1. A mirrored volume is a complete logical representation of separate volume copies.

In a disaster recovery context, mirroring data over long distance is referred to as storage replication. Depending on the technologies used, replication can be performed synchronously, asynchronously, semi-synchronously, or point-in-time. Replication is enabled via microcode on the disk array controller or via server software. It is typically a proprietary solution, not compatible between various data storage device vendors.

Mirroring is typically only synchronous. Synchronous writing typically achieves a recovery point objective (RPO) of zero lost data. Asynchronous replication can achieve an RPO of just a few seconds while the remaining methodologies provide an RPO of a few minutes to perhaps several hours.

Disk mirroring differs from file shadowing that operates on the file level, and disk snapshots where data images are never re-synced with their origins.

Overview

[edit]

Typically, mirroring is provided in either hardware solutions such as disk arrays, or in software within the operating system (such as Linux mdadm and device mapper).[1][2] Additionally, file systems like Btrfs or ZFS provide integrated data mirroring.[3][4] There are additional benefits from Btrfs and ZFS, which maintain both data and metadata integrity checksums, making themselves capable of detecting bad copies of blocks, and using mirrored data to pull up data from correct blocks.[5]

There are several scenarios for what happens when a disk fails. In a hot swap system, in the event of a disk failure, the system itself typically diagnoses a disk failure and signals a failure. Sophisticated systems may automatically activate a hot standby disk and use the remaining active disk to copy live data onto this disk. Alternatively, a new disk is installed and the data is copied to it. In less sophisticated systems, the system is operated on the remaining disk until a spare disk can be installed.

The copying of data from one side of a mirror pair to another is called rebuilding or, less commonly, resilvering.[6]

Mirroring can be performed site to site either by rapid data links, for example fibre optic links, which over distances of 500 m or so can maintain adequate performance to support real-time mirroring. Longer distances or slower links maintain mirrors using an asynchronous copying system. For remote disaster recovery systems, this mirroring may not be done by integrated systems but simply by additional applications on primary and secondary machines.

Additional benefits

[edit]

In addition to providing an additional copy of the data for the purpose of redundancy in case of hardware failure, disk mirroring can allow each disk to be accessed separately for reading purposes. Under certain circumstances, this can significantly improve performance as the system can choose for each read which disk can seek most quickly to the required data. This is especially significant where there are several tasks competing for data on the same disk, and thrashing (where the switching between tasks takes up more time than the task itself) can be reduced. This is an important consideration in hardware configurations that frequently access the data on the disk.

See also

[edit]

References

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Disk mirroring

View on Grokipedia
from Grokipedia
Disk mirroring is a technique that replicates data simultaneously across two or more physical disks to ensure redundancy and in the event of a disk . In disk mirroring, also known as RAID 1 (Redundant Array of Independent Disks level 1), a RAID controller or software writes identical copies of data to each disk in the array, presenting them as a single logical volume to the operating system. If one disk fails, the system seamlessly accesses data from the remaining mirror(s) with minimal downtime, supporting high-availability applications such as financial systems and servers. Key advantages of disk mirroring include enhanced data reliability, improved read performance by distributing reads across multiple disks, and straightforward implementation without complex parity calculations. However, it halves usable storage capacity since all space is duplicated (e.g., two 1 TB disks yield only 1 TB of usable space), increases write latency due to simultaneous writes, and raises costs from requiring additional hardware. The concept of disk mirroring predates the formal RAID framework, with early implementations in systems like Tandem Computers' NonStop architecture using mirrored storage for fault tolerance, and it gained widespread adoption following the 1988 UC Berkeley paper "A Case for Redundant Arrays of Inexpensive Disks (RAID)" by David A. Patterson, Garth Gibson, and Randy H. Katz, which proposed RAID levels including mirroring as RAID 1. Today, disk mirroring is implemented in hardware RAID controllers, software solutions like those in Windows or Linux, and applies to both traditional hard disk drives (HDDs) and solid-state drives (SSDs).

Fundamentals

Definition and Purpose

Disk mirroring is a technique that duplicates data across two or more physical disks in real time, creating identical copies to enhance system reliability. This method, also known as RAID 1, ensures that every write operation is simultaneously applied to all mirrored disks, maintaining data consistency without interruption to ongoing processes. The primary purpose of disk mirroring is to provide and by protecting against from single-point failures, such as disk crashes or hardware malfunctions. By keeping exact replicas of data sets readily accessible, it allows for seamless to a surviving disk, minimizing in critical environments like enterprise servers and financial systems. Unlike periodic backups, which capture snapshots at scheduled intervals and require restoration time, disk mirroring delivers real-time for immediate access to current data. This distinction makes mirroring suitable for applications demanding continuous operation rather than long-term archival protection. Disk mirroring was first conceptualized in the within fault-tolerant computing systems, notably through innovations by , which introduced commercial implementations in 1977 to support non-stop .

Basic Mechanism

Disk mirroring maintains identical copies of across multiple physical disks configured as a mirror set, where each disk in the set holds a complete duplicate of the stored . In a fundamental duplex configuration, two disks form the mirror set, with each serving as an identical copy of the . This setup ensures that data blocks are synchronized without striping or interleaving, relying instead on direct replication to provide . The write process in disk mirroring begins when a host system issues a write request for a specific block. The storage controller then simultaneously directs the write operation to all disks in the mirror set, replicating the block on each one in parallel to maintain consistency. For instance, in a two-disk duplex setup, the controller sends the identical and address to both disks, completing the operation only after confirmation from all involved disks, thereby ensuring no divergence in content. This simultaneous replication step is the core of mirroring's redundancy mechanism. Read operations retrieve data from any available disk within the mirror set, allowing flexibility in access. In normal conditions, the controller may distribute read requests across the disks to balance load and improve . In a simple two-disk , this means the read can come from either disk, with the choice often based on proximity or current workload to optimize response times. Mirror sets can scale to triplex configurations with three disks or more, where writes propagate to all members and reads draw from any, further enhancing availability through additional replicas.

Implementation

Hardware Approaches

Hardware-based disk mirroring, commonly implemented through RAID level 1 (RAID 1), relies on dedicated controllers that manage data replication at the level, ensuring that writes to one disk are simultaneously duplicated to a mirror disk without involving the host operating system. These controllers, often in the form of PCIe cards or integrated RAID-on-Chip (ROC) solutions on motherboards, feature their own processors and memory to handle all mirroring operations independently. Dedicated hardware RAID 1 cards, such as LSI MegaRAID or Tri-Mode controllers, offload mirroring tasks from the host CPU, resulting in lower overhead and allowing the processor to focus on application workloads. This offloading enables faster I/O processing, as the controller can access mirrored data from either disk concurrently, maintaining performance during reads while providing redundancy. In integrated setups, motherboard RAID controllers like those in UCS B-Series servers support RAID 1 volumes with 2 disks, configured via utilities for seamless firmware-level management. Enterprise storage arrays exemplify advanced hardware mirroring, with systems from Dell EMC using PERC controllers to duplicate data across physical disks in 1 configurations for high-availability environments. Similarly, NetApp E-Series arrays incorporate dual controllers per enclosure to facilitate hardware-managed mirroring, ensuring data replication across drives in fault-tolerant setups. A key feature of these hardware approaches is support for hot-swappable drives, where failed disks can be replaced without system interruption, as the controller automatically rebuilds the mirror using background resynchronization.

Software Approaches

Software-based disk mirroring implements redundancy by duplicating data writes across multiple storage devices at the operating system or application level, typically without relying on specialized hardware controllers. This approach leverages kernel drivers or modules to intercept (I/O) operations and replicate them to mirror devices, enabling on commodity hardware. Unlike hardware mirroring, software methods offer greater configurability, as they can be dynamically adjusted through administrative tools without physical reconfiguration. In operating system-level implementations, software mirroring is often managed through built-in utilities that create virtual devices aggregating physical disks. For instance, in , the tool configures 1 arrays using the Multiple Devices () driver, which writes identical data to paired disks for redundancy while allowing reads from either for improved performance. Similarly, provides native mirroring within its storage pools, where vdevs (virtual devices) can be configured as mirrors to ensure across multiple disks, integrating seamlessly with its mechanism. On Windows, Dynamic Disks support mirroring via the Disk Management console, converting basic disks to dynamic volumes that duplicate data across partners for . These OS-level tools operate by into the block I/O layer; for example, Linux's md driver uses kernel modules to intercept write requests and synchronously propagate them to all mirrors before acknowledging completion. Application-level mirroring extends redundancy to specific workloads, often at the file system or database layer. The Logical Volume Manager (LVM) in enables mirrored logical volumes by spanning physical extents across devices and replicating data through the device-mapper framework, providing flexibility for resizing and snapshotting alongside mirroring. A key advantage of software mirroring is its adaptability in virtualized environments, where hypervisors like or can provision mirrored storage pools on virtual disks, facilitating and resource pooling without hardware dependencies. This contrasts with hardware offloading, which may limit options in shared virtual infrastructures but offers lower CPU overhead for high-throughput scenarios.

Operational Aspects

Synchronization Processes

Initial synchronization in disk mirroring, also known as the initial mirror or rebuild process, involves copying all data from the primary disk to the secondary disk during setup to establish . This process ensures that both disks contain identical copies before the mirror becomes operational, typically initiated when creating a new mirrored with one pre-existing disk containing data. In Linux's device-mapper RAID implementation, this is triggered by the "sync" parameter during creation, resulting in a full data transfer that populates the secondary disk. Ongoing resynchronization maintains data consistency between mirrored disks by addressing minor discrepancies that may arise from events such as power losses or transient errors, without requiring a full rebuild. This process can be periodic, checking for inconsistencies at predefined intervals, or event-triggered, such as after an unclean shutdown where partial writes might leave mirrors out of alignment. Research on software resynchronization has proposed mechanisms like journal-guided verification to target only affected blocks, replaying outstanding write intentions from the file system's journal to repair inconsistencies efficiently. For instance, after a crash, the system scans the journal to identify and verify modified regions, rewriting data only where discrepancies exist between mirrors. Bitmap tracking enhances resynchronization efficiency by maintaining metadata that records which disk blocks have changed since the last point, allowing the to skip unchanged regions during alignment. This write-intent bitmap divides the disk into fixed-size chunks (e.g., 4KB regions) and sets bits for modified areas, enabling targeted updates rather than scanning the entire volume. In RAID1 implementations, such as those using integration, the bitmap can be combined with discard notifications or interval trees for tracking unused blocks, further optimizing the process by avoiding unnecessary reads and writes on free space. Internal bitmaps in dm-raid, for example, are stored on the disks themselves and managed by a background daemon that updates them during normal operations. The duration of resynchronization is proportional to the disk size and the rate of data changes, with full initial syncs on large drives often taking several hours due to the need to copy terabytes of data sequentially. Bitmap-assisted resyncs significantly reduce this time by limiting operations to altered blocks; for example, in a 2 TiB RAID1 array with 43% utilization, traditional full sync might require 5 hours, while bitmap-optimized methods can complete in about 2 hours by skipping unused areas. In journal-guided approaches for ongoing resyncs, times scale with the journal size rather than the full array, dropping from minutes to seconds for small change sets in multi-gigabyte arrays.

Failure Handling

Failure detection in disk mirroring systems relies on multiple monitoring mechanisms to identify disk issues before or during failure. (SMART) attributes, such as reallocated sector count and error rates, provide predictive indicators of impending drive failure by tracking internal diagnostics like read/write errors and spin-up retries. In RAID implementations, controllers or software layers detect failures through I/O error logs, such as "No such device or address" messages, and validate using checksums to identify silent corruption or read failures on mirrored copies. Hardware controllers generate alerts for persistent read/write errors, marking the affected disk as failed and notifying administrators via system events or lights-out management interfaces. Upon detecting a in a mirrored pair, the failover process automatically redirects all I/O operations to the surviving mirror, ensuring continued read/write access without interruption in well-configured setups. This transparent switchover is managed by the controller or software stack, which degrades the array to a non-redundant state but maintains data availability as long as the remaining disk functions. For example, in LVM 1, the volume remains operational on the healthy device, with policies like raid_fault_policy=allocate attempting to reallocate resources dynamically. After replacing the failed disk, recovery involves inserting the new drive and initiating a rebuild, where is copied from the active mirror to resynchronize the and restore . This , often called resynchronization, can be full (copying all ) or optimized (syncing only changed regions tracked by the driver), and is monitored through tools showing sync percentages. In Solaris Volume Manager, for instance, the metasync command handles this, logging events and allowing resumption after interruptions. In multi-mirror configurations like RAID 10, which stripes data across multiple mirrored pairs, the system can tolerate multiple simultaneous disk without , provided no two failed drives belong to the same mirror pair; failure of both drives in any single pair results in total data unavailability due to the absence of parity reconstruction.

Benefits and Limitations

Key Advantages

Disk mirroring enhances by maintaining identical copies of data across multiple disks, enabling the system to continue operations without even if one disk fails; in N-way configurations, up to N-1 disk failures can be tolerated. A key performance benefit arises from improved read operations, where data can be retrieved in parallel from any of the mirrored disks, potentially doubling the read throughput relative to a single disk setup. Recovery in disk mirroring is straightforward, as the surviving mirror provides an immediate, complete copy of the data without the need for complex parity computations required in schemes like RAID 5. Theoretically, disk mirroring provides 100% redundancy at the block level, contributing to high data availability and positioning it as a preferred solution for mission-critical applications such as and financial systems where is unacceptable.

Primary Drawbacks

Disk mirroring incurs significant storage overhead because it requires complete duplication of all across multiple disks, effectively halving the usable capacity of the storage array. For instance, configuring two 1TB disks in a mirrored setup yields only 1TB of usable space, as the second disk serves solely as an exact replica to ensure . This 100% overhead makes mirroring inefficient for capacity-intensive applications where maximizing storage utilization is critical. Another key limitation is the write performance penalty associated with duplicating I/O operations across all mirrors. Every write must be performed simultaneously on each disk in the mirror set, which can slow throughput to the speed of the slowest participating disk, introducing latency and reducing overall efficiency compared to non-redundant systems. This overhead becomes particularly noticeable in write-heavy workloads, where the parallel nature of the writes does not fully offset the additional synchronization demands. The need for duplicate hardware also drives up costs, as mirroring effectively doubles the number of disks and associated components required, straining budgets in large-scale deployments. For environments with high-capacity needs, this can lead to substantial financial implications without proportional gains in usable storage. Furthermore, while mirroring protects against isolated disk failures, it remains susceptible to correlated failures, such as those arising from shared controller malfunctions or batch defects affecting multiple disks simultaneously. These events can compromise the entire mirror set despite the at the disk level, highlighting a vulnerability to systemic issues beyond individual component faults.

Historical Development

Origins and Early Adoption

Disk mirroring emerged in the late as a key technique for enhancing data availability in fault-tolerant computing systems, predating the formal standards by over a decade. Its development was driven by the need for high reliability in environments where could have severe consequences, such as , , and financial applications requiring uninterrupted . Early implementations focused on duplicating data across multiple disks to protect against hardware failures, ensuring that if one disk or its controller failed, operations could continue seamlessly using the mirror. Tandem Computers pioneered commercial disk mirroring with the introduction of its NonStop I system in 1977, building on the company's founding focus on fault-tolerant architecture since 1974. In Tandem's design, data was stored redundantly on paired disks, each connected to independent controllers and processors, providing multiple paths for access and enabling the system to tolerate failures in disks, channels, or power supplies without data loss. This approach was particularly suited to online transaction processing in financial institutions, such as banks handling high-volume operations, where Tandem systems like the Tandem/16—shipped to Citibank in 1976—demonstrated early success in maintaining continuous availability. In the , disk mirroring gained further traction through adoption in fault-tolerant servers from companies like Stratus Computer, founded in 1980 to extend nonstop computing to broader commercial markets. Stratus systems, such as the Continuous Processing System, incorporated mirrored disks alongside duplicated processors and memory to achieve redundancy, allowing configurations with up to 60 megabytes of mirrored storage per processor and ensuring operations continued during component repairs. These mainframe-era implementations in sectors like and underscored mirroring's role in scaling reliability for mission-critical workloads, with Stratus emphasizing seamless to prevent any perceptible downtime. A pivotal milestone in formalizing disk mirroring came in 1988 with the UC Berkeley paper "A Case for Redundant Arrays of Inexpensive Disks ()" by David A. Patterson, Garth Gibson, and Randy H. Katz, which defined it as RAID level 1 and positioned it as a cost-effective alternative to expensive mainframe storage. The paper highlighted mirroring's established use in systems like Tandem's for , while advocating its integration with arrays of smaller disks to improve performance and affordability in emerging computing environments. This work catalyzed wider industry interest, bridging proprietary early adoptions with standardized approaches.

Modern Evolution

By the 1990s, disk mirroring had been formally incorporated into specifications through efforts like the RAID Advisory Board, established in 1992 to promote the technology and coordinate standardization across implementations. This included integration with interface standards such as SCSI-3, which began development in the early 1990s and provided foundational support for controllers enabling mirroring operations. Similarly, ATA standards, formalized by ANSI starting in 1990, facilitated mirroring via compatible hardware controllers, broadening adoption in consumer and enterprise systems. The evolution of disk mirroring accelerated with the transition to solid-state drives (SSDs) and NVMe interfaces, which addressed latency and throughput limitations of traditional HDD-based mirroring. SSDs enabled faster synchronous replication without the mechanical delays inherent in spinning disks, improving overall system responsiveness in RAID 1 configurations. NVMe further enhanced this by leveraging PCIe for direct CPU access, allowing mirroring setups to achieve sub-millisecond write latencies and higher , particularly in environments. Integration with cloud storage marked another key advancement, exemplified by Amazon EBS volumes, which allow configuration of RAID 1 , though not recommended for additional given EBS's built-in across multiple servers in an Availability Zone. This allowed users to configure mirrored EBS instances for critical workloads, combining cloud scalability with local-like data protection. As of 2025, hybrid has become prominent in (HCI) platforms such as and vSAN, where ensures across mixed HDD and SSD tiers within distributed clusters. In vSAN, for instance, policies default to RAID-1-like object for single-failure protection, optimizing for hybrid storage pools that use SSDs for caching and HDDs for capacity. employs a replication factor of 2 or 3 for equivalent across nodes, supporting hybrid configurations in self-healing clusters. Post-2010, the rise of software-defined storage (SDS) significantly reduced dependence on proprietary hardware for mirroring, enabling implementation via open-source tools like mdadm or on commodity servers. This shift, driven by HCI growth, allowed flexible, cost-effective mirroring without specialized controllers, with market adoption surging as SDS solutions handled petabyte-scale in virtualized environments.

Comparisons and Alternatives

Versus Other RAID Levels

Disk mirroring, also known as RAID 1, provides redundancy by duplicating data across multiple drives, contrasting sharply with 0, which employs striping to distribute data without any . In 0, the full capacity of all drives is utilized for storage, maximizing available space but offering no protection against drive failure, where even a single disk loss results in complete . 1, however, sacrifices half the total capacity in a standard two-drive setup to maintain an exact copy of data on each drive, enabling the system to continue operating seamlessly if one drive fails. While 0 delivers superior read and write performance through parallel operations across drives, 1 matches the speed of a single drive without the performance gains of striping. Compared to RAID 5, which uses parity for single-drive , disk mirroring offers simpler and faster recovery processes, as failed drives can be replaced using direct copies without complex parity recalculation. 5 achieves higher storage efficiency, providing approximately 80% usable space in a five-drive by dedicating only one drive's worth to parity, whereas 1 limits usable capacity to 50% in a two-drive configuration. Although 5 enhances read performance across multiple drives, its write operations are slower due to parity computations, making 1 preferable for workloads prioritizing consistent speed over capacity. The capacity trade-off in disk mirroring is inherent to its design: for an with NN mirrored drives, the usable capacity is given by total raw capacityN\frac{\text{total raw capacity}}{N}, reflecting the duplication required for . This results in progressively lower efficiency as NN increases—for instance, 33% usable space with three drives—while performance remains tied to individual drive capabilities without the scaling benefits of parity-based levels. 1 excels in small-scale deployments demanding high reliability, such as mission-critical applications with limited data volumes, in contrast to 6, which suits larger arrays by tolerating two simultaneous drive failures through dual parity at the expense of added complexity.

Versus Erasure Coding

Disk mirroring and erasure coding represent two distinct approaches to achieving in storage systems, differing primarily in their mechanisms for and storage efficiency. Erasure coding involves distributing across multiple nodes or drives by dividing it into fragments and generating parity information using mathematical algorithms, such as Reed-Solomon codes, which allow reconstruction of lost from the remaining fragments. This method enables tolerance of multiple failures without full duplication, as the parity blocks store only the necessary information to recover erased . In contrast, disk mirroring, as seen in RAID 1 configurations, achieves through complete duplication of data across separate drives, resulting in a storage efficiency of only 50% since every byte of data requires an identical copy. , however, provides comparable with significantly lower overhead; for instance, a common 10+4 erasure code configuration (10 data fragments plus 4 parity fragments) utilizes approximately 71% of total capacity for usable data while tolerating up to 4 simultaneous failures. This efficiency advantage stems from the coding's ability to spread more economically, making it preferable for large-scale environments where storage costs are a primary concern. Use cases for these techniques diverge based on and needs. Disk mirroring excels in scenarios requiring low-latency access, such as local block storage in enterprise servers or , where immediate read/write operations from duplicate copies minimize recovery time. Conversely, erasure coding is optimized for distributed systems like and , where it supports massive ; for example, Ceph employs erasure coding to protect petabyte-scale clusters with reduced replication overhead, and uses it to achieve high durability across geographically dispersed data centers. Erasure coding gained prominence in the as storage demands exploded in and environments, challenging the dominance of by offering a more space-efficient alternative for hyperscale deployments. This shift was driven by advancements in coding efficiency and repair mechanisms, enabling widespread adoption in systems previously reliant on full replication.

References

  1. https://www.techtarget.com/searchstorage/definition/disk-mirroring
  2. https://www.geeksforgeeks.org/operating-systems/disk-mirroring-raid-1/
  3. https://pages.cs.wisc.edu/~remzi/Classes/739/Fall2015/Papers/tandem-TR-90.pdf
  4. https://www.pcmag.com/encyclopedia/term/disk-mirroring
  5. https://dl.acm.org/doi/10.1145/50202.50214
  6. https://www.cs.cmu.edu/~garth/RAIDpaper/Patterson88.pdf
  7. https://www.cs.cornell.edu/courses/cs4410/2011su/slides/lecture18.pdf
  8. https://www.cise.ufl.edu/~jnw/FileSystemsfa02/Lectures/40.html
  9. https://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/c/sw/raid/configuration/guide/b_cisco-ucs-servers-raid-guide.pdf
  10. https://ww1.microchip.com/downloads/aemDocuments/documents/DCS/ProductDocuments/SupportingCollateral/Choosing-the-Right-RAID-Level-00003949A.pdf
  11. https://media.kingston.com/kingston/pdf/ktc-blog-servers-and-data-centers-sds-hardware-software-raid-whitepaper-en.pdf
  12. https://www.enterprisestorageforum.com/hardware/raid-controllers/
  13. https://www.netapp.com/media/19760-tr-4538.pdf
  14. https://docs.kernel.org/admin-guide/md.html
  15. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/managing_storage_devices/managing-raid_managing-storage-devices
  16. https://openzfs.github.io/openzfs-docs/man/7/zpoolconcepts.7.html
  17. https://learn.microsoft.com/en-us/windows/win32/fileio/basic-and-dynamic-disks
  18. https://www.man7.org/linux/man-pages/man8/mdadm.8.html
  19. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/6/html/logical_volume_manager_administration/mirrored_volumes
  20. https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/overview
  21. https://www.kernel.org/doc/Documentation/admin-guide/device-mapper/dm-raid.rst
  22. https://www.usenix.org/legacy/event/fast05/tech/full_papers/denehy/denehy.pdf
  23. https://www.landley.net/kdocs/ols/2012/ols2012-subramanian.pdf
  24. https://support.wdc.com/knowledgebase/answer.aspx?ID=7477
  25. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/configuring_and_managing_logical_volumes/configuring-raid-logical-volumes_configuring-and-managing-logical-volumes
  26. https://www.dell.com/support/manuals/en-us/command-monitor/dcm_rg_10.9.1/alerts-in-dell-command-monitor-1091?guid=guid-f58103ed-b74f-4547-b538-be1f9eaba081&lang=en-us
  27. https://docs.oracle.com/cd/E19120-01/open.solaris/819-2789/about-metadevices-16/index.html
  28. https://www.techtarget.com/searchstorage/definition/RAID-10-redundant-array-of-independent-disks
  29. https://pages.cs.wisc.edu/~ganoop/cs537/RAID.html
  30. https://www.cs.cornell.edu/courses/cs4410/2018su/lectures/lec16-disk.html
  31. https://h3turing.vmhost.psu.edu/312ppts/RAID.pdf
  32. https://www.ou.edu/class/telecomm/lect05j.htm
  33. https://www.ibm.com/docs/ssw_aix_72/performance/perf_impl_disk_mirroring.html
  34. https://www2.cs.uh.edu/~paris/MYPAPERS/StorageSS06.pdf
  35. https://ntrs.nasa.gov/api/citations/19930003352/downloads/19930003352.pdf?attachment=true
  36. https://www.researchgate.net/publication/30051269_On_the_Genesis_of_Organizational_Forms_Evidence_from_the_Market_for_Disk_Arrays
  37. https://fmueller.io/notes/tandem-cpus/
  38. https://connect2nonstop.com/wp-content/uploads/sites/8/2022/03/The-Connection-May-June-2016-web.pdf
  39. https://www.nytimes.com/1984/07/11/business/stratus-s-nonstop-computers.html
  40. https://www.computerhistory.org/storageengine/u-c-berkeley-paper-catalyses-interest-in-raid/
  41. https://www.techmonitor.ai/analysis/industry_body_in_the_wings_for_raid_companies/
  42. https://www.pdl.cmu.edu/RAIDtutorial/Sigarch95.pdf
  43. https://www.spiceworks.com/tech/tech-general/articles/ahci-raid-sata-ide/
  44. https://insights.samsung.com/2023/07/24/is-it-time-to-replace-your-raid-storage-with-ssds-4/
  45. https://www.kingston.com/en/blog/servers-and-data-centers/nvme-raid-redundancy
  46. https://docs.aws.amazon.com/ebs/latest/userguide/raid-config.html
  47. https://www.vmware.com/docs/vmw-vSAN-Availability-Technologies
  48. https://techdocs.broadcom.com/us/en/vmware-cis/vsan/vsan/7-0/vsan-adminstration/using-vsan-policies/about-vsan-policies.html
  49. https://portal.nutanix.com/page/documents/solutions/details?targetId=RA-2078-Cloudera-with-Nutanix:nutanix-storage-redundancy-configuration.html
  50. https://www.starwindsoftware.com/blog/software-defined-storage-guide-to-top-sds-vendors/
  51. https://www.techtarget.com/searchdatabackup/tip/RAID-1-vs-RAID-0-Which-level-is-best-for-data-protection
  52. https://www.techtarget.com/searchdatabackup/tip/RAID-1-vs-RAID-5
  53. https://www.liquidweb.com/blog/raid-level-1-5-6-10/
  54. https://web.eecs.utk.edu/~jplank/plank/papers/Login-2013.pdf
  55. https://www.ibm.com/docs/en/storage-ceph/7.1.0?topic=components-erasure-coding
  56. https://www.backblaze.com/blog/reed-solomon/
  57. https://www.techtarget.com/searchstorage/definition/erasure-coding
  58. https://qumulo.com/blog/erasure-coding-vs-raid-explained/
  59. https://www.bdrshield.com/blog/raid-vs-erasure-coding-vs-replication/
  60. http://fireless.cs.cornell.edu/publications/erasure_iptps.pdf
  61. https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/fault-tolerance
  62. https://ceph.io/en/news/blog/2014/erasure-coding-in-ceph-2/
  63. https://cloud.google.com/blog/products/storage-data-transfer/understanding-cloud-storage-11-9s-durability-target
  64. https://dl.acm.org/doi/10.1145/3708994
  65. https://www.usenix.org/system/files/fast19-zhou.pdf
Add your contribution
Related Hubs
User Avatar
No comments yet.