💾 Storage Systems — Partie 3 : Organisation logique du stockage

Taxonomie de l’organisation logique

Ordres de grandeur à garder en tête

# Visualiser la pile logique Linux
lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINT,UUID,MODEL
findmnt -R /
blkid
pvs; vgs; lvs -a

Mini-lab pédagogique : comprendre la pile sans risque

# Créer un fichier disque de test, le partitionner, créer un FS et le monter
truncate -s 2G /tmp/lab-disk.img
losetup --find --show /tmp/lab-disk.img
# Supposons /dev/loop10
parted /dev/loop10 --script mklabel gpt mkpart primary ext4 1MiB 100%
mkfs.ext4 -L LABFS /dev/loop10p1
mkdir -p /mnt/labfs
mount /dev/loop10p1 /mnt/labfs
df -hT /mnt/labfs

MBR vs GPT : comparaison d’ingénierie

UEFI, ESP et démarrage

# Linux : voir les entrées UEFI
efibootmgr -v

# Voir le partitionnement et les flags
parted -l
sgdisk -p /dev/nvme0n1

# Exemple ESP dans /etc/fstab
UUID=XXXX-YYYY /boot/efi vfat umask=0077 0 1

Migration MBR → GPT : scénario prudent

# Linux : audit non destructif avant toute action
lsblk -f
parted /dev/sda print
sgdisk -v /dev/sda
cat /etc/fstab
mount | grep boot

Partitions Windows modernes

# PowerShell : inventaire stockage
Get-Disk
Get-Partition
Get-Volume
Get-PhysicalDisk
Get-StoragePool

# Voir BitLocker
Get-BitLockerVolume

BSD : disklabel, GEOM, ZFS

Les systèmes BSD ont historiquement utilisé des disklabels et une couche GEOM puissante. Aujourd’hui, GPT + ZFS est courant pour les serveurs modernes, mais l’administrateur doit comprendre la différence entre slice, partition BSD et partition GPT.

# FreeBSD : audit rapide
gpart show
geom disk list
zpool status
zfs list -t filesystem,snapshot

Alignement 4K / 1MiB : petite erreur, gros impact

Les disques modernes exposent souvent des secteurs logiques de 512 B mais écrivent physiquement en 4 KiB, tandis que les SSD et RAID ont des tailles d’effacement ou de stripe plus grandes. Une partition mal alignée peut provoquer deux opérations physiques pour une écriture logique.

# Vérifier alignement Linux
parted /dev/sdb align-check optimal 1
lsblk -t
blockdev --getss --getpbsz /dev/sdb

Windows : Dynamic Disk, Storage Spaces, ReFS

Windows a progressivement déplacé la logique des volumes depuis Dynamic Disk vers Storage Spaces et Storage Spaces Direct. Pour les environnements modernes, Storage Spaces offre pools, virtual disks, tiers, parity, mirror et intégration PowerShell.

Get-StoragePool
Get-VirtualDisk
Get-PhysicalDisk | Sort-Object HealthStatus
Repair-VirtualDisk -FriendlyName "DataVDisk"

ZFS : pool, vdev, datasets

ZFS n’est pas seulement un système de fichiers : c’est aussi un volume manager transactionnel. Les disques forment des vdevs, les vdevs forment un pool, et les datasets/zvols exposent des espaces fichiers ou blocs.

zpool create tank mirror /dev/disk/by-id/d1 /dev/disk/by-id/d2
zfs create tank/app
zfs set compression=zstd tank/app
zfs set atime=off tank/app
zpool status -v
zpool scrub tank

Thin provisioning : promesse et danger

Le thin provisioning permet d’allouer logiquement plus d’espace que la capacité physique immédiatement disponible. Très utile pour VM, dev/test et cloud interne, mais dangereux sans alerting, car la saturation du pool peut provoquer des erreurs d’écriture brutales.

# LVM thin pool
lvcreate --type thin-pool -L 2T -n thinpool vg_vm
lvcreate --thin -V 500G -n vm01 vg_vm/thinpool
lvs -a -o+seg_monitor,data_percent,metadata_percent

# Autoextend dans lvm.conf à vérifier
# thin_pool_autoextend_threshold
# thin_pool_autoextend_percent

Incidents classiques de couche volume

ext4 vs XFS : choix Linux classique

mkfs.ext4 -L ROOTFS /dev/vg/root
tune2fs -l /dev/vg/root
e2fsck -f /dev/vg/root
resize2fs /dev/vg/root

mkfs.xfs -L DATA /dev/vg/data
xfs_info /srv/data
xfs_growfs /srv/data
xfs_repair -n /dev/vg/data

File systems Copy-on-Write : Btrfs et ZFS

Les systèmes COW écrivent les nouvelles données ailleurs puis basculent les métadonnées de manière transactionnelle. Cela facilite snapshots et checksums, mais peut générer fragmentation et amplification d’écriture si mal tuné.

