first example
This commit is contained in:
Tech08mag
+10
@@ -0,0 +1,10 @@
|
||||
# Python-generated files
|
||||
__pycache__/
|
||||
*.py[oc]
|
||||
build/
|
||||
dist/
|
||||
wheels/
|
||||
*.egg-info
|
||||
|
||||
# Virtual environments
|
||||
.venv
|
||||
@@ -0,0 +1 @@
|
||||
3.13
|
||||
@@ -0,0 +1,45 @@
|
||||
Hardware:
|
||||
CPU: Ryzen 7 7735HS\
|
||||
GPU: RX 7600S (8GB VRAM)\
|
||||
RAM: 16GB DDR5 4800 MTS (may be used for loading the model)\
|
||||
SWAP: 8 GB (not used)\
|
||||
Modell: https://huggingface.co/Qwen/Qwen3-TTS-12Hz-0.6B-CustomVoice
|
||||
|
||||
|
||||
Example - Cpu \
|
||||
Generation time: 657.36s\
|
||||
Audio duration: 88.64s\
|
||||
Real-time factor: 7.42x\
|
||||
text: cpu\
|
||||
Speaker: Ryan\
|
||||
Language: English\
|
||||
Instruct: read the text in a calm and soothing voice, with a slight emphasis on key points, and maintain a steady pace throughout the narration.\
|
||||
|
||||
Example - Raid\
|
||||
Generation time: 2315.90s\
|
||||
Audio duration: 655.28s\
|
||||
Real-time factor: 3.53x\
|
||||
text: cpu\
|
||||
Speaker: Ryan\
|
||||
Language: English\
|
||||
Instruct: read the text in a calm and soothing voice, with a slight emphasis on key points, and maintain a steady pace throughout the narration.
|
||||
|
||||
Example - [Huggingface](https://huggingface.co/blog/security-incident-july-2026)\
|
||||
Generation time: 1407.29s\
|
||||
Audio duration: 390.40s\
|
||||
Real-time factor: 3.60x\
|
||||
text: huggingface\
|
||||
Speaker: Aiden\
|
||||
Language: English\
|
||||
Instruct: read the text in a calm and soothing voice, with a slight emphasis on key points, and maintain a steady pace throughout the narration.
|
||||
|
||||
Example - [Offener Brief: Microsoft, Nvidia & Co. fordern offenes KI-Ökosystem](https://www.heise.de/news/Offener-Brief-Microsoft-Nvidia-Co-fordern-offenes-KI-Oekosystem-11378076.html)\
|
||||
(offically not supported)\
|
||||
Generation time: 903.47s\
|
||||
Audio duration: 184.40s\
|
||||
Real-time factor: 4.90x\
|
||||
Speaker: Aiden\
|
||||
Language: German\
|
||||
Instruct: read the text in a calm and soothing voice, with a slight emphasis on key points, and maintain a steady pace throughout the narration.
|
||||
|
||||
VRAM Usage is most of the time below 4GB.
|
||||
@@ -0,0 +1,8 @@
|
||||
A CPU (Central Processing Unit) is the main component of a computer that performs the instructions given by programs. It is often called the computer’s processor or main processor. The CPU’s electronic circuits handle tasks such as:
|
||||
|
||||
Arithmetic operations — calculations like addition, subtraction, and other mathematical tasks.
|
||||
Logic operations — making decisions based on comparisons (for example, checking whether one value is greater than another).
|
||||
Control operations — managing and coordinating the activities of other computer components.
|
||||
Input/output (I/O) operations — handling communication between the computer and external devices.
|
||||
|
||||
The CPU works together with other parts of a computer, such as main memory (RAM) and input/output hardware. It is different from specialized processors like graphics processing units (GPUs), which are designed mainly for tasks such as rendering images and accelerating parallel computations. In short, the CPU is the general-purpose “brain” of a computer that runs programs and coordinates system operations.
|
||||
@@ -0,0 +1,12 @@
|
||||
Offener Brief: Microsoft, Nvidia & Co. fordern offenes KI-Ökosystem
|
||||
|
||||
25 US-Tech-Riesen sprechen sich für ein KI-Ökosystem mit Open-Weights-Modellen aus. Ist das die richtige Antwort auf Kimi K3?
|
||||
|
||||
Mit seinem 2,8 Billionen Parameter großen Open-Weights-Modell Kimi K3 kommt das chinesische Start-up Moonshot AI den High-End-KIs von OpenAI und Anthropic gefährlich nahe. Und zwar so nahe, dass seit der Veröffentlichung des Modells am 16. Juli heftige Diskussionen rund um Öffnung, Neuausrichtung und Regulierung der strategisch wichtigen KI-Branche aufflammen: Vor allem die US-Tech-Unternehmen sind sich, je nach Interessenlage und bereits vorhandener oder nur angestrebter Monopolstellung, recht uneinig, wie man der Konkurrenz aus China begegnen soll. Allen ist gemein: Sie sehen die Bedrohung als real, zumindest für das ein oder andere Geschäftsmodell, und so schnell haben sie damit offenbar nicht gerechnet.
|
||||
|
||||
Nun hat eine Allianz von 25 überwiegend US-amerikanischen Tech-Unternehmen einen offenen Brief veröffentlicht. Darin legen sie dar, dass die Vereinigten Staaten ihre Führungsposition im Bereich künstliche Intelligenz nur verteidigen können, wenn sie ein Ökosystem aus offenen Modellen aufbauen – und nicht, indem sie ein einziges bestes System protegieren.
|
||||
|
||||
Zu den Unterzeichnern gehören die Diensteanbieter und Plattformbetreiber Microsoft, Meta, Mistral, Hugging Face sowie die Hardwarekonzerne Nvidia, IBM und Dell, flankiert von den großen Investoren Andreessen Horowitz und Y Combinator. Die Entwickler der technisch führenden Closed-Source-Modelle Anthropic und OpenAI sehen die Dinge naturgemäß anders; sie gehören nicht zu den Unterzeichnern.
|
||||
Mehr Sicherheit, mehr Wettbewerb
|
||||
|
||||
Microsoft, Nvidia & Co. plädieren vor allem aus ökonomischen und aus Sicherheitsgründen für eine Open-Weights-Strategie: Ein Ökosystem aus offenen Modellen würde einen breiten Zugang zu fortgeschrittenen KIs gewährleisten, vom Start-up über Unternehmen jedweder Größe bis hin zu öffentlichen Einrichtungen und von der Farm über Schulen bis hin zum Krankenhaus. Jeder Nutzer könne das für ihn geeignete Modell einsetzen, ohne eines von Grund auf trainieren oder überhöhte Frontier-Model-Preise bezahlen zu müssen. Ein Open-Weights-Ökosystem erhalte den Wettbewerb und garantiere, dass die Gewinne breit verteilt würden, anstatt sich in den Händen einzelner zu konzentrieren. Weil Open-Weights-Modelle von einer ganzen Community aus Forschern und Entwicklern inspiziert werden können, sei es auch leichter, Schwachstellen zu erkennen sowie zu beseitigen – und die Technik langfristig sicherer zu machen.
|
||||
@@ -0,0 +1,39 @@
|
||||
Security incident disclosure — July 2026
|
||||
|
||||
Earlier this week, we detected and responded to an intrusion into part of our production infrastructure. This one was different from anything we had handled before in one important way: it was driven, end to end, by an autonomous AI agent system - and we detected and dissected it largely with AI of our own.
|
||||
|
||||
We identified unauthorized access to a limited set of internal datasets and to several credentials used by our services. We are still completing our assessment of whether any partner or customer data was affected, and we will contact any affected parties directly as required. We have found no evidence of tampering with public, user-facing models, datasets, or Spaces, and our software supply chain (container images and published packages) was verified clean.
|
||||
What happened
|
||||
|
||||
The intrusion started where AI platforms are uniquely exposed: the data-processing pipeline. A malicious dataset abused two code-execution paths in our dataset processing (a remote-code dataset loader and a template-injection in a dataset configuration) to run code on a processing worker. From there, the actor escalated to node-level access, harvested cloud and cluster credentials, and moved laterally into several internal clusters over a weekend.
|
||||
|
||||
The campaign was run by an autonomous agent framework (appearing to be built on an agentic security-research harness - used LLM still not known) executing many thousands of individual actions across a swarm of short-lived sandboxes, with self-migrating command-and-control staged on public services. This matches the "agentic attacker" scenario the industry has been forecasting.
|
||||
What we did
|
||||
|
||||
Fixed the root vulnerability: the dataset code-execution paths used for initial access are closed.
|
||||
Eradicated the attacker's foothold across the affected clusters and rebuilt the compromised nodes.
|
||||
Revoked and rotated the affected credentials and tokens, and began a broader precautionary rotation of secrets.
|
||||
Deployed additional guardrails and stricter admission controls on our clusters.
|
||||
Improved our detection and alerting so a high-severity signal pages a responder in minutes, any day of the week.
|
||||
|
||||
We are working with outside cybersecurity forensic specialists to investigate the issue and review our security policies and procedures. Finally, we have also reported this incident to law enforcement agencies.
|
||||
For our community
|
||||
|
||||
As a precaution, we recommend rotating any access tokens and reviewing recent activity on your account. If you believe you are affected, or want to report a security concern, contact us at security@huggingface.co.
|
||||
|
||||
We are grateful to the teams across Hugging Face who responded around the clock, and we are sorry for any disruption this caused. Security is never finished; we will keep raising the bar.
|
||||
Analyzing an AI-driven intrusion
|
||||
|
||||
The attack was initially surfaced through AI-assisted detection. Our anomaly-detection pipeline uses LLM-based triage over security telemetry to separate real signals from the daily noise, and it was the correlation of those signals that flagged the compromise.
|
||||
|
||||
To understand what a swarm of tens of thousands of automated actions did, we ran LLM-driven analysis agents over the full attacker action log, comprised of more than 17,000 recorded events. This allowed us to reconstruct the timeline, extract indicators of compromise, map the credentials touched, and separate genuine impact from decoy activity. Thanks to this approach, we were able to do in hours what would usually take days, and match the adversary's speed.
|
||||
|
||||
The choice of models we could use for this analysis was constrained in a way we did not anticipate; we describe this below.
|
||||
The asymmetry problem
|
||||
|
||||
When we started the log analysis, we first used frontier models behind commercial APIs. This did not work: the analysis requires submitting large volumes of real attack commands, exploit payloads, and C2 artifacts, and these requests were blocked by the providers' safety guardrails, which cannot distinguish an incident responder from an attacker. We ran the forensic analysis instead on GLM 5.2, an open-weight model, on our own infrastructure. This had a second benefit: no attacker data, and none of the credentials it referenced, left our environment.
|
||||
|
||||
This experience points to a gap worth planning for. We do not know which model powered the attacker's agents, whether a jailbroken hosted model or an unrestricted open-weight one; either way, the attacker was bound by no usage policy, while our own forensic work was blocked by the guardrails of the hosted models we first tried. The practical lesson for defenders: have a capable model you can run on your own infrastructure vetted and ready before an incident, both to avoid guardrail lockout and to keep attacker data and credentials from leaving your environment. This is not an argument against safety measures on hosted models, and we are sharing this feedback with the providers concerned.
|
||||
What this means
|
||||
|
||||
Autonomous, AI-driven offensive tooling is no longer theoretical. It lowers the cost of running a broad, patient, multi-stage campaign, and it operates at machine speed. Defending an online platform now means treating the data and model surface as a first-class attack surface, and using AI on defense to keep pace. We will keep investing there, and keep sharing what we learn.
|
||||
Binary file not shown.
@@ -0,0 +1,35 @@
|
||||
import time
|
||||
import torch
|
||||
import soundfile as sf
|
||||
from qwen_tts import Qwen3TTSModel
|
||||
|
||||
# Load the model
|
||||
model = Qwen3TTSModel.from_pretrained(
|
||||
"Qwen/Qwen3-TTS-12Hz-0.6B-CustomVoice",
|
||||
device_map="cuda:0",
|
||||
dtype=torch.bfloat16,
|
||||
)
|
||||
|
||||
with open("input.txt", "r") as f:
|
||||
text = f.read()
|
||||
f.close()
|
||||
|
||||
# Generate speech with specific instructions
|
||||
start_time = time.perf_counter()
|
||||
wavs, sr = model.generate_custom_voice(
|
||||
text=text,
|
||||
language="English",
|
||||
speaker="Aiden",
|
||||
instruct="read the text in a calm and soothing voice, with a slight emphasis on key points, and maintain a steady pace throughout the narration.",
|
||||
)
|
||||
end_time = time.perf_counter()
|
||||
|
||||
# Save the generated audio
|
||||
sf.write("output_custom_voice.wav", wavs[0], sr)
|
||||
|
||||
# Print timing
|
||||
duration = end_time - start_time
|
||||
audio_duration = len(wavs[0]) / sr
|
||||
print(f"Generation time: {duration:.2f}s")
|
||||
print(f"Audio duration: {audio_duration:.2f}s")
|
||||
print(f"Real-time factor: {duration / audio_duration:.2f}x")
|
||||
@@ -0,0 +1,45 @@
|
||||
[project]
|
||||
name = "tts"
|
||||
version = "0.1.0"
|
||||
description = "Add your description here"
|
||||
readme = "README.md"
|
||||
requires-python = ">=3.13"
|
||||
dependencies = [
|
||||
"accelerate==1.12.0",
|
||||
"fastapi==0.140.0",
|
||||
"gradio==6.17.3",
|
||||
"huggingface-hub==0.36.2",
|
||||
"librosa==0.11.0",
|
||||
"numpy==2.4.6",
|
||||
"onnxruntime==1.28.0",
|
||||
"pandas==3.0.5",
|
||||
"pillow==12.3.0",
|
||||
"protobuf==7.35.1",
|
||||
"pydantic==2.13.4",
|
||||
"pydub==0.25.1",
|
||||
"pyyaml==6.0.3",
|
||||
"qwen-tts==0.1.1",
|
||||
"requests==2.34.2",
|
||||
"safetensors==0.8.0",
|
||||
"scikit-learn==1.9.0",
|
||||
"scipy==1.18.0",
|
||||
"soundfile==0.14.0",
|
||||
"soxr==1.1.0",
|
||||
"torch==2.13.0+rocm7.2",
|
||||
"torchaudio==2.11.0+rocm7.2",
|
||||
"torchvision==0.28.0+rocm7.2",
|
||||
"tqdm==4.69.1",
|
||||
"transformers==4.57.3",
|
||||
"triton-rocm==3.7.1",
|
||||
"uvicorn==0.51.0",
|
||||
]
|
||||
|
||||
[[tool.uv.index]]
|
||||
name = "pytorch-rocm"
|
||||
url = "https://download.pytorch.org/whl/rocm7.2"
|
||||
explicit = true
|
||||
|
||||
[tool.uv.sources]
|
||||
torch = { index = "pytorch-rocm" }
|
||||
torchaudio = { index = "pytorch-rocm" }
|
||||
torchvision = { index = "pytorch-rocm" }
|
||||
@@ -0,0 +1,359 @@
|
||||
Here's a more detailed summary of the Wikipedia article on **RAID (Redundant Array of Independent Disks)**.
|
||||
|
||||
### What is RAID?
|
||||
|
||||
RAID is a storage virtualization technology that combines multiple physical hard drives or SSDs into one logical storage unit. It was originally designed to improve:
|
||||
|
||||
* **Performance** (faster data access)
|
||||
* **Reliability** (protecting against drive failures)
|
||||
* **Availability** (keeping systems running even when a drive fails)
|
||||
|
||||
Originally, RAID stood for **Redundant Array of Inexpensive Disks**, but it is now commonly referred to as **Redundant Array of Independent Disks**. Data is distributed across drives using different techniques called **RAID levels**, each balancing speed, capacity, and fault tolerance differently. ([Harvey Mudd College][1])
|
||||
|
||||
---
|
||||
|
||||
## History
|
||||
|
||||
RAID was introduced in **1987** by researchers at the University of California, Berkeley. At the time, many small, inexpensive disks could be combined to match or outperform a single large, expensive disk (known as a **SLED – Single Large Expensive Disk**). Over time, RAID became a standard feature in servers, enterprise storage systems, and some desktop computers. ([Harvey Mudd College][1])
|
||||
|
||||
---
|
||||
|
||||
## How RAID Works
|
||||
|
||||
RAID organizes data using three main techniques:
|
||||
|
||||
### 1. Striping
|
||||
|
||||
* Data is divided into blocks.
|
||||
* Blocks are spread across multiple drives.
|
||||
* Increases read and write speed because several drives work simultaneously.
|
||||
|
||||
Example:
|
||||
|
||||
| Disk 1 | Disk 2 |
|
||||
| ------- | ------- |
|
||||
| Block 1 | Block 2 |
|
||||
| Block 3 | Block 4 |
|
||||
| Block 5 | Block 6 |
|
||||
|
||||
---
|
||||
|
||||
### 2. Mirroring
|
||||
|
||||
* Every piece of data is copied onto another drive.
|
||||
* If one drive fails, the copy remains available.
|
||||
|
||||
Example:
|
||||
|
||||
| Disk 1 | Disk 2 |
|
||||
| ------ | ------ |
|
||||
| File A | File A |
|
||||
| File B | File B |
|
||||
|
||||
---
|
||||
|
||||
### 3. Parity
|
||||
|
||||
Parity stores extra information that allows lost data to be reconstructed if a drive fails.
|
||||
|
||||
Instead of storing complete copies like mirroring, RAID calculates parity values from the data blocks.
|
||||
|
||||
Example:
|
||||
|
||||
| Disk 1 | Disk 2 | Disk 3 |
|
||||
| ------ | ------ | ------ |
|
||||
| Data A | Data B | Parity |
|
||||
|
||||
If Disk 1 fails, Data A can be rebuilt using Data B and the parity information.
|
||||
|
||||
Parity is much more storage-efficient than mirroring but requires additional calculations.
|
||||
|
||||
---
|
||||
|
||||
# Standard RAID Levels
|
||||
|
||||
## RAID 0 – Striping
|
||||
|
||||
**Minimum disks:** 2
|
||||
|
||||
Features:
|
||||
|
||||
* Fastest RAID level
|
||||
* No redundancy
|
||||
* Uses 100% of storage capacity
|
||||
|
||||
Advantages:
|
||||
|
||||
* Excellent read/write performance
|
||||
* Full disk capacity available
|
||||
|
||||
Disadvantages:
|
||||
|
||||
* If one disk fails, all data is lost
|
||||
|
||||
Typical use:
|
||||
|
||||
* Gaming
|
||||
* Video editing
|
||||
* Temporary data
|
||||
|
||||
---
|
||||
|
||||
## RAID 1 – Mirroring
|
||||
|
||||
**Minimum disks:** 2
|
||||
|
||||
Features:
|
||||
|
||||
* Every disk has an identical copy.
|
||||
* Very reliable.
|
||||
|
||||
Advantages:
|
||||
|
||||
* Survives one disk failure.
|
||||
* Easy recovery.
|
||||
|
||||
Disadvantages:
|
||||
|
||||
* Only 50% of storage is usable.
|
||||
|
||||
Example:
|
||||
|
||||
Two 2 TB drives become **2 TB usable**, not 4 TB.
|
||||
|
||||
---
|
||||
|
||||
## RAID 2
|
||||
|
||||
Uses bit-level striping with error-correcting codes.
|
||||
|
||||
It is rarely used today because modern drives already perform internal error correction.
|
||||
|
||||
---
|
||||
|
||||
## RAID 3
|
||||
|
||||
Uses:
|
||||
|
||||
* Byte-level striping
|
||||
* One dedicated parity disk
|
||||
|
||||
Advantages:
|
||||
|
||||
* High sequential throughput
|
||||
|
||||
Disadvantages:
|
||||
|
||||
* Dedicated parity disk becomes a bottleneck.
|
||||
|
||||
Rarely used today.
|
||||
|
||||
---
|
||||
|
||||
## RAID 4
|
||||
|
||||
Uses:
|
||||
|
||||
* Block-level striping
|
||||
* One dedicated parity disk
|
||||
|
||||
Improves random reads but still suffers from the parity-disk bottleneck.
|
||||
|
||||
---
|
||||
|
||||
## RAID 5
|
||||
|
||||
**Minimum disks:** 3
|
||||
|
||||
Uses:
|
||||
|
||||
* Striping
|
||||
* Distributed parity
|
||||
|
||||
Parity blocks are spread across all drives instead of using one dedicated parity disk.
|
||||
|
||||
Advantages:
|
||||
|
||||
* Good performance
|
||||
* Efficient storage
|
||||
* Can survive one drive failure
|
||||
|
||||
Storage formula:
|
||||
|
||||
**(Number of drives − 1) × Drive size**
|
||||
|
||||
Example:
|
||||
|
||||
Four 4 TB drives → **12 TB usable**
|
||||
|
||||
Disadvantages:
|
||||
|
||||
* Slow rebuild after a failure
|
||||
* A second drive failure during rebuild causes complete data loss
|
||||
|
||||
---
|
||||
|
||||
## RAID 6
|
||||
|
||||
Similar to RAID 5 but stores **two parity blocks**.
|
||||
|
||||
Advantages:
|
||||
|
||||
* Can survive two simultaneous disk failures.
|
||||
* Better suited for very large storage arrays.
|
||||
|
||||
Disadvantages:
|
||||
|
||||
* More storage overhead
|
||||
* Slightly slower writes due to additional parity calculations
|
||||
|
||||
Storage formula:
|
||||
|
||||
**(Number of drives − 2) × Drive size**
|
||||
|
||||
---
|
||||
|
||||
## RAID 10 (1+0)
|
||||
|
||||
Combines:
|
||||
|
||||
* RAID 1 (mirroring)
|
||||
* RAID 0 (striping)
|
||||
|
||||
Requires at least four disks.
|
||||
|
||||
Advantages:
|
||||
|
||||
* Excellent performance
|
||||
* High fault tolerance
|
||||
* Fast rebuilds
|
||||
|
||||
Disadvantages:
|
||||
|
||||
* Only 50% of storage is usable
|
||||
|
||||
Widely used for:
|
||||
|
||||
* Databases
|
||||
* Virtual machines
|
||||
* Enterprise servers
|
||||
|
||||
---
|
||||
|
||||
# Nested RAID Levels
|
||||
|
||||
Some RAID systems combine multiple RAID levels, including:
|
||||
|
||||
* RAID 01
|
||||
* RAID 10
|
||||
* RAID 50
|
||||
* RAID 60
|
||||
|
||||
These combinations aim to balance speed, storage efficiency, and fault tolerance for specific workloads. ([Harvey Mudd College][1])
|
||||
|
||||
---
|
||||
|
||||
# RAID Implementations
|
||||
|
||||
### Hardware RAID
|
||||
|
||||
A dedicated RAID controller manages the array.
|
||||
|
||||
Advantages:
|
||||
|
||||
* Better performance
|
||||
* Less CPU usage
|
||||
* Often includes battery-backed cache
|
||||
|
||||
Disadvantages:
|
||||
|
||||
* More expensive
|
||||
* Hardware failures may require a compatible controller
|
||||
|
||||
---
|
||||
|
||||
### Software RAID
|
||||
|
||||
The operating system manages the RAID.
|
||||
|
||||
Advantages:
|
||||
|
||||
* No special hardware required
|
||||
* Lower cost
|
||||
* Flexible configuration
|
||||
|
||||
Disadvantages:
|
||||
|
||||
* Uses CPU resources
|
||||
* Performance depends on the operating system
|
||||
|
||||
Examples include Linux `mdadm`, Windows Storage Spaces, and ZFS/Btrfs (which provide RAID-like capabilities).
|
||||
|
||||
---
|
||||
|
||||
### Firmware ("Fake RAID")
|
||||
|
||||
Implemented in motherboard firmware with operating system drivers.
|
||||
|
||||
Advantages:
|
||||
|
||||
* Cheaper than dedicated hardware RAID
|
||||
|
||||
Disadvantages:
|
||||
|
||||
* Often offers little performance benefit over software RAID
|
||||
* May have compatibility issues
|
||||
|
||||
---
|
||||
|
||||
# Reliability and Weaknesses
|
||||
|
||||
Although RAID improves reliability, it has limitations:
|
||||
|
||||
### RAID is **not a backup**
|
||||
|
||||
RAID protects against hardware failures but does **not** protect against:
|
||||
|
||||
* Accidental deletion
|
||||
* Malware or ransomware
|
||||
* File corruption
|
||||
* Fire, flood, or theft
|
||||
* Human error
|
||||
|
||||
Regular backups are still essential.
|
||||
|
||||
---
|
||||
|
||||
### Rebuild Time
|
||||
|
||||
When a failed drive is replaced, RAID rebuilds the lost data.
|
||||
|
||||
Modern large-capacity drives (e.g., 20 TB or more) can take many hours or even days to rebuild, during which the array is more vulnerable to additional failures. ([Harvey Mudd College][1])
|
||||
|
||||
---
|
||||
|
||||
### Unrecoverable Read Errors (UREs)
|
||||
|
||||
During a rebuild, if another disk has an unreadable sector, the rebuild may fail—especially in RAID 5. This is one reason RAID 6 is often preferred for large arrays. ([Harvey Mudd College][1])
|
||||
|
||||
---
|
||||
|
||||
## Choosing the Right RAID Level
|
||||
|
||||
| RAID Level | Speed | Fault Tolerance | Storage Efficiency | Typical Use |
|
||||
| ---------- | --------: | --------------: | -----------------: | ---------------------------------- |
|
||||
| RAID 0 | Excellent | None | 100% | High-performance workloads |
|
||||
| RAID 1 | Good | High | 50% | Critical personal or business data |
|
||||
| RAID 5 | Good | One drive | High | General-purpose servers |
|
||||
| RAID 6 | Good | Two drives | Moderate | Large storage systems |
|
||||
| RAID 10 | Excellent | High | 50% | Databases and virtualization |
|
||||
|
||||
### Key Takeaways
|
||||
|
||||
* RAID combines multiple drives to improve **performance**, **availability**, and/or **fault tolerance**.
|
||||
* Different RAID levels use **striping**, **mirroring**, and **parity** in different combinations.
|
||||
* RAID 0 maximizes speed but provides no protection.
|
||||
* RAID 1 focuses on data redundancy through mirroring.
|
||||
* RAID 5 and RAID 6 use parity to balance capacity and reliability.
|
||||
* RAID 10 delivers both high performance and strong redundancy but requires more disks and sacrifices half the raw storage capacity.
|
||||
* RAID helps protect against disk failures, but it is **not a substitute for regular backups**.
|
||||
Reference in New Issue
Block a user