# Btrfs
btrfs subvolume create /mnt/@data
btrfs filesystem df /mnt
btrfs scrub start -Bd /mnt

# ZFS
zfs list -o name,used,refer,compressratio,mountpoint
zpool status -v
zpool scrub tank

NTFS et ReFS : vision Windows Server

# Windows : informations FS
Get-Volume | Select DriveLetter,FileSystem,HealthStatus,SizeRemaining,Size
fsutil fsinfo volumeinfo C:
fsutil dirty query C:

APFS : design SSD-first Apple

APFS est optimisé pour SSD, chiffrement, snapshots et clones rapides. Sa logique de containers et volumes permet le partage d’espace entre volumes logiques.

# macOS : audit APFS
diskutil apfs list
diskutil info /
tmutil listlocalsnapshots /

Inodes, MFT, metadata : le stockage invisible

Un FS stocke les données, mais aussi beaucoup de métadonnées : propriétaires, permissions, timestamps, extents, index de répertoires, journaux, checksums, snapshots. Les incidents d’espace viennent souvent des métadonnées, pas seulement des octets de fichiers.

df -hT
df -i
find /var -xdev -type f | wc -l
find /var -xdev -size +1G -ls

Journaux ext4 et XFS

tune2fs -l /dev/vg/root | grep -i journal
mount | grep ext4
journalctl -k | grep -i ext4

xfs_info /srv/data
xfs_repair -n /dev/vg/data
xfs_logprint /dev/vg/data | head

Copy-on-Write vs journal classique

ZFS, Btrfs et APFS préfèrent une approche transactionnelle COW : les blocs existants ne sont pas écrasés immédiatement. Les nouveaux blocs et métadonnées sont écrits ailleurs, puis un pointeur atomique valide le nouvel état.

Ordering, barriers, flush et caches contrôleur

Un FS cohérent suppose que les écritures arrivent dans l’ordre attendu sur le support. Les caches disques, contrôleurs RAID, hyperviseurs et SAN peuvent réordonner ou retarder des writes. Les flush/barriers forcent certains points de persistance.

Réparation : méthode froide et prudente

# Ne pas lancer directement une réparation destructrice sur prod
umount /dev/vg/data
fsck -n /dev/vg/data
xfs_repair -n /dev/vg/xfsdata

# Image de secours si possible
ddrescue -f -n /dev/sdb /mnt/rescue/sdb.img /mnt/rescue/sdb.map

Snapshots COW : Btrfs et ZFS

btrfs subvolume snapshot -r /srv/data /srv/.snapshots/data-$(date +%F)
btrfs subvolume list /srv
btrfs send /srv/.snapshots/data-2026-05-02 | btrfs receive /backup

zfs snapshot tank/app@daily-2026-05-02
zfs list -t snapshot
zfs rollback tank/app@daily-2026-05-02
zfs send -R tank/app@daily-2026-05-02 | ssh backup zfs receive backup/app

LVM snapshot : pratique mais à surveiller

Un snapshot LVM classique utilise un espace de copy-on-write séparé. Si cet espace se remplit, le snapshot devient inutilisable. Les thin snapshots sont plus souples, mais dépendent de la santé du thin pool.

# Snapshot classique
lvcreate -s -n lv_app_snap -L 50G /dev/vg_data/lv_app
mount -o ro /dev/vg_data/lv_app_snap /mnt/snap

# Suppression après backup
umount /mnt/snap
lvremove /dev/vg_data/lv_app_snap

# Monitoring
lvs -a -o+origin,data_percent,metadata_percent,seg_monitor

Windows VSS et APFS local snapshots

vssadmin list writers
vssadmin list shadows
Get-ComputerRestorePoint

tmutil listlocalsnapshots /
tmutil deletelocalsnapshots 2026-05-02-210000
diskutil apfs listSnapshots /

Politique de rétention snapshot

La rétention doit être proportionnée au churn, pas seulement au calendrier. Une base de données qui réécrit 20% du volume par jour consommera beaucoup plus qu’un dépôt documentaire froid.

Déduplication : puissante mais dangereuse sans sizing

La déduplication détecte des blocs identiques et ne stocke qu’une copie physique. Elle est excellente pour VDI, sauvegardes, VM similaires, ISO et clones ; elle est souvent inutile sur flux chiffrés ou compressés.

Ratios réalistes par type de données

Tester avant d’activer

On ne choisit jamais compression/dédup sur croyance. Il faut prendre un échantillon représentatif, mesurer ratio, CPU, latence p95/p99 et comportement en restauration.

# Mesurer compression simple sur échantillon
tar -cf - /srv/sample | zstd -T0 -3 -o /tmp/sample.tar.zst
ls -lh /tmp/sample.tar.zst

du -sh /srv/sample

# fio : latence avant/après compression FS
fio --name=randwrite --directory=/srv/data --size=10G --rw=randwrite --bs=4k --iodepth=32 --numjobs=4 --time_based --runtime=120 --group_reporting

fio : benchmark minimal mais sérieux

# Random read 4K, profil IOPS
fio --name=rr4k --filename=/srv/data/fio.test --size=20G --rw=randread --bs=4k --iodepth=64 --numjobs=4 --time_based --runtime=180 --direct=1 --group_reporting

# Sequential write 1M, profil backup/media
fio --name=sw1m --filename=/srv/data/fio.seq --size=50G --rw=write --bs=1M --iodepth=16 --numjobs=1 --direct=1 --group_reporting

# Mixed DB-like
fio --name=mix --filename=/srv/data/fio.mix --size=20G --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --time_based --runtime=180 --direct=1 --group_reporting

Fragmentation logique

La fragmentation augmente les seeks sur HDD et peut accroître les métadonnées / extents sur SSD. Les FS modernes masquent une partie du problème, mais les snapshots COW, VM images et workloads append/delete peuvent générer une fragmentation significative.

Observer la couche logique

# Linux
iostat -xz 1
pidstat -d 1
sar -d 1
bpftrace tools si disponible
journalctl -k | grep -Ei "error|xfs|ext4|btrfs|nvme|scsi"

# FS usage
df -hT
du -xhd1 /var | sort -h
lsof +L1

# Windows PowerShell
Get-Counter '\PhysicalDisk(*)\Avg. Disk sec/Read'
Get-Counter '\LogicalDisk(*)\% Free Space'
Get-Volume
Get-EventLog -LogName System -Source disk -Newest 20

# ReFS/Storage Spaces
Get-VirtualDisk | Get-StorageJob

Chiffrement : couche bloc, FS ou application

# LUKS rapide
cryptsetup luksFormat /dev/sdb1
cryptsetup open /dev/sdb1 cryptdata
mkfs.xfs /dev/mapper/cryptdata

# BitLocker
Enable-BitLocker -MountPoint "D:" -EncryptionMethod XtsAes256

Checksums, bit rot et scrubbing

Un disque peut retourner une donnée techniquement lisible mais incorrecte. Sans checksum bout-en-bout, la corruption silencieuse peut remonter jusqu’à l’application. ZFS et Btrfs détectent ces erreurs ; avec redondance, ils peuvent les réparer automatiquement.

# ZFS scrub
zpool scrub tank
zpool status -v tank

# Btrfs scrub
btrfs scrub start -Bd /srv/data
btrfs scrub status /srv/data

Snapshots immuables et défense ransomware

Un ransomware chiffre les fichiers au niveau logique. Les snapshots permettent un retour rapide si l’attaquant ne peut pas les supprimer. Il faut donc séparer les droits admin applicatifs des droits snapshot/backup.

Kubernetes CSI et volumes persistants

Dans Kubernetes, le stockage persistant est abstrait par PV, PVC, StorageClass et CSI driver. Le choix du FS et du mode d’accès impacte directement les bases de données, les brokers et les workloads stateful.

kubectl get storageclass
kubectl get pv,pvc -A
kubectl describe pvc -n prod data-postgres-0
kubectl get volumesnapshot -A

Overlay filesystems : Docker/containers

Les containers utilisent souvent overlayfs : une couche image read-only et une couche writable. Très efficace pour déploiement, mais inadapté aux données persistantes critiques si utilisé comme stockage principal.

docker system df
docker inspect CONTAINER_ID | jq '.[0].GraphDriver'
du -xhd1 /var/lib/docker | sort -h

Snapshots cloud : pratiques, mais pas toujours application-consistent

AWS EBS snapshots, Azure Managed Disk snapshots et Google Persistent Disk snapshots capturent le bloc. Selon OS et application, il faut quiescer, flush ou utiliser un agent pour garantir une cohérence applicative.

Runbook Windows : volumes et santé

Get-Disk
Get-Partition
Get-Volume | Sort-Object DriveLetter
Get-PhysicalDisk
Get-StoragePool
Get-VirtualDisk

# Events stockage
Get-WinEvent -LogName System | Where-Object {$_.ProviderName -match 'disk|stor|ntfs|refs'} | Select-Object -First 20

# Chkdsk audit
chkdsk D: /scan

# Extension volume
Resize-Partition -DriveLetter D -Size 2TB

Incident : volume plein

# Top dossiers sans traverser autres FS
du -xhd1 / | sort -h

# Fichiers supprimés mais encore ouverts
lsof +L1

# Journald
journalctl --disk-usage
journalctl --vacuum-time=7d

Runbook récupération : règle d’or

# Image disque avec reprise erreurs
ddrescue -f -n /dev/sdb /mnt/rescue/sdb.img /mnt/rescue/sdb.map
ddrescue -d -r3 /dev/sdb /mnt/rescue/sdb.img /mnt/rescue/sdb.map

# Vérification table GPT
sgdisk -v /dev/sdb
parted /dev/sdb print

# Monter read-only
mount -o ro,norecovery /dev/vg/data /mnt/recovery || true

Checklist design avant production

TCO logique : ce qui coûte vraiment

Glossaire express