🐧 Storage Systems — Chapitre 36 : Tuning Linux storage

Chapitre dense consacré au tuning stockage sous Linux : I/O schedulers, read-ahead, mount options, TRIM/discard, LVM, choix filesystem, XFS, ext4, ZFS, Btrfs, NVMe, multipath SAN, iSCSI, NFS, SMB/CIFS, réseau, kernel VM dirty settings, mdadm, bases de données, containers/Kubernetes, logs, monitoring, sysctl/udev/tuned et checklist production. Objectif : optimiser sans casser, avec baseline, p99, preuve et rollback.

I/O schedulersRead-aheadMount optionsTRIM / discardLVM tuningFilesystem choice

36.1

I/O schedulers

mq-deadline, none, BFQ : choix du planificateur bloc selon SSD/NVMe, HDD, VM, desktop, serveur et latence.

Schedulermq-deadlinenoneBFQ

36.2

Read-ahead

Optimisation séquentielle : anticiper les lectures, améliorer streaming/backup, éviter pollution cache sur random I/O.

Read-aheadSequentialCache

36.3

Mount options

noatime, nodiratime, discard, lazytime, barrier, commit, inode64, logbufs : options filesystem à comprendre avant tuning.

Mountnoatimediscard

36.4

TRIM / discard

SSD : discard continu vs fstrim planifié, thin provisioning, LVM, SAN, cloud disk et risques de performance.

TRIMdiscardSSD

36.5

LVM tuning

Stripe, cache, thin provisioning, snapshots, metadata, alignment, extent size, writecache et monitoring.

LVMStripeThin

36.6

Filesystem choice

XFS pour grosses charges, ext4 polyvalent, ZFS/Btrfs avancés : choisir selon workload, snapshots, checksums et admin.

XFSext4ZFSBtrfs

36.7

XFS tuning

Allocation groups, inode64, log buffers, reflink, quota, bigtime, ftype, fragmentation et workloads fichier massif.

XFSAGMetadata

36.8

ext4 tuning

Journal mode, commit interval, reserved blocks, stride/stripe-width, dir_index, lazytime et fsck strategy.

ext4JournalStride

36.9

ZFS on Linux

ARC, L2ARC, SLOG, recordsize, ashift, compression, snapshots, scrubbing, sync writes et dataset design.

ZFSARCSLOG

36.10

Btrfs tuning

COW, snapshots, compression, autodefrag, nodatacow, scrub, balance, metadata profile et workloads adaptés.

BtrfsCOWSnapshots

36.11

NVMe tuning

Queues, IRQ affinity, multipath NVMe, scheduler none, polling, namespace, thermal throttling et firmware.

NVMeQueuesIRQ

36.12

Multipath SAN

DM-Multipath : path_grouping_policy, ALUA, failover, queue_if_no_path, checker, prio et path imbalance.

MultipathALUASAN

36.13

iSCSI tuning

Sessions, portals, jumbo frames, TCP buffers, multipath, replacement_timeout, login retries et isolation réseau.

iSCSITCPMultipath

36.14

NFS tuning

nconnect, rsize/wsize, hard/soft, timeo, retrans, actimeo, sync/async, Kerberos et workloads metadata.

NFSnconnectrsize

36.15

SMB/CIFS tuning Linux

mount.cifs, cache, vers, multichannel selon support, signing, encryption, actimeo, credentials et workloads fichiers.

SMBCIFSMount

36.16

Network tuning

MTU, IRQ/RPS/XPS, GRO/LRO, TCP buffers, congestion control, RDMA, packet loss et storage VLAN.

NetworkMTUTCP

36.17

Kernel VM dirty settings

vm.dirty_ratio, dirty_background_ratio, dirty_expire, writeback, swappiness et risques de latence writeback.

Dirty pagesWritebackVM

36.18

mdadm / RAID software

Chunk size, stripe_cache_size, bitmap, resync speed, read-ahead, write-mostly, monitoring et rebuild impact.

mdadmRAIDRebuild

36.19

Linux storage pour bases

Oracle, PostgreSQL, MySQL, SQL Server Linux : direct I/O, WAL, hugepages, fsync, scheduler, XFS/ext4.

DBWALfsync

36.20

Containers et Kubernetes nodes

overlayfs, containerd, kubelet eviction, local PV, CSI, image GC, journald logs et node disk pressure.

K8soverlayfsNode disk

36.21

Logs et journald

journald, logrotate, filesystem pressure, sync writes, write amplification, partitionnement et rétention logs.

Logsjournaldlogrotate

36.22

Monitoring Linux storage

iostat, blktrace, bpftrace, perf, pidstat, smartctl, nvme-cli, sar, Prometheus node_exporter.

Monitoringbpftracesmartctl

36.23

sysctl, udev et persistance

Rendre les réglages durables : sysctl.d, udev rules, tuned, systemd timers, fstab et documentation.

sysctludevtuned

36.24

Checklist tuning Linux storage

GO/NO-GO : baseline, rollback, un changement à la fois, p99, fstrim, scheduler, mount options, monitoring.

ChecklistGO/NO-GOBaseline

36.1 I/O schedulers

Définition opérationnelle

mq-deadline, none, BFQ : choix du planificateur bloc selon SSD/NVMe, HDD, VM, desktop, serveur et latence.

Point clé : le tuning Linux storage est une démarche mesurée : baseline, hypothèse, changement unique, mesure p95/p99, validation applicative et rollback. Sans métriques, le tuning devient dangereux.

Chaîne Linux storage

Application→Filesystem→Page cache→Block layer→Driver / Fabric→Storage

Méthode : baseline → tune one knob → measure p99 → validate workload → persist setting → document rollback.

Composants à analyser

Composant	Rôle / explication
Workload	Base de données, VM, NAS, backup, logs, object gateway, Kubernetes node, streaming, random I/O.
Block layer	Device, scheduler, queue, LVM, mdadm, multipath, NVMe, iSCSI, discard, alignment.
Filesystem layer	XFS, ext4, ZFS, Btrfs, mount options, journal, metadata, cache, fragmentation.
Kernel layer	Page cache, dirty pages, writeback, readahead, IRQ, TCP buffers, memory pressure.
Observation	iostat, fio, sar, vmstat, pidstat, bpftrace, smartctl, nvme-cli, dmesg, application metrics.
Safety	Baseline, snapshot/backup, rollback plan, one-change-at-a-time, test window, production guardrails.

Cas d’usage

Optimiser une base PostgreSQL/MySQL/Oracle sur Linux
Réduire latence p99 d’un serveur NVMe
Améliorer throughput backup ou streaming
Stabiliser un serveur NFS/SMB
Éviter saturation writeback et dirty pages
Préparer un POC stockage Linux reproductible

Baseline→Hypothesis→Change→Measure→Persist→Rollback doc

Apports du tuning

Permet de gagner performance sans changer de matériel
Réduit latence p99 et comportements imprévisibles
Clarifie le rôle de chaque couche Linux
Rend les décisions de tuning auditables
Évite les réglages magiques copiés sans contexte

Risques / limites

Réglage bénéfique pour sequential mais mauvais pour random
discard continu pouvant dégrader certains workloads
sysctl global impactant d’autres applications
mount options dangereuses si cohérence/journal mal compris
benchmark sans rollback ni baseline exploitable

Matrice de décision Linux storage tuning

Question	Décision à prendre
Quel workload ?	OLTP random, sequential backup, NAS metadata, VM images, logs, Kubernetes, object gateway ou archive.
Quel device ?	HDD, SATA SSD, NVMe, LUN SAN, iSCSI, NFS, SMB, cloud disk, mdadm, LVM ou device mapper.
Quel filesystem ?	XFS pour grosses charges, ext4 polyvalent, ZFS/Btrfs si snapshots/checksums avancés sont voulus.
Quel risque ?	Perte de cohérence, write amplification, latence p99, cache pollution, trim/discard, rollback difficile.
Quelle preuve ?	fio/iostat/sar avant-après, graphes p95/p99, logs applicatifs, versions kernel/firmware, configuration persistante.
Quelle persistance ?	udev, sysctl.d, tuned, fstab, systemd timer fstrim, scripts d’audit et documentation exploitation.

Règle pratique : sur NVMe moderne, scheduler none ou mq-deadline ; sur desktop interactif BFQ peut aider ; toujours tester avec le vrai workload.

Runbook tuning Linux storage

Capturer baseline : iostat, vmstat, sar, fio, logs application, dmesg, SMART/NVMe health.
Identifier type I/O : random/sequential, block size, read/write, queue depth, cache hit, dirty pages.
Choisir un seul réglage : scheduler, readahead, mount option, fstrim, LVM stripe, sysctl, network.
Appliquer en temporaire quand possible, mesurer p95/p99, throughput, saturation et erreurs.
Valider côté application : transaction time, checkpoint, restore, backup, file listing, pod latency.
Persister proprement via sysctl.d, udev rules, fstab, tuned ou systemd timer.
Documenter rollback et seuils de monitoring.

# Discovery
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,DISC-MAX,DISC-GRAN,MOUNTPOINT
cat /sys/block/nvme0n1/queue/scheduler
cat /sys/block/nvme0n1/queue/read_ahead_kb
findmnt -no OPTIONS /data
iostat -x 1
vmstat 1
sar -d 1
dmesg -T | tail -100
smartctl -a /dev/sda
nvme smart-log /dev/nvme0

# Temporary tuning examples
echo none > /sys/block/nvme0n1/queue/scheduler
blockdev --setra 4096 /dev/nvme0n1
fstrim -v /data

# fio validation
fio --name=linux-storage --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting

NO-GO : changement global sans baseline, sans rollback, sans test applicatif, sans p99, ou avec options dangereuses copiées depuis Internet sans comprendre le workload.

36.2 Read-ahead

Définition opérationnelle

Optimisation séquentielle : anticiper les lectures, améliorer streaming/backup, éviter pollution cache sur random I/O.

Chaîne Linux storage

Application→Filesystem→Page cache→Block layer→Driver / Fabric→Storage

Méthode : baseline → tune one knob → measure p99 → validate workload → persist setting → document rollback.

Composants à analyser

Composant	Rôle / explication
Workload	Base de données, VM, NAS, backup, logs, object gateway, Kubernetes node, streaming, random I/O.
Block layer	Device, scheduler, queue, LVM, mdadm, multipath, NVMe, iSCSI, discard, alignment.
Filesystem layer	XFS, ext4, ZFS, Btrfs, mount options, journal, metadata, cache, fragmentation.
Kernel layer	Page cache, dirty pages, writeback, readahead, IRQ, TCP buffers, memory pressure.
Observation	iostat, fio, sar, vmstat, pidstat, bpftrace, smartctl, nvme-cli, dmesg, application metrics.
Safety	Baseline, snapshot/backup, rollback plan, one-change-at-a-time, test window, production guardrails.

Cas d’usage

Optimiser une base PostgreSQL/MySQL/Oracle sur Linux
Réduire latence p99 d’un serveur NVMe
Améliorer throughput backup ou streaming
Stabiliser un serveur NFS/SMB
Éviter saturation writeback et dirty pages
Préparer un POC stockage Linux reproductible

Baseline→Hypothesis→Change→Measure→Persist→Rollback doc

Apports du tuning

Permet de gagner performance sans changer de matériel
Réduit latence p99 et comportements imprévisibles
Clarifie le rôle de chaque couche Linux
Rend les décisions de tuning auditables
Évite les réglages magiques copiés sans contexte

Risques / limites

Réglage bénéfique pour sequential mais mauvais pour random
discard continu pouvant dégrader certains workloads
sysctl global impactant d’autres applications
mount options dangereuses si cohérence/journal mal compris
benchmark sans rollback ni baseline exploitable

Matrice de décision Linux storage tuning

Question	Décision à prendre
Quel workload ?	OLTP random, sequential backup, NAS metadata, VM images, logs, Kubernetes, object gateway ou archive.
Quel device ?	HDD, SATA SSD, NVMe, LUN SAN, iSCSI, NFS, SMB, cloud disk, mdadm, LVM ou device mapper.
Quel filesystem ?	XFS pour grosses charges, ext4 polyvalent, ZFS/Btrfs si snapshots/checksums avancés sont voulus.
Quel risque ?	Perte de cohérence, write amplification, latence p99, cache pollution, trim/discard, rollback difficile.
Quelle preuve ?	fio/iostat/sar avant-après, graphes p95/p99, logs applicatifs, versions kernel/firmware, configuration persistante.
Quelle persistance ?	udev, sysctl.d, tuned, fstab, systemd timer fstrim, scripts d’audit et documentation exploitation.

Règle pratique : sur NVMe moderne, scheduler none ou mq-deadline ; sur desktop interactif BFQ peut aider ; toujours tester avec le vrai workload.

Runbook tuning Linux storage

Capturer baseline : iostat, vmstat, sar, fio, logs application, dmesg, SMART/NVMe health.
Identifier type I/O : random/sequential, block size, read/write, queue depth, cache hit, dirty pages.
Choisir un seul réglage : scheduler, readahead, mount option, fstrim, LVM stripe, sysctl, network.
Appliquer en temporaire quand possible, mesurer p95/p99, throughput, saturation et erreurs.
Valider côté application : transaction time, checkpoint, restore, backup, file listing, pod latency.
Persister proprement via sysctl.d, udev rules, fstab, tuned ou systemd timer.
Documenter rollback et seuils de monitoring.

# Discovery
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,DISC-MAX,DISC-GRAN,MOUNTPOINT
cat /sys/block/nvme0n1/queue/scheduler
cat /sys/block/nvme0n1/queue/read_ahead_kb
findmnt -no OPTIONS /data
iostat -x 1
vmstat 1
sar -d 1
dmesg -T | tail -100
smartctl -a /dev/sda
nvme smart-log /dev/nvme0

# Temporary tuning examples
echo none > /sys/block/nvme0n1/queue/scheduler
blockdev --setra 4096 /dev/nvme0n1
fstrim -v /data

# fio validation
fio --name=linux-storage --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting

NO-GO : changement global sans baseline, sans rollback, sans test applicatif, sans p99, ou avec options dangereuses copiées depuis Internet sans comprendre le workload.

36.3 Mount options

Définition opérationnelle

noatime, nodiratime, discard, lazytime, barrier, commit, inode64, logbufs : options filesystem à comprendre avant tuning.

Chaîne Linux storage

Application→Filesystem→Page cache→Block layer→Driver / Fabric→Storage

Méthode : baseline → tune one knob → measure p99 → validate workload → persist setting → document rollback.

Composants à analyser

Composant	Rôle / explication
Workload	Base de données, VM, NAS, backup, logs, object gateway, Kubernetes node, streaming, random I/O.
Block layer	Device, scheduler, queue, LVM, mdadm, multipath, NVMe, iSCSI, discard, alignment.
Filesystem layer	XFS, ext4, ZFS, Btrfs, mount options, journal, metadata, cache, fragmentation.
Kernel layer	Page cache, dirty pages, writeback, readahead, IRQ, TCP buffers, memory pressure.
Observation	iostat, fio, sar, vmstat, pidstat, bpftrace, smartctl, nvme-cli, dmesg, application metrics.
Safety	Baseline, snapshot/backup, rollback plan, one-change-at-a-time, test window, production guardrails.

Cas d’usage

Optimiser une base PostgreSQL/MySQL/Oracle sur Linux
Réduire latence p99 d’un serveur NVMe
Améliorer throughput backup ou streaming
Stabiliser un serveur NFS/SMB
Éviter saturation writeback et dirty pages
Préparer un POC stockage Linux reproductible

Baseline→Hypothesis→Change→Measure→Persist→Rollback doc

Apports du tuning

Permet de gagner performance sans changer de matériel
Réduit latence p99 et comportements imprévisibles
Clarifie le rôle de chaque couche Linux
Rend les décisions de tuning auditables
Évite les réglages magiques copiés sans contexte

Risques / limites

Réglage bénéfique pour sequential mais mauvais pour random
discard continu pouvant dégrader certains workloads
sysctl global impactant d’autres applications
mount options dangereuses si cohérence/journal mal compris
benchmark sans rollback ni baseline exploitable

Matrice de décision Linux storage tuning

Question	Décision à prendre
Quel workload ?	OLTP random, sequential backup, NAS metadata, VM images, logs, Kubernetes, object gateway ou archive.
Quel device ?	HDD, SATA SSD, NVMe, LUN SAN, iSCSI, NFS, SMB, cloud disk, mdadm, LVM ou device mapper.
Quel filesystem ?	XFS pour grosses charges, ext4 polyvalent, ZFS/Btrfs si snapshots/checksums avancés sont voulus.
Quel risque ?	Perte de cohérence, write amplification, latence p99, cache pollution, trim/discard, rollback difficile.
Quelle preuve ?	fio/iostat/sar avant-après, graphes p95/p99, logs applicatifs, versions kernel/firmware, configuration persistante.
Quelle persistance ?	udev, sysctl.d, tuned, fstab, systemd timer fstrim, scripts d’audit et documentation exploitation.

Règle pratique : sur NVMe moderne, scheduler none ou mq-deadline ; sur desktop interactif BFQ peut aider ; toujours tester avec le vrai workload.

Runbook tuning Linux storage

Capturer baseline : iostat, vmstat, sar, fio, logs application, dmesg, SMART/NVMe health.
Identifier type I/O : random/sequential, block size, read/write, queue depth, cache hit, dirty pages.
Choisir un seul réglage : scheduler, readahead, mount option, fstrim, LVM stripe, sysctl, network.
Appliquer en temporaire quand possible, mesurer p95/p99, throughput, saturation et erreurs.
Valider côté application : transaction time, checkpoint, restore, backup, file listing, pod latency.
Persister proprement via sysctl.d, udev rules, fstab, tuned ou systemd timer.
Documenter rollback et seuils de monitoring.

# Discovery
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,DISC-MAX,DISC-GRAN,MOUNTPOINT
cat /sys/block/nvme0n1/queue/scheduler
cat /sys/block/nvme0n1/queue/read_ahead_kb
findmnt -no OPTIONS /data
iostat -x 1
vmstat 1
sar -d 1
dmesg -T | tail -100
smartctl -a /dev/sda
nvme smart-log /dev/nvme0

# Temporary tuning examples
echo none > /sys/block/nvme0n1/queue/scheduler
blockdev --setra 4096 /dev/nvme0n1
fstrim -v /data

# fio validation
fio --name=linux-storage --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting

NO-GO : changement global sans baseline, sans rollback, sans test applicatif, sans p99, ou avec options dangereuses copiées depuis Internet sans comprendre le workload.

36.4 TRIM / discard

Définition opérationnelle

SSD : discard continu vs fstrim planifié, thin provisioning, LVM, SAN, cloud disk et risques de performance.

Chaîne Linux storage

Application→Filesystem→Page cache→Block layer→Driver / Fabric→Storage

Méthode : baseline → tune one knob → measure p99 → validate workload → persist setting → document rollback.

Composants à analyser

Composant	Rôle / explication
Workload	Base de données, VM, NAS, backup, logs, object gateway, Kubernetes node, streaming, random I/O.
Block layer	Device, scheduler, queue, LVM, mdadm, multipath, NVMe, iSCSI, discard, alignment.
Filesystem layer	XFS, ext4, ZFS, Btrfs, mount options, journal, metadata, cache, fragmentation.
Kernel layer	Page cache, dirty pages, writeback, readahead, IRQ, TCP buffers, memory pressure.
Observation	iostat, fio, sar, vmstat, pidstat, bpftrace, smartctl, nvme-cli, dmesg, application metrics.
Safety	Baseline, snapshot/backup, rollback plan, one-change-at-a-time, test window, production guardrails.

Cas d’usage

Optimiser une base PostgreSQL/MySQL/Oracle sur Linux
Réduire latence p99 d’un serveur NVMe
Améliorer throughput backup ou streaming
Stabiliser un serveur NFS/SMB
Éviter saturation writeback et dirty pages
Préparer un POC stockage Linux reproductible

Baseline→Hypothesis→Change→Measure→Persist→Rollback doc

Apports du tuning

Permet de gagner performance sans changer de matériel
Réduit latence p99 et comportements imprévisibles
Clarifie le rôle de chaque couche Linux
Rend les décisions de tuning auditables
Évite les réglages magiques copiés sans contexte

Risques / limites

Réglage bénéfique pour sequential mais mauvais pour random
discard continu pouvant dégrader certains workloads
sysctl global impactant d’autres applications
mount options dangereuses si cohérence/journal mal compris
benchmark sans rollback ni baseline exploitable

Matrice de décision Linux storage tuning

Question	Décision à prendre
Quel workload ?	OLTP random, sequential backup, NAS metadata, VM images, logs, Kubernetes, object gateway ou archive.
Quel device ?	HDD, SATA SSD, NVMe, LUN SAN, iSCSI, NFS, SMB, cloud disk, mdadm, LVM ou device mapper.
Quel filesystem ?	XFS pour grosses charges, ext4 polyvalent, ZFS/Btrfs si snapshots/checksums avancés sont voulus.
Quel risque ?	Perte de cohérence, write amplification, latence p99, cache pollution, trim/discard, rollback difficile.
Quelle preuve ?	fio/iostat/sar avant-après, graphes p95/p99, logs applicatifs, versions kernel/firmware, configuration persistante.
Quelle persistance ?	udev, sysctl.d, tuned, fstab, systemd timer fstrim, scripts d’audit et documentation exploitation.

Règle pratique : sur NVMe moderne, scheduler none ou mq-deadline ; sur desktop interactif BFQ peut aider ; toujours tester avec le vrai workload.

Runbook tuning Linux storage

Capturer baseline : iostat, vmstat, sar, fio, logs application, dmesg, SMART/NVMe health.
Identifier type I/O : random/sequential, block size, read/write, queue depth, cache hit, dirty pages.
Choisir un seul réglage : scheduler, readahead, mount option, fstrim, LVM stripe, sysctl, network.
Appliquer en temporaire quand possible, mesurer p95/p99, throughput, saturation et erreurs.
Valider côté application : transaction time, checkpoint, restore, backup, file listing, pod latency.
Persister proprement via sysctl.d, udev rules, fstab, tuned ou systemd timer.
Documenter rollback et seuils de monitoring.

# Discovery
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,DISC-MAX,DISC-GRAN,MOUNTPOINT
cat /sys/block/nvme0n1/queue/scheduler
cat /sys/block/nvme0n1/queue/read_ahead_kb
findmnt -no OPTIONS /data
iostat -x 1
vmstat 1
sar -d 1
dmesg -T | tail -100
smartctl -a /dev/sda
nvme smart-log /dev/nvme0

# Temporary tuning examples
echo none > /sys/block/nvme0n1/queue/scheduler
blockdev --setra 4096 /dev/nvme0n1
fstrim -v /data

# fio validation
fio --name=linux-storage --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting

NO-GO : changement global sans baseline, sans rollback, sans test applicatif, sans p99, ou avec options dangereuses copiées depuis Internet sans comprendre le workload.

36.5 LVM tuning

Définition opérationnelle

Stripe, cache, thin provisioning, snapshots, metadata, alignment, extent size, writecache et monitoring.

Chaîne Linux storage

Application→Filesystem→Page cache→Block layer→Driver / Fabric→Storage

Méthode : baseline → tune one knob → measure p99 → validate workload → persist setting → document rollback.

Composants à analyser

Composant	Rôle / explication
Workload	Base de données, VM, NAS, backup, logs, object gateway, Kubernetes node, streaming, random I/O.
Block layer	Device, scheduler, queue, LVM, mdadm, multipath, NVMe, iSCSI, discard, alignment.
Filesystem layer	XFS, ext4, ZFS, Btrfs, mount options, journal, metadata, cache, fragmentation.
Kernel layer	Page cache, dirty pages, writeback, readahead, IRQ, TCP buffers, memory pressure.
Observation	iostat, fio, sar, vmstat, pidstat, bpftrace, smartctl, nvme-cli, dmesg, application metrics.
Safety	Baseline, snapshot/backup, rollback plan, one-change-at-a-time, test window, production guardrails.

Cas d’usage

Optimiser une base PostgreSQL/MySQL/Oracle sur Linux
Réduire latence p99 d’un serveur NVMe
Améliorer throughput backup ou streaming
Stabiliser un serveur NFS/SMB
Éviter saturation writeback et dirty pages
Préparer un POC stockage Linux reproductible

Baseline→Hypothesis→Change→Measure→Persist→Rollback doc

Apports du tuning

Permet de gagner performance sans changer de matériel
Réduit latence p99 et comportements imprévisibles
Clarifie le rôle de chaque couche Linux
Rend les décisions de tuning auditables
Évite les réglages magiques copiés sans contexte

Risques / limites

Réglage bénéfique pour sequential mais mauvais pour random
discard continu pouvant dégrader certains workloads
sysctl global impactant d’autres applications
mount options dangereuses si cohérence/journal mal compris
benchmark sans rollback ni baseline exploitable

Matrice de décision Linux storage tuning

Question	Décision à prendre
Quel workload ?	OLTP random, sequential backup, NAS metadata, VM images, logs, Kubernetes, object gateway ou archive.
Quel device ?	HDD, SATA SSD, NVMe, LUN SAN, iSCSI, NFS, SMB, cloud disk, mdadm, LVM ou device mapper.
Quel filesystem ?	XFS pour grosses charges, ext4 polyvalent, ZFS/Btrfs si snapshots/checksums avancés sont voulus.
Quel risque ?	Perte de cohérence, write amplification, latence p99, cache pollution, trim/discard, rollback difficile.
Quelle preuve ?	fio/iostat/sar avant-après, graphes p95/p99, logs applicatifs, versions kernel/firmware, configuration persistante.
Quelle persistance ?	udev, sysctl.d, tuned, fstab, systemd timer fstrim, scripts d’audit et documentation exploitation.

Règle pratique : sur NVMe moderne, scheduler none ou mq-deadline ; sur desktop interactif BFQ peut aider ; toujours tester avec le vrai workload.

Runbook tuning Linux storage

Capturer baseline : iostat, vmstat, sar, fio, logs application, dmesg, SMART/NVMe health.
Identifier type I/O : random/sequential, block size, read/write, queue depth, cache hit, dirty pages.
Choisir un seul réglage : scheduler, readahead, mount option, fstrim, LVM stripe, sysctl, network.
Appliquer en temporaire quand possible, mesurer p95/p99, throughput, saturation et erreurs.
Valider côté application : transaction time, checkpoint, restore, backup, file listing, pod latency.
Persister proprement via sysctl.d, udev rules, fstab, tuned ou systemd timer.
Documenter rollback et seuils de monitoring.

# Discovery
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,DISC-MAX,DISC-GRAN,MOUNTPOINT
cat /sys/block/nvme0n1/queue/scheduler
cat /sys/block/nvme0n1/queue/read_ahead_kb
findmnt -no OPTIONS /data
iostat -x 1
vmstat 1
sar -d 1
dmesg -T | tail -100
smartctl -a /dev/sda
nvme smart-log /dev/nvme0

# Temporary tuning examples
echo none > /sys/block/nvme0n1/queue/scheduler
blockdev --setra 4096 /dev/nvme0n1
fstrim -v /data

# fio validation
fio --name=linux-storage --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting

NO-GO : changement global sans baseline, sans rollback, sans test applicatif, sans p99, ou avec options dangereuses copiées depuis Internet sans comprendre le workload.

36.6 Filesystem choice

Définition opérationnelle

XFS pour grosses charges, ext4 polyvalent, ZFS/Btrfs avancés : choisir selon workload, snapshots, checksums et admin.

Chaîne Linux storage

Application→Filesystem→Page cache→Block layer→Driver / Fabric→Storage

Méthode : baseline → tune one knob → measure p99 → validate workload → persist setting → document rollback.

Composants à analyser

Composant	Rôle / explication
Workload	Base de données, VM, NAS, backup, logs, object gateway, Kubernetes node, streaming, random I/O.
Block layer	Device, scheduler, queue, LVM, mdadm, multipath, NVMe, iSCSI, discard, alignment.
Filesystem layer	XFS, ext4, ZFS, Btrfs, mount options, journal, metadata, cache, fragmentation.
Kernel layer	Page cache, dirty pages, writeback, readahead, IRQ, TCP buffers, memory pressure.
Observation	iostat, fio, sar, vmstat, pidstat, bpftrace, smartctl, nvme-cli, dmesg, application metrics.
Safety	Baseline, snapshot/backup, rollback plan, one-change-at-a-time, test window, production guardrails.

Cas d’usage

Optimiser une base PostgreSQL/MySQL/Oracle sur Linux
Réduire latence p99 d’un serveur NVMe
Améliorer throughput backup ou streaming
Stabiliser un serveur NFS/SMB
Éviter saturation writeback et dirty pages
Préparer un POC stockage Linux reproductible

Baseline→Hypothesis→Change→Measure→Persist→Rollback doc

Apports du tuning

Permet de gagner performance sans changer de matériel
Réduit latence p99 et comportements imprévisibles
Clarifie le rôle de chaque couche Linux
Rend les décisions de tuning auditables
Évite les réglages magiques copiés sans contexte

Risques / limites

Réglage bénéfique pour sequential mais mauvais pour random
discard continu pouvant dégrader certains workloads
sysctl global impactant d’autres applications
mount options dangereuses si cohérence/journal mal compris
benchmark sans rollback ni baseline exploitable

Matrice de décision Linux storage tuning

Question	Décision à prendre
Quel workload ?	OLTP random, sequential backup, NAS metadata, VM images, logs, Kubernetes, object gateway ou archive.
Quel device ?	HDD, SATA SSD, NVMe, LUN SAN, iSCSI, NFS, SMB, cloud disk, mdadm, LVM ou device mapper.
Quel filesystem ?	XFS pour grosses charges, ext4 polyvalent, ZFS/Btrfs si snapshots/checksums avancés sont voulus.
Quel risque ?	Perte de cohérence, write amplification, latence p99, cache pollution, trim/discard, rollback difficile.
Quelle preuve ?	fio/iostat/sar avant-après, graphes p95/p99, logs applicatifs, versions kernel/firmware, configuration persistante.
Quelle persistance ?	udev, sysctl.d, tuned, fstab, systemd timer fstrim, scripts d’audit et documentation exploitation.

Règle pratique : sur NVMe moderne, scheduler none ou mq-deadline ; sur desktop interactif BFQ peut aider ; toujours tester avec le vrai workload.

Runbook tuning Linux storage

Capturer baseline : iostat, vmstat, sar, fio, logs application, dmesg, SMART/NVMe health.
Identifier type I/O : random/sequential, block size, read/write, queue depth, cache hit, dirty pages.
Choisir un seul réglage : scheduler, readahead, mount option, fstrim, LVM stripe, sysctl, network.
Appliquer en temporaire quand possible, mesurer p95/p99, throughput, saturation et erreurs.
Valider côté application : transaction time, checkpoint, restore, backup, file listing, pod latency.
Persister proprement via sysctl.d, udev rules, fstab, tuned ou systemd timer.
Documenter rollback et seuils de monitoring.

# Discovery
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,DISC-MAX,DISC-GRAN,MOUNTPOINT
cat /sys/block/nvme0n1/queue/scheduler
cat /sys/block/nvme0n1/queue/read_ahead_kb
findmnt -no OPTIONS /data
iostat -x 1
vmstat 1
sar -d 1
dmesg -T | tail -100
smartctl -a /dev/sda
nvme smart-log /dev/nvme0

# Temporary tuning examples
echo none > /sys/block/nvme0n1/queue/scheduler
blockdev --setra 4096 /dev/nvme0n1
fstrim -v /data

# fio validation
fio --name=linux-storage --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting

NO-GO : changement global sans baseline, sans rollback, sans test applicatif, sans p99, ou avec options dangereuses copiées depuis Internet sans comprendre le workload.

36.7 XFS tuning

Définition opérationnelle

Allocation groups, inode64, log buffers, reflink, quota, bigtime, ftype, fragmentation et workloads fichier massif.

Chaîne Linux storage

Application→Filesystem→Page cache→Block layer→Driver / Fabric→Storage

Méthode : baseline → tune one knob → measure p99 → validate workload → persist setting → document rollback.

Composants à analyser

Composant	Rôle / explication
Workload	Base de données, VM, NAS, backup, logs, object gateway, Kubernetes node, streaming, random I/O.
Block layer	Device, scheduler, queue, LVM, mdadm, multipath, NVMe, iSCSI, discard, alignment.
Filesystem layer	XFS, ext4, ZFS, Btrfs, mount options, journal, metadata, cache, fragmentation.
Kernel layer	Page cache, dirty pages, writeback, readahead, IRQ, TCP buffers, memory pressure.
Observation	iostat, fio, sar, vmstat, pidstat, bpftrace, smartctl, nvme-cli, dmesg, application metrics.
Safety	Baseline, snapshot/backup, rollback plan, one-change-at-a-time, test window, production guardrails.

Cas d’usage

Optimiser une base PostgreSQL/MySQL/Oracle sur Linux
Réduire latence p99 d’un serveur NVMe
Améliorer throughput backup ou streaming
Stabiliser un serveur NFS/SMB
Éviter saturation writeback et dirty pages
Préparer un POC stockage Linux reproductible

Baseline→Hypothesis→Change→Measure→Persist→Rollback doc

Apports du tuning

Permet de gagner performance sans changer de matériel
Réduit latence p99 et comportements imprévisibles
Clarifie le rôle de chaque couche Linux
Rend les décisions de tuning auditables
Évite les réglages magiques copiés sans contexte

Risques / limites

Réglage bénéfique pour sequential mais mauvais pour random
discard continu pouvant dégrader certains workloads
sysctl global impactant d’autres applications
mount options dangereuses si cohérence/journal mal compris
benchmark sans rollback ni baseline exploitable

Matrice de décision Linux storage tuning

Question	Décision à prendre
Quel workload ?	OLTP random, sequential backup, NAS metadata, VM images, logs, Kubernetes, object gateway ou archive.
Quel device ?	HDD, SATA SSD, NVMe, LUN SAN, iSCSI, NFS, SMB, cloud disk, mdadm, LVM ou device mapper.
Quel filesystem ?	XFS pour grosses charges, ext4 polyvalent, ZFS/Btrfs si snapshots/checksums avancés sont voulus.
Quel risque ?	Perte de cohérence, write amplification, latence p99, cache pollution, trim/discard, rollback difficile.
Quelle preuve ?	fio/iostat/sar avant-après, graphes p95/p99, logs applicatifs, versions kernel/firmware, configuration persistante.
Quelle persistance ?	udev, sysctl.d, tuned, fstab, systemd timer fstrim, scripts d’audit et documentation exploitation.

Règle pratique : sur NVMe moderne, scheduler none ou mq-deadline ; sur desktop interactif BFQ peut aider ; toujours tester avec le vrai workload.

Runbook tuning Linux storage

Capturer baseline : iostat, vmstat, sar, fio, logs application, dmesg, SMART/NVMe health.
Identifier type I/O : random/sequential, block size, read/write, queue depth, cache hit, dirty pages.
Choisir un seul réglage : scheduler, readahead, mount option, fstrim, LVM stripe, sysctl, network.
Appliquer en temporaire quand possible, mesurer p95/p99, throughput, saturation et erreurs.
Valider côté application : transaction time, checkpoint, restore, backup, file listing, pod latency.
Persister proprement via sysctl.d, udev rules, fstab, tuned ou systemd timer.
Documenter rollback et seuils de monitoring.

# Discovery
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,DISC-MAX,DISC-GRAN,MOUNTPOINT
cat /sys/block/nvme0n1/queue/scheduler
cat /sys/block/nvme0n1/queue/read_ahead_kb
findmnt -no OPTIONS /data
iostat -x 1
vmstat 1
sar -d 1
dmesg -T | tail -100
smartctl -a /dev/sda
nvme smart-log /dev/nvme0

# Temporary tuning examples
echo none > /sys/block/nvme0n1/queue/scheduler
blockdev --setra 4096 /dev/nvme0n1
fstrim -v /data

# fio validation
fio --name=linux-storage --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting

NO-GO : changement global sans baseline, sans rollback, sans test applicatif, sans p99, ou avec options dangereuses copiées depuis Internet sans comprendre le workload.

36.8 ext4 tuning

Définition opérationnelle

Journal mode, commit interval, reserved blocks, stride/stripe-width, dir_index, lazytime et fsck strategy.

Chaîne Linux storage

Application→Filesystem→Page cache→Block layer→Driver / Fabric→Storage

Méthode : baseline → tune one knob → measure p99 → validate workload → persist setting → document rollback.

Composants à analyser

Composant	Rôle / explication
Workload	Base de données, VM, NAS, backup, logs, object gateway, Kubernetes node, streaming, random I/O.
Block layer	Device, scheduler, queue, LVM, mdadm, multipath, NVMe, iSCSI, discard, alignment.
Filesystem layer	XFS, ext4, ZFS, Btrfs, mount options, journal, metadata, cache, fragmentation.
Kernel layer	Page cache, dirty pages, writeback, readahead, IRQ, TCP buffers, memory pressure.
Observation	iostat, fio, sar, vmstat, pidstat, bpftrace, smartctl, nvme-cli, dmesg, application metrics.
Safety	Baseline, snapshot/backup, rollback plan, one-change-at-a-time, test window, production guardrails.

Cas d’usage

Optimiser une base PostgreSQL/MySQL/Oracle sur Linux
Réduire latence p99 d’un serveur NVMe
Améliorer throughput backup ou streaming
Stabiliser un serveur NFS/SMB
Éviter saturation writeback et dirty pages
Préparer un POC stockage Linux reproductible

Baseline→Hypothesis→Change→Measure→Persist→Rollback doc

Apports du tuning

Permet de gagner performance sans changer de matériel
Réduit latence p99 et comportements imprévisibles
Clarifie le rôle de chaque couche Linux
Rend les décisions de tuning auditables
Évite les réglages magiques copiés sans contexte

Risques / limites

Réglage bénéfique pour sequential mais mauvais pour random
discard continu pouvant dégrader certains workloads
sysctl global impactant d’autres applications
mount options dangereuses si cohérence/journal mal compris
benchmark sans rollback ni baseline exploitable

Matrice de décision Linux storage tuning

Question	Décision à prendre
Quel workload ?	OLTP random, sequential backup, NAS metadata, VM images, logs, Kubernetes, object gateway ou archive.
Quel device ?	HDD, SATA SSD, NVMe, LUN SAN, iSCSI, NFS, SMB, cloud disk, mdadm, LVM ou device mapper.
Quel filesystem ?	XFS pour grosses charges, ext4 polyvalent, ZFS/Btrfs si snapshots/checksums avancés sont voulus.
Quel risque ?	Perte de cohérence, write amplification, latence p99, cache pollution, trim/discard, rollback difficile.
Quelle preuve ?	fio/iostat/sar avant-après, graphes p95/p99, logs applicatifs, versions kernel/firmware, configuration persistante.
Quelle persistance ?	udev, sysctl.d, tuned, fstab, systemd timer fstrim, scripts d’audit et documentation exploitation.

Règle pratique : sur NVMe moderne, scheduler none ou mq-deadline ; sur desktop interactif BFQ peut aider ; toujours tester avec le vrai workload.

Runbook tuning Linux storage

Capturer baseline : iostat, vmstat, sar, fio, logs application, dmesg, SMART/NVMe health.
Identifier type I/O : random/sequential, block size, read/write, queue depth, cache hit, dirty pages.
Choisir un seul réglage : scheduler, readahead, mount option, fstrim, LVM stripe, sysctl, network.
Appliquer en temporaire quand possible, mesurer p95/p99, throughput, saturation et erreurs.
Valider côté application : transaction time, checkpoint, restore, backup, file listing, pod latency.
Persister proprement via sysctl.d, udev rules, fstab, tuned ou systemd timer.
Documenter rollback et seuils de monitoring.

# Discovery
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,DISC-MAX,DISC-GRAN,MOUNTPOINT
cat /sys/block/nvme0n1/queue/scheduler
cat /sys/block/nvme0n1/queue/read_ahead_kb
findmnt -no OPTIONS /data
iostat -x 1
vmstat 1
sar -d 1
dmesg -T | tail -100
smartctl -a /dev/sda
nvme smart-log /dev/nvme0

# Temporary tuning examples
echo none > /sys/block/nvme0n1/queue/scheduler
blockdev --setra 4096 /dev/nvme0n1
fstrim -v /data

# fio validation
fio --name=linux-storage --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting

NO-GO : changement global sans baseline, sans rollback, sans test applicatif, sans p99, ou avec options dangereuses copiées depuis Internet sans comprendre le workload.

36.9 ZFS on Linux

Définition opérationnelle

ARC, L2ARC, SLOG, recordsize, ashift, compression, snapshots, scrubbing, sync writes et dataset design.

Chaîne Linux storage

Application→Filesystem→Page cache→Block layer→Driver / Fabric→Storage

Méthode : baseline → tune one knob → measure p99 → validate workload → persist setting → document rollback.

Composants à analyser

Composant	Rôle / explication
Workload	Base de données, VM, NAS, backup, logs, object gateway, Kubernetes node, streaming, random I/O.
Block layer	Device, scheduler, queue, LVM, mdadm, multipath, NVMe, iSCSI, discard, alignment.
Filesystem layer	XFS, ext4, ZFS, Btrfs, mount options, journal, metadata, cache, fragmentation.
Kernel layer	Page cache, dirty pages, writeback, readahead, IRQ, TCP buffers, memory pressure.
Observation	iostat, fio, sar, vmstat, pidstat, bpftrace, smartctl, nvme-cli, dmesg, application metrics.
Safety	Baseline, snapshot/backup, rollback plan, one-change-at-a-time, test window, production guardrails.

Cas d’usage

Optimiser une base PostgreSQL/MySQL/Oracle sur Linux
Réduire latence p99 d’un serveur NVMe
Améliorer throughput backup ou streaming
Stabiliser un serveur NFS/SMB
Éviter saturation writeback et dirty pages
Préparer un POC stockage Linux reproductible

Baseline→Hypothesis→Change→Measure→Persist→Rollback doc

Apports du tuning

Permet de gagner performance sans changer de matériel
Réduit latence p99 et comportements imprévisibles
Clarifie le rôle de chaque couche Linux
Rend les décisions de tuning auditables
Évite les réglages magiques copiés sans contexte

Risques / limites

Réglage bénéfique pour sequential mais mauvais pour random
discard continu pouvant dégrader certains workloads
sysctl global impactant d’autres applications
mount options dangereuses si cohérence/journal mal compris
benchmark sans rollback ni baseline exploitable

Matrice de décision Linux storage tuning

Question	Décision à prendre
Quel workload ?	OLTP random, sequential backup, NAS metadata, VM images, logs, Kubernetes, object gateway ou archive.
Quel device ?	HDD, SATA SSD, NVMe, LUN SAN, iSCSI, NFS, SMB, cloud disk, mdadm, LVM ou device mapper.
Quel filesystem ?	XFS pour grosses charges, ext4 polyvalent, ZFS/Btrfs si snapshots/checksums avancés sont voulus.
Quel risque ?	Perte de cohérence, write amplification, latence p99, cache pollution, trim/discard, rollback difficile.
Quelle preuve ?	fio/iostat/sar avant-après, graphes p95/p99, logs applicatifs, versions kernel/firmware, configuration persistante.
Quelle persistance ?	udev, sysctl.d, tuned, fstab, systemd timer fstrim, scripts d’audit et documentation exploitation.

Règle pratique : sur NVMe moderne, scheduler none ou mq-deadline ; sur desktop interactif BFQ peut aider ; toujours tester avec le vrai workload.

Runbook tuning Linux storage

Capturer baseline : iostat, vmstat, sar, fio, logs application, dmesg, SMART/NVMe health.
Identifier type I/O : random/sequential, block size, read/write, queue depth, cache hit, dirty pages.
Choisir un seul réglage : scheduler, readahead, mount option, fstrim, LVM stripe, sysctl, network.
Appliquer en temporaire quand possible, mesurer p95/p99, throughput, saturation et erreurs.
Valider côté application : transaction time, checkpoint, restore, backup, file listing, pod latency.
Persister proprement via sysctl.d, udev rules, fstab, tuned ou systemd timer.
Documenter rollback et seuils de monitoring.

# Discovery
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,DISC-MAX,DISC-GRAN,MOUNTPOINT
cat /sys/block/nvme0n1/queue/scheduler
cat /sys/block/nvme0n1/queue/read_ahead_kb
findmnt -no OPTIONS /data
iostat -x 1
vmstat 1
sar -d 1
dmesg -T | tail -100
smartctl -a /dev/sda
nvme smart-log /dev/nvme0

# Temporary tuning examples
echo none > /sys/block/nvme0n1/queue/scheduler
blockdev --setra 4096 /dev/nvme0n1
fstrim -v /data

# fio validation
fio --name=linux-storage --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting

NO-GO : changement global sans baseline, sans rollback, sans test applicatif, sans p99, ou avec options dangereuses copiées depuis Internet sans comprendre le workload.

36.10 Btrfs tuning

Définition opérationnelle

COW, snapshots, compression, autodefrag, nodatacow, scrub, balance, metadata profile et workloads adaptés.

Chaîne Linux storage

Application→Filesystem→Page cache→Block layer→Driver / Fabric→Storage

Méthode : baseline → tune one knob → measure p99 → validate workload → persist setting → document rollback.

Composants à analyser

Composant	Rôle / explication
Workload	Base de données, VM, NAS, backup, logs, object gateway, Kubernetes node, streaming, random I/O.
Block layer	Device, scheduler, queue, LVM, mdadm, multipath, NVMe, iSCSI, discard, alignment.
Filesystem layer	XFS, ext4, ZFS, Btrfs, mount options, journal, metadata, cache, fragmentation.
Kernel layer	Page cache, dirty pages, writeback, readahead, IRQ, TCP buffers, memory pressure.
Observation	iostat, fio, sar, vmstat, pidstat, bpftrace, smartctl, nvme-cli, dmesg, application metrics.
Safety	Baseline, snapshot/backup, rollback plan, one-change-at-a-time, test window, production guardrails.

Cas d’usage

Optimiser une base PostgreSQL/MySQL/Oracle sur Linux
Réduire latence p99 d’un serveur NVMe
Améliorer throughput backup ou streaming
Stabiliser un serveur NFS/SMB
Éviter saturation writeback et dirty pages
Préparer un POC stockage Linux reproductible

Baseline→Hypothesis→Change→Measure→Persist→Rollback doc

Apports du tuning

Permet de gagner performance sans changer de matériel
Réduit latence p99 et comportements imprévisibles
Clarifie le rôle de chaque couche Linux
Rend les décisions de tuning auditables
Évite les réglages magiques copiés sans contexte

Risques / limites

Réglage bénéfique pour sequential mais mauvais pour random
discard continu pouvant dégrader certains workloads
sysctl global impactant d’autres applications
mount options dangereuses si cohérence/journal mal compris
benchmark sans rollback ni baseline exploitable

Matrice de décision Linux storage tuning

Question	Décision à prendre
Quel workload ?	OLTP random, sequential backup, NAS metadata, VM images, logs, Kubernetes, object gateway ou archive.
Quel device ?	HDD, SATA SSD, NVMe, LUN SAN, iSCSI, NFS, SMB, cloud disk, mdadm, LVM ou device mapper.
Quel filesystem ?	XFS pour grosses charges, ext4 polyvalent, ZFS/Btrfs si snapshots/checksums avancés sont voulus.
Quel risque ?	Perte de cohérence, write amplification, latence p99, cache pollution, trim/discard, rollback difficile.
Quelle preuve ?	fio/iostat/sar avant-après, graphes p95/p99, logs applicatifs, versions kernel/firmware, configuration persistante.
Quelle persistance ?	udev, sysctl.d, tuned, fstab, systemd timer fstrim, scripts d’audit et documentation exploitation.

Règle pratique : sur NVMe moderne, scheduler none ou mq-deadline ; sur desktop interactif BFQ peut aider ; toujours tester avec le vrai workload.

Runbook tuning Linux storage

Capturer baseline : iostat, vmstat, sar, fio, logs application, dmesg, SMART/NVMe health.
Identifier type I/O : random/sequential, block size, read/write, queue depth, cache hit, dirty pages.
Choisir un seul réglage : scheduler, readahead, mount option, fstrim, LVM stripe, sysctl, network.
Appliquer en temporaire quand possible, mesurer p95/p99, throughput, saturation et erreurs.
Valider côté application : transaction time, checkpoint, restore, backup, file listing, pod latency.
Persister proprement via sysctl.d, udev rules, fstab, tuned ou systemd timer.
Documenter rollback et seuils de monitoring.

# Discovery
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,DISC-MAX,DISC-GRAN,MOUNTPOINT
cat /sys/block/nvme0n1/queue/scheduler
cat /sys/block/nvme0n1/queue/read_ahead_kb
findmnt -no OPTIONS /data
iostat -x 1
vmstat 1
sar -d 1
dmesg -T | tail -100
smartctl -a /dev/sda
nvme smart-log /dev/nvme0

# Temporary tuning examples
echo none > /sys/block/nvme0n1/queue/scheduler
blockdev --setra 4096 /dev/nvme0n1
fstrim -v /data

# fio validation
fio --name=linux-storage --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting

NO-GO : changement global sans baseline, sans rollback, sans test applicatif, sans p99, ou avec options dangereuses copiées depuis Internet sans comprendre le workload.

36.11 NVMe tuning

Définition opérationnelle

Queues, IRQ affinity, multipath NVMe, scheduler none, polling, namespace, thermal throttling et firmware.

Chaîne Linux storage

Application→Filesystem→Page cache→Block layer→Driver / Fabric→Storage

Méthode : baseline → tune one knob → measure p99 → validate workload → persist setting → document rollback.

Composants à analyser

Composant	Rôle / explication
Workload	Base de données, VM, NAS, backup, logs, object gateway, Kubernetes node, streaming, random I/O.
Block layer	Device, scheduler, queue, LVM, mdadm, multipath, NVMe, iSCSI, discard, alignment.
Filesystem layer	XFS, ext4, ZFS, Btrfs, mount options, journal, metadata, cache, fragmentation.
Kernel layer	Page cache, dirty pages, writeback, readahead, IRQ, TCP buffers, memory pressure.
Observation	iostat, fio, sar, vmstat, pidstat, bpftrace, smartctl, nvme-cli, dmesg, application metrics.
Safety	Baseline, snapshot/backup, rollback plan, one-change-at-a-time, test window, production guardrails.

Cas d’usage

Optimiser une base PostgreSQL/MySQL/Oracle sur Linux
Réduire latence p99 d’un serveur NVMe
Améliorer throughput backup ou streaming
Stabiliser un serveur NFS/SMB
Éviter saturation writeback et dirty pages
Préparer un POC stockage Linux reproductible

Baseline→Hypothesis→Change→Measure→Persist→Rollback doc

Apports du tuning

Permet de gagner performance sans changer de matériel
Réduit latence p99 et comportements imprévisibles
Clarifie le rôle de chaque couche Linux
Rend les décisions de tuning auditables
Évite les réglages magiques copiés sans contexte

Risques / limites

Réglage bénéfique pour sequential mais mauvais pour random
discard continu pouvant dégrader certains workloads
sysctl global impactant d’autres applications
mount options dangereuses si cohérence/journal mal compris
benchmark sans rollback ni baseline exploitable

Matrice de décision Linux storage tuning

Question	Décision à prendre
Quel workload ?	OLTP random, sequential backup, NAS metadata, VM images, logs, Kubernetes, object gateway ou archive.
Quel device ?	HDD, SATA SSD, NVMe, LUN SAN, iSCSI, NFS, SMB, cloud disk, mdadm, LVM ou device mapper.
Quel filesystem ?	XFS pour grosses charges, ext4 polyvalent, ZFS/Btrfs si snapshots/checksums avancés sont voulus.
Quel risque ?	Perte de cohérence, write amplification, latence p99, cache pollution, trim/discard, rollback difficile.
Quelle preuve ?	fio/iostat/sar avant-après, graphes p95/p99, logs applicatifs, versions kernel/firmware, configuration persistante.
Quelle persistance ?	udev, sysctl.d, tuned, fstab, systemd timer fstrim, scripts d’audit et documentation exploitation.

Règle pratique : sur NVMe moderne, scheduler none ou mq-deadline ; sur desktop interactif BFQ peut aider ; toujours tester avec le vrai workload.

Runbook tuning Linux storage

Capturer baseline : iostat, vmstat, sar, fio, logs application, dmesg, SMART/NVMe health.
Identifier type I/O : random/sequential, block size, read/write, queue depth, cache hit, dirty pages.
Choisir un seul réglage : scheduler, readahead, mount option, fstrim, LVM stripe, sysctl, network.
Appliquer en temporaire quand possible, mesurer p95/p99, throughput, saturation et erreurs.
Valider côté application : transaction time, checkpoint, restore, backup, file listing, pod latency.
Persister proprement via sysctl.d, udev rules, fstab, tuned ou systemd timer.
Documenter rollback et seuils de monitoring.

# Discovery
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,DISC-MAX,DISC-GRAN,MOUNTPOINT
cat /sys/block/nvme0n1/queue/scheduler
cat /sys/block/nvme0n1/queue/read_ahead_kb
findmnt -no OPTIONS /data
iostat -x 1
vmstat 1
sar -d 1
dmesg -T | tail -100
smartctl -a /dev/sda
nvme smart-log /dev/nvme0

# Temporary tuning examples
echo none > /sys/block/nvme0n1/queue/scheduler
blockdev --setra 4096 /dev/nvme0n1
fstrim -v /data

# fio validation
fio --name=linux-storage --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting

NO-GO : changement global sans baseline, sans rollback, sans test applicatif, sans p99, ou avec options dangereuses copiées depuis Internet sans comprendre le workload.

36.12 Multipath SAN

Définition opérationnelle

DM-Multipath : path_grouping_policy, ALUA, failover, queue_if_no_path, checker, prio et path imbalance.

Chaîne Linux storage

Application→Filesystem→Page cache→Block layer→Driver / Fabric→Storage

Méthode : baseline → tune one knob → measure p99 → validate workload → persist setting → document rollback.

Composants à analyser

Composant	Rôle / explication
Workload	Base de données, VM, NAS, backup, logs, object gateway, Kubernetes node, streaming, random I/O.
Block layer	Device, scheduler, queue, LVM, mdadm, multipath, NVMe, iSCSI, discard, alignment.
Filesystem layer	XFS, ext4, ZFS, Btrfs, mount options, journal, metadata, cache, fragmentation.
Kernel layer	Page cache, dirty pages, writeback, readahead, IRQ, TCP buffers, memory pressure.
Observation	iostat, fio, sar, vmstat, pidstat, bpftrace, smartctl, nvme-cli, dmesg, application metrics.
Safety	Baseline, snapshot/backup, rollback plan, one-change-at-a-time, test window, production guardrails.

Cas d’usage

Optimiser une base PostgreSQL/MySQL/Oracle sur Linux
Réduire latence p99 d’un serveur NVMe
Améliorer throughput backup ou streaming
Stabiliser un serveur NFS/SMB
Éviter saturation writeback et dirty pages
Préparer un POC stockage Linux reproductible

Baseline→Hypothesis→Change→Measure→Persist→Rollback doc

Apports du tuning

Permet de gagner performance sans changer de matériel
Réduit latence p99 et comportements imprévisibles
Clarifie le rôle de chaque couche Linux
Rend les décisions de tuning auditables
Évite les réglages magiques copiés sans contexte

Risques / limites

Réglage bénéfique pour sequential mais mauvais pour random
discard continu pouvant dégrader certains workloads
sysctl global impactant d’autres applications
mount options dangereuses si cohérence/journal mal compris
benchmark sans rollback ni baseline exploitable

Matrice de décision Linux storage tuning

Question	Décision à prendre
Quel workload ?	OLTP random, sequential backup, NAS metadata, VM images, logs, Kubernetes, object gateway ou archive.
Quel device ?	HDD, SATA SSD, NVMe, LUN SAN, iSCSI, NFS, SMB, cloud disk, mdadm, LVM ou device mapper.
Quel filesystem ?	XFS pour grosses charges, ext4 polyvalent, ZFS/Btrfs si snapshots/checksums avancés sont voulus.
Quel risque ?	Perte de cohérence, write amplification, latence p99, cache pollution, trim/discard, rollback difficile.
Quelle preuve ?	fio/iostat/sar avant-après, graphes p95/p99, logs applicatifs, versions kernel/firmware, configuration persistante.
Quelle persistance ?	udev, sysctl.d, tuned, fstab, systemd timer fstrim, scripts d’audit et documentation exploitation.

Règle pratique : sur NVMe moderne, scheduler none ou mq-deadline ; sur desktop interactif BFQ peut aider ; toujours tester avec le vrai workload.

Runbook tuning Linux storage

Capturer baseline : iostat, vmstat, sar, fio, logs application, dmesg, SMART/NVMe health.
Identifier type I/O : random/sequential, block size, read/write, queue depth, cache hit, dirty pages.
Choisir un seul réglage : scheduler, readahead, mount option, fstrim, LVM stripe, sysctl, network.
Appliquer en temporaire quand possible, mesurer p95/p99, throughput, saturation et erreurs.
Valider côté application : transaction time, checkpoint, restore, backup, file listing, pod latency.
Persister proprement via sysctl.d, udev rules, fstab, tuned ou systemd timer.
Documenter rollback et seuils de monitoring.

# Discovery
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,DISC-MAX,DISC-GRAN,MOUNTPOINT
cat /sys/block/nvme0n1/queue/scheduler
cat /sys/block/nvme0n1/queue/read_ahead_kb
findmnt -no OPTIONS /data
iostat -x 1
vmstat 1
sar -d 1
dmesg -T | tail -100
smartctl -a /dev/sda
nvme smart-log /dev/nvme0

# Temporary tuning examples
echo none > /sys/block/nvme0n1/queue/scheduler
blockdev --setra 4096 /dev/nvme0n1
fstrim -v /data

# fio validation
fio --name=linux-storage --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting

NO-GO : changement global sans baseline, sans rollback, sans test applicatif, sans p99, ou avec options dangereuses copiées depuis Internet sans comprendre le workload.

36.13 iSCSI tuning

Définition opérationnelle

Sessions, portals, jumbo frames, TCP buffers, multipath, replacement_timeout, login retries et isolation réseau.

Chaîne Linux storage

Application→Filesystem→Page cache→Block layer→Driver / Fabric→Storage

Méthode : baseline → tune one knob → measure p99 → validate workload → persist setting → document rollback.

Composants à analyser

Composant	Rôle / explication
Workload	Base de données, VM, NAS, backup, logs, object gateway, Kubernetes node, streaming, random I/O.
Block layer	Device, scheduler, queue, LVM, mdadm, multipath, NVMe, iSCSI, discard, alignment.
Filesystem layer	XFS, ext4, ZFS, Btrfs, mount options, journal, metadata, cache, fragmentation.
Kernel layer	Page cache, dirty pages, writeback, readahead, IRQ, TCP buffers, memory pressure.
Observation	iostat, fio, sar, vmstat, pidstat, bpftrace, smartctl, nvme-cli, dmesg, application metrics.
Safety	Baseline, snapshot/backup, rollback plan, one-change-at-a-time, test window, production guardrails.

Cas d’usage

Optimiser une base PostgreSQL/MySQL/Oracle sur Linux
Réduire latence p99 d’un serveur NVMe
Améliorer throughput backup ou streaming
Stabiliser un serveur NFS/SMB
Éviter saturation writeback et dirty pages
Préparer un POC stockage Linux reproductible

Baseline→Hypothesis→Change→Measure→Persist→Rollback doc

Apports du tuning

Permet de gagner performance sans changer de matériel
Réduit latence p99 et comportements imprévisibles
Clarifie le rôle de chaque couche Linux
Rend les décisions de tuning auditables
Évite les réglages magiques copiés sans contexte

Risques / limites

Réglage bénéfique pour sequential mais mauvais pour random
discard continu pouvant dégrader certains workloads
sysctl global impactant d’autres applications
mount options dangereuses si cohérence/journal mal compris
benchmark sans rollback ni baseline exploitable

Matrice de décision Linux storage tuning

Question	Décision à prendre
Quel workload ?	OLTP random, sequential backup, NAS metadata, VM images, logs, Kubernetes, object gateway ou archive.
Quel device ?	HDD, SATA SSD, NVMe, LUN SAN, iSCSI, NFS, SMB, cloud disk, mdadm, LVM ou device mapper.
Quel filesystem ?	XFS pour grosses charges, ext4 polyvalent, ZFS/Btrfs si snapshots/checksums avancés sont voulus.
Quel risque ?	Perte de cohérence, write amplification, latence p99, cache pollution, trim/discard, rollback difficile.
Quelle preuve ?	fio/iostat/sar avant-après, graphes p95/p99, logs applicatifs, versions kernel/firmware, configuration persistante.
Quelle persistance ?	udev, sysctl.d, tuned, fstab, systemd timer fstrim, scripts d’audit et documentation exploitation.

Règle pratique : sur NVMe moderne, scheduler none ou mq-deadline ; sur desktop interactif BFQ peut aider ; toujours tester avec le vrai workload.

Runbook tuning Linux storage

Capturer baseline : iostat, vmstat, sar, fio, logs application, dmesg, SMART/NVMe health.
Identifier type I/O : random/sequential, block size, read/write, queue depth, cache hit, dirty pages.
Choisir un seul réglage : scheduler, readahead, mount option, fstrim, LVM stripe, sysctl, network.
Appliquer en temporaire quand possible, mesurer p95/p99, throughput, saturation et erreurs.
Valider côté application : transaction time, checkpoint, restore, backup, file listing, pod latency.
Persister proprement via sysctl.d, udev rules, fstab, tuned ou systemd timer.
Documenter rollback et seuils de monitoring.

# Discovery
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,DISC-MAX,DISC-GRAN,MOUNTPOINT
cat /sys/block/nvme0n1/queue/scheduler
cat /sys/block/nvme0n1/queue/read_ahead_kb
findmnt -no OPTIONS /data
iostat -x 1
vmstat 1
sar -d 1
dmesg -T | tail -100
smartctl -a /dev/sda
nvme smart-log /dev/nvme0

# Temporary tuning examples
echo none > /sys/block/nvme0n1/queue/scheduler
blockdev --setra 4096 /dev/nvme0n1
fstrim -v /data

# fio validation
fio --name=linux-storage --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting

NO-GO : changement global sans baseline, sans rollback, sans test applicatif, sans p99, ou avec options dangereuses copiées depuis Internet sans comprendre le workload.

36.14 NFS tuning

Définition opérationnelle

nconnect, rsize/wsize, hard/soft, timeo, retrans, actimeo, sync/async, Kerberos et workloads metadata.

Chaîne Linux storage

Application→Filesystem→Page cache→Block layer→Driver / Fabric→Storage

Méthode : baseline → tune one knob → measure p99 → validate workload → persist setting → document rollback.

Composants à analyser

Composant	Rôle / explication
Workload	Base de données, VM, NAS, backup, logs, object gateway, Kubernetes node, streaming, random I/O.
Block layer	Device, scheduler, queue, LVM, mdadm, multipath, NVMe, iSCSI, discard, alignment.
Filesystem layer	XFS, ext4, ZFS, Btrfs, mount options, journal, metadata, cache, fragmentation.
Kernel layer	Page cache, dirty pages, writeback, readahead, IRQ, TCP buffers, memory pressure.
Observation	iostat, fio, sar, vmstat, pidstat, bpftrace, smartctl, nvme-cli, dmesg, application metrics.
Safety	Baseline, snapshot/backup, rollback plan, one-change-at-a-time, test window, production guardrails.

Cas d’usage

Optimiser une base PostgreSQL/MySQL/Oracle sur Linux
Réduire latence p99 d’un serveur NVMe
Améliorer throughput backup ou streaming
Stabiliser un serveur NFS/SMB
Éviter saturation writeback et dirty pages
Préparer un POC stockage Linux reproductible

Baseline→Hypothesis→Change→Measure→Persist→Rollback doc

Apports du tuning

Permet de gagner performance sans changer de matériel
Réduit latence p99 et comportements imprévisibles
Clarifie le rôle de chaque couche Linux
Rend les décisions de tuning auditables
Évite les réglages magiques copiés sans contexte

Risques / limites

Réglage bénéfique pour sequential mais mauvais pour random
discard continu pouvant dégrader certains workloads
sysctl global impactant d’autres applications
mount options dangereuses si cohérence/journal mal compris
benchmark sans rollback ni baseline exploitable

Matrice de décision Linux storage tuning

Question	Décision à prendre
Quel workload ?	OLTP random, sequential backup, NAS metadata, VM images, logs, Kubernetes, object gateway ou archive.
Quel device ?	HDD, SATA SSD, NVMe, LUN SAN, iSCSI, NFS, SMB, cloud disk, mdadm, LVM ou device mapper.
Quel filesystem ?	XFS pour grosses charges, ext4 polyvalent, ZFS/Btrfs si snapshots/checksums avancés sont voulus.
Quel risque ?	Perte de cohérence, write amplification, latence p99, cache pollution, trim/discard, rollback difficile.
Quelle preuve ?	fio/iostat/sar avant-après, graphes p95/p99, logs applicatifs, versions kernel/firmware, configuration persistante.
Quelle persistance ?	udev, sysctl.d, tuned, fstab, systemd timer fstrim, scripts d’audit et documentation exploitation.

Règle pratique : sur NVMe moderne, scheduler none ou mq-deadline ; sur desktop interactif BFQ peut aider ; toujours tester avec le vrai workload.

Runbook tuning Linux storage

Capturer baseline : iostat, vmstat, sar, fio, logs application, dmesg, SMART/NVMe health.
Identifier type I/O : random/sequential, block size, read/write, queue depth, cache hit, dirty pages.
Choisir un seul réglage : scheduler, readahead, mount option, fstrim, LVM stripe, sysctl, network.
Appliquer en temporaire quand possible, mesurer p95/p99, throughput, saturation et erreurs.
Valider côté application : transaction time, checkpoint, restore, backup, file listing, pod latency.
Persister proprement via sysctl.d, udev rules, fstab, tuned ou systemd timer.
Documenter rollback et seuils de monitoring.

# Discovery
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,DISC-MAX,DISC-GRAN,MOUNTPOINT
cat /sys/block/nvme0n1/queue/scheduler
cat /sys/block/nvme0n1/queue/read_ahead_kb
findmnt -no OPTIONS /data
iostat -x 1
vmstat 1
sar -d 1
dmesg -T | tail -100
smartctl -a /dev/sda
nvme smart-log /dev/nvme0

# Temporary tuning examples
echo none > /sys/block/nvme0n1/queue/scheduler
blockdev --setra 4096 /dev/nvme0n1
fstrim -v /data

# fio validation
fio --name=linux-storage --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting

NO-GO : changement global sans baseline, sans rollback, sans test applicatif, sans p99, ou avec options dangereuses copiées depuis Internet sans comprendre le workload.

36.15 SMB/CIFS tuning Linux

Définition opérationnelle

mount.cifs, cache, vers, multichannel selon support, signing, encryption, actimeo, credentials et workloads fichiers.

Chaîne Linux storage

Application→Filesystem→Page cache→Block layer→Driver / Fabric→Storage

Méthode : baseline → tune one knob → measure p99 → validate workload → persist setting → document rollback.

Composants à analyser

Composant	Rôle / explication
Workload	Base de données, VM, NAS, backup, logs, object gateway, Kubernetes node, streaming, random I/O.
Block layer	Device, scheduler, queue, LVM, mdadm, multipath, NVMe, iSCSI, discard, alignment.
Filesystem layer	XFS, ext4, ZFS, Btrfs, mount options, journal, metadata, cache, fragmentation.
Kernel layer	Page cache, dirty pages, writeback, readahead, IRQ, TCP buffers, memory pressure.
Observation	iostat, fio, sar, vmstat, pidstat, bpftrace, smartctl, nvme-cli, dmesg, application metrics.
Safety	Baseline, snapshot/backup, rollback plan, one-change-at-a-time, test window, production guardrails.

Cas d’usage

Optimiser une base PostgreSQL/MySQL/Oracle sur Linux
Réduire latence p99 d’un serveur NVMe
Améliorer throughput backup ou streaming
Stabiliser un serveur NFS/SMB
Éviter saturation writeback et dirty pages
Préparer un POC stockage Linux reproductible

Baseline→Hypothesis→Change→Measure→Persist→Rollback doc

Apports du tuning

Permet de gagner performance sans changer de matériel
Réduit latence p99 et comportements imprévisibles
Clarifie le rôle de chaque couche Linux
Rend les décisions de tuning auditables
Évite les réglages magiques copiés sans contexte

Risques / limites

Réglage bénéfique pour sequential mais mauvais pour random
discard continu pouvant dégrader certains workloads
sysctl global impactant d’autres applications
mount options dangereuses si cohérence/journal mal compris
benchmark sans rollback ni baseline exploitable

Matrice de décision Linux storage tuning

Question	Décision à prendre
Quel workload ?	OLTP random, sequential backup, NAS metadata, VM images, logs, Kubernetes, object gateway ou archive.
Quel device ?	HDD, SATA SSD, NVMe, LUN SAN, iSCSI, NFS, SMB, cloud disk, mdadm, LVM ou device mapper.
Quel filesystem ?	XFS pour grosses charges, ext4 polyvalent, ZFS/Btrfs si snapshots/checksums avancés sont voulus.
Quel risque ?	Perte de cohérence, write amplification, latence p99, cache pollution, trim/discard, rollback difficile.
Quelle preuve ?	fio/iostat/sar avant-après, graphes p95/p99, logs applicatifs, versions kernel/firmware, configuration persistante.
Quelle persistance ?	udev, sysctl.d, tuned, fstab, systemd timer fstrim, scripts d’audit et documentation exploitation.

Règle pratique : sur NVMe moderne, scheduler none ou mq-deadline ; sur desktop interactif BFQ peut aider ; toujours tester avec le vrai workload.

Runbook tuning Linux storage

Capturer baseline : iostat, vmstat, sar, fio, logs application, dmesg, SMART/NVMe health.
Identifier type I/O : random/sequential, block size, read/write, queue depth, cache hit, dirty pages.
Choisir un seul réglage : scheduler, readahead, mount option, fstrim, LVM stripe, sysctl, network.
Appliquer en temporaire quand possible, mesurer p95/p99, throughput, saturation et erreurs.
Valider côté application : transaction time, checkpoint, restore, backup, file listing, pod latency.
Persister proprement via sysctl.d, udev rules, fstab, tuned ou systemd timer.
Documenter rollback et seuils de monitoring.

# Discovery
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,DISC-MAX,DISC-GRAN,MOUNTPOINT
cat /sys/block/nvme0n1/queue/scheduler
cat /sys/block/nvme0n1/queue/read_ahead_kb
findmnt -no OPTIONS /data
iostat -x 1
vmstat 1
sar -d 1
dmesg -T | tail -100
smartctl -a /dev/sda
nvme smart-log /dev/nvme0

# Temporary tuning examples
echo none > /sys/block/nvme0n1/queue/scheduler
blockdev --setra 4096 /dev/nvme0n1
fstrim -v /data

# fio validation
fio --name=linux-storage --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting

NO-GO : changement global sans baseline, sans rollback, sans test applicatif, sans p99, ou avec options dangereuses copiées depuis Internet sans comprendre le workload.

36.16 Network tuning

Définition opérationnelle

MTU, IRQ/RPS/XPS, GRO/LRO, TCP buffers, congestion control, RDMA, packet loss et storage VLAN.

Chaîne Linux storage

Application→Filesystem→Page cache→Block layer→Driver / Fabric→Storage

Méthode : baseline → tune one knob → measure p99 → validate workload → persist setting → document rollback.

Composants à analyser

Composant	Rôle / explication
Workload	Base de données, VM, NAS, backup, logs, object gateway, Kubernetes node, streaming, random I/O.
Block layer	Device, scheduler, queue, LVM, mdadm, multipath, NVMe, iSCSI, discard, alignment.
Filesystem layer	XFS, ext4, ZFS, Btrfs, mount options, journal, metadata, cache, fragmentation.
Kernel layer	Page cache, dirty pages, writeback, readahead, IRQ, TCP buffers, memory pressure.
Observation	iostat, fio, sar, vmstat, pidstat, bpftrace, smartctl, nvme-cli, dmesg, application metrics.
Safety	Baseline, snapshot/backup, rollback plan, one-change-at-a-time, test window, production guardrails.

Cas d’usage

Optimiser une base PostgreSQL/MySQL/Oracle sur Linux
Réduire latence p99 d’un serveur NVMe
Améliorer throughput backup ou streaming
Stabiliser un serveur NFS/SMB
Éviter saturation writeback et dirty pages
Préparer un POC stockage Linux reproductible

Baseline→Hypothesis→Change→Measure→Persist→Rollback doc

Apports du tuning

Permet de gagner performance sans changer de matériel
Réduit latence p99 et comportements imprévisibles
Clarifie le rôle de chaque couche Linux
Rend les décisions de tuning auditables
Évite les réglages magiques copiés sans contexte

Risques / limites

Réglage bénéfique pour sequential mais mauvais pour random
discard continu pouvant dégrader certains workloads
sysctl global impactant d’autres applications
mount options dangereuses si cohérence/journal mal compris
benchmark sans rollback ni baseline exploitable

Matrice de décision Linux storage tuning

Question	Décision à prendre
Quel workload ?	OLTP random, sequential backup, NAS metadata, VM images, logs, Kubernetes, object gateway ou archive.
Quel device ?	HDD, SATA SSD, NVMe, LUN SAN, iSCSI, NFS, SMB, cloud disk, mdadm, LVM ou device mapper.
Quel filesystem ?	XFS pour grosses charges, ext4 polyvalent, ZFS/Btrfs si snapshots/checksums avancés sont voulus.
Quel risque ?	Perte de cohérence, write amplification, latence p99, cache pollution, trim/discard, rollback difficile.
Quelle preuve ?	fio/iostat/sar avant-après, graphes p95/p99, logs applicatifs, versions kernel/firmware, configuration persistante.
Quelle persistance ?	udev, sysctl.d, tuned, fstab, systemd timer fstrim, scripts d’audit et documentation exploitation.

Règle pratique : sur NVMe moderne, scheduler none ou mq-deadline ; sur desktop interactif BFQ peut aider ; toujours tester avec le vrai workload.

Runbook tuning Linux storage

Capturer baseline : iostat, vmstat, sar, fio, logs application, dmesg, SMART/NVMe health.
Identifier type I/O : random/sequential, block size, read/write, queue depth, cache hit, dirty pages.
Choisir un seul réglage : scheduler, readahead, mount option, fstrim, LVM stripe, sysctl, network.
Appliquer en temporaire quand possible, mesurer p95/p99, throughput, saturation et erreurs.
Valider côté application : transaction time, checkpoint, restore, backup, file listing, pod latency.
Persister proprement via sysctl.d, udev rules, fstab, tuned ou systemd timer.
Documenter rollback et seuils de monitoring.

# Discovery
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,DISC-MAX,DISC-GRAN,MOUNTPOINT
cat /sys/block/nvme0n1/queue/scheduler
cat /sys/block/nvme0n1/queue/read_ahead_kb
findmnt -no OPTIONS /data
iostat -x 1
vmstat 1
sar -d 1
dmesg -T | tail -100
smartctl -a /dev/sda
nvme smart-log /dev/nvme0

# Temporary tuning examples
echo none > /sys/block/nvme0n1/queue/scheduler
blockdev --setra 4096 /dev/nvme0n1
fstrim -v /data

# fio validation
fio --name=linux-storage --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting

NO-GO : changement global sans baseline, sans rollback, sans test applicatif, sans p99, ou avec options dangereuses copiées depuis Internet sans comprendre le workload.

36.17 Kernel VM dirty settings

Définition opérationnelle

vm.dirty_ratio, dirty_background_ratio, dirty_expire, writeback, swappiness et risques de latence writeback.

Chaîne Linux storage

Application→Filesystem→Page cache→Block layer→Driver / Fabric→Storage

Méthode : baseline → tune one knob → measure p99 → validate workload → persist setting → document rollback.

Composants à analyser

Composant	Rôle / explication
Workload	Base de données, VM, NAS, backup, logs, object gateway, Kubernetes node, streaming, random I/O.
Block layer	Device, scheduler, queue, LVM, mdadm, multipath, NVMe, iSCSI, discard, alignment.
Filesystem layer	XFS, ext4, ZFS, Btrfs, mount options, journal, metadata, cache, fragmentation.
Kernel layer	Page cache, dirty pages, writeback, readahead, IRQ, TCP buffers, memory pressure.
Observation	iostat, fio, sar, vmstat, pidstat, bpftrace, smartctl, nvme-cli, dmesg, application metrics.
Safety	Baseline, snapshot/backup, rollback plan, one-change-at-a-time, test window, production guardrails.

Cas d’usage

Optimiser une base PostgreSQL/MySQL/Oracle sur Linux
Réduire latence p99 d’un serveur NVMe
Améliorer throughput backup ou streaming
Stabiliser un serveur NFS/SMB
Éviter saturation writeback et dirty pages
Préparer un POC stockage Linux reproductible

Baseline→Hypothesis→Change→Measure→Persist→Rollback doc

Apports du tuning

Permet de gagner performance sans changer de matériel
Réduit latence p99 et comportements imprévisibles
Clarifie le rôle de chaque couche Linux
Rend les décisions de tuning auditables
Évite les réglages magiques copiés sans contexte

Risques / limites

Réglage bénéfique pour sequential mais mauvais pour random
discard continu pouvant dégrader certains workloads
sysctl global impactant d’autres applications
mount options dangereuses si cohérence/journal mal compris
benchmark sans rollback ni baseline exploitable

Matrice de décision Linux storage tuning

Question	Décision à prendre
Quel workload ?	OLTP random, sequential backup, NAS metadata, VM images, logs, Kubernetes, object gateway ou archive.
Quel device ?	HDD, SATA SSD, NVMe, LUN SAN, iSCSI, NFS, SMB, cloud disk, mdadm, LVM ou device mapper.
Quel filesystem ?	XFS pour grosses charges, ext4 polyvalent, ZFS/Btrfs si snapshots/checksums avancés sont voulus.
Quel risque ?	Perte de cohérence, write amplification, latence p99, cache pollution, trim/discard, rollback difficile.
Quelle preuve ?	fio/iostat/sar avant-après, graphes p95/p99, logs applicatifs, versions kernel/firmware, configuration persistante.
Quelle persistance ?	udev, sysctl.d, tuned, fstab, systemd timer fstrim, scripts d’audit et documentation exploitation.

Règle pratique : sur NVMe moderne, scheduler none ou mq-deadline ; sur desktop interactif BFQ peut aider ; toujours tester avec le vrai workload.

Runbook tuning Linux storage

Capturer baseline : iostat, vmstat, sar, fio, logs application, dmesg, SMART/NVMe health.
Identifier type I/O : random/sequential, block size, read/write, queue depth, cache hit, dirty pages.
Choisir un seul réglage : scheduler, readahead, mount option, fstrim, LVM stripe, sysctl, network.
Appliquer en temporaire quand possible, mesurer p95/p99, throughput, saturation et erreurs.
Valider côté application : transaction time, checkpoint, restore, backup, file listing, pod latency.
Persister proprement via sysctl.d, udev rules, fstab, tuned ou systemd timer.
Documenter rollback et seuils de monitoring.

# Discovery
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,DISC-MAX,DISC-GRAN,MOUNTPOINT
cat /sys/block/nvme0n1/queue/scheduler
cat /sys/block/nvme0n1/queue/read_ahead_kb
findmnt -no OPTIONS /data
iostat -x 1
vmstat 1
sar -d 1
dmesg -T | tail -100
smartctl -a /dev/sda
nvme smart-log /dev/nvme0

# Temporary tuning examples
echo none > /sys/block/nvme0n1/queue/scheduler
blockdev --setra 4096 /dev/nvme0n1
fstrim -v /data

# fio validation
fio --name=linux-storage --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting

NO-GO : changement global sans baseline, sans rollback, sans test applicatif, sans p99, ou avec options dangereuses copiées depuis Internet sans comprendre le workload.

36.18 mdadm / RAID software

Définition opérationnelle

Chunk size, stripe_cache_size, bitmap, resync speed, read-ahead, write-mostly, monitoring et rebuild impact.

Chaîne Linux storage

Application→Filesystem→Page cache→Block layer→Driver / Fabric→Storage

Méthode : baseline → tune one knob → measure p99 → validate workload → persist setting → document rollback.

Composants à analyser

Composant	Rôle / explication
Workload	Base de données, VM, NAS, backup, logs, object gateway, Kubernetes node, streaming, random I/O.
Block layer	Device, scheduler, queue, LVM, mdadm, multipath, NVMe, iSCSI, discard, alignment.
Filesystem layer	XFS, ext4, ZFS, Btrfs, mount options, journal, metadata, cache, fragmentation.
Kernel layer	Page cache, dirty pages, writeback, readahead, IRQ, TCP buffers, memory pressure.
Observation	iostat, fio, sar, vmstat, pidstat, bpftrace, smartctl, nvme-cli, dmesg, application metrics.
Safety	Baseline, snapshot/backup, rollback plan, one-change-at-a-time, test window, production guardrails.

Cas d’usage

Optimiser une base PostgreSQL/MySQL/Oracle sur Linux
Réduire latence p99 d’un serveur NVMe
Améliorer throughput backup ou streaming
Stabiliser un serveur NFS/SMB
Éviter saturation writeback et dirty pages
Préparer un POC stockage Linux reproductible

Baseline→Hypothesis→Change→Measure→Persist→Rollback doc

Apports du tuning

Permet de gagner performance sans changer de matériel
Réduit latence p99 et comportements imprévisibles
Clarifie le rôle de chaque couche Linux
Rend les décisions de tuning auditables
Évite les réglages magiques copiés sans contexte

Risques / limites

Réglage bénéfique pour sequential mais mauvais pour random
discard continu pouvant dégrader certains workloads
sysctl global impactant d’autres applications
mount options dangereuses si cohérence/journal mal compris
benchmark sans rollback ni baseline exploitable

Matrice de décision Linux storage tuning

Question	Décision à prendre
Quel workload ?	OLTP random, sequential backup, NAS metadata, VM images, logs, Kubernetes, object gateway ou archive.
Quel device ?	HDD, SATA SSD, NVMe, LUN SAN, iSCSI, NFS, SMB, cloud disk, mdadm, LVM ou device mapper.
Quel filesystem ?	XFS pour grosses charges, ext4 polyvalent, ZFS/Btrfs si snapshots/checksums avancés sont voulus.
Quel risque ?	Perte de cohérence, write amplification, latence p99, cache pollution, trim/discard, rollback difficile.
Quelle preuve ?	fio/iostat/sar avant-après, graphes p95/p99, logs applicatifs, versions kernel/firmware, configuration persistante.
Quelle persistance ?	udev, sysctl.d, tuned, fstab, systemd timer fstrim, scripts d’audit et documentation exploitation.

Règle pratique : sur NVMe moderne, scheduler none ou mq-deadline ; sur desktop interactif BFQ peut aider ; toujours tester avec le vrai workload.

Runbook tuning Linux storage

Capturer baseline : iostat, vmstat, sar, fio, logs application, dmesg, SMART/NVMe health.
Identifier type I/O : random/sequential, block size, read/write, queue depth, cache hit, dirty pages.
Choisir un seul réglage : scheduler, readahead, mount option, fstrim, LVM stripe, sysctl, network.
Appliquer en temporaire quand possible, mesurer p95/p99, throughput, saturation et erreurs.
Valider côté application : transaction time, checkpoint, restore, backup, file listing, pod latency.
Persister proprement via sysctl.d, udev rules, fstab, tuned ou systemd timer.
Documenter rollback et seuils de monitoring.

# Discovery
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,DISC-MAX,DISC-GRAN,MOUNTPOINT
cat /sys/block/nvme0n1/queue/scheduler
cat /sys/block/nvme0n1/queue/read_ahead_kb
findmnt -no OPTIONS /data
iostat -x 1
vmstat 1
sar -d 1
dmesg -T | tail -100
smartctl -a /dev/sda
nvme smart-log /dev/nvme0

# Temporary tuning examples
echo none > /sys/block/nvme0n1/queue/scheduler
blockdev --setra 4096 /dev/nvme0n1
fstrim -v /data

# fio validation
fio --name=linux-storage --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting

NO-GO : changement global sans baseline, sans rollback, sans test applicatif, sans p99, ou avec options dangereuses copiées depuis Internet sans comprendre le workload.

36.19 Linux storage pour bases

Définition opérationnelle

Oracle, PostgreSQL, MySQL, SQL Server Linux : direct I/O, WAL, hugepages, fsync, scheduler, XFS/ext4.

Chaîne Linux storage

Application→Filesystem→Page cache→Block layer→Driver / Fabric→Storage

Méthode : baseline → tune one knob → measure p99 → validate workload → persist setting → document rollback.

Composants à analyser

Composant	Rôle / explication
Workload	Base de données, VM, NAS, backup, logs, object gateway, Kubernetes node, streaming, random I/O.
Block layer	Device, scheduler, queue, LVM, mdadm, multipath, NVMe, iSCSI, discard, alignment.
Filesystem layer	XFS, ext4, ZFS, Btrfs, mount options, journal, metadata, cache, fragmentation.
Kernel layer	Page cache, dirty pages, writeback, readahead, IRQ, TCP buffers, memory pressure.
Observation	iostat, fio, sar, vmstat, pidstat, bpftrace, smartctl, nvme-cli, dmesg, application metrics.
Safety	Baseline, snapshot/backup, rollback plan, one-change-at-a-time, test window, production guardrails.

Cas d’usage

Optimiser une base PostgreSQL/MySQL/Oracle sur Linux
Réduire latence p99 d’un serveur NVMe
Améliorer throughput backup ou streaming
Stabiliser un serveur NFS/SMB
Éviter saturation writeback et dirty pages
Préparer un POC stockage Linux reproductible

Baseline→Hypothesis→Change→Measure→Persist→Rollback doc

Apports du tuning

Permet de gagner performance sans changer de matériel
Réduit latence p99 et comportements imprévisibles
Clarifie le rôle de chaque couche Linux
Rend les décisions de tuning auditables
Évite les réglages magiques copiés sans contexte

Risques / limites

Réglage bénéfique pour sequential mais mauvais pour random
discard continu pouvant dégrader certains workloads
sysctl global impactant d’autres applications
mount options dangereuses si cohérence/journal mal compris
benchmark sans rollback ni baseline exploitable

Matrice de décision Linux storage tuning

Question	Décision à prendre
Quel workload ?	OLTP random, sequential backup, NAS metadata, VM images, logs, Kubernetes, object gateway ou archive.
Quel device ?	HDD, SATA SSD, NVMe, LUN SAN, iSCSI, NFS, SMB, cloud disk, mdadm, LVM ou device mapper.
Quel filesystem ?	XFS pour grosses charges, ext4 polyvalent, ZFS/Btrfs si snapshots/checksums avancés sont voulus.
Quel risque ?	Perte de cohérence, write amplification, latence p99, cache pollution, trim/discard, rollback difficile.
Quelle preuve ?	fio/iostat/sar avant-après, graphes p95/p99, logs applicatifs, versions kernel/firmware, configuration persistante.
Quelle persistance ?	udev, sysctl.d, tuned, fstab, systemd timer fstrim, scripts d’audit et documentation exploitation.

Règle pratique : sur NVMe moderne, scheduler none ou mq-deadline ; sur desktop interactif BFQ peut aider ; toujours tester avec le vrai workload.

Runbook tuning Linux storage

Capturer baseline : iostat, vmstat, sar, fio, logs application, dmesg, SMART/NVMe health.
Identifier type I/O : random/sequential, block size, read/write, queue depth, cache hit, dirty pages.
Choisir un seul réglage : scheduler, readahead, mount option, fstrim, LVM stripe, sysctl, network.
Appliquer en temporaire quand possible, mesurer p95/p99, throughput, saturation et erreurs.
Valider côté application : transaction time, checkpoint, restore, backup, file listing, pod latency.
Persister proprement via sysctl.d, udev rules, fstab, tuned ou systemd timer.
Documenter rollback et seuils de monitoring.

# Discovery
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,DISC-MAX,DISC-GRAN,MOUNTPOINT
cat /sys/block/nvme0n1/queue/scheduler
cat /sys/block/nvme0n1/queue/read_ahead_kb
findmnt -no OPTIONS /data
iostat -x 1
vmstat 1
sar -d 1
dmesg -T | tail -100
smartctl -a /dev/sda
nvme smart-log /dev/nvme0

# Temporary tuning examples
echo none > /sys/block/nvme0n1/queue/scheduler
blockdev --setra 4096 /dev/nvme0n1
fstrim -v /data

# fio validation
fio --name=linux-storage --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting

NO-GO : changement global sans baseline, sans rollback, sans test applicatif, sans p99, ou avec options dangereuses copiées depuis Internet sans comprendre le workload.

36.20 Containers et Kubernetes nodes

Définition opérationnelle

overlayfs, containerd, kubelet eviction, local PV, CSI, image GC, journald logs et node disk pressure.

Chaîne Linux storage

Application→Filesystem→Page cache→Block layer→Driver / Fabric→Storage

Méthode : baseline → tune one knob → measure p99 → validate workload → persist setting → document rollback.

Composants à analyser

Composant	Rôle / explication
Workload	Base de données, VM, NAS, backup, logs, object gateway, Kubernetes node, streaming, random I/O.
Block layer	Device, scheduler, queue, LVM, mdadm, multipath, NVMe, iSCSI, discard, alignment.
Filesystem layer	XFS, ext4, ZFS, Btrfs, mount options, journal, metadata, cache, fragmentation.
Kernel layer	Page cache, dirty pages, writeback, readahead, IRQ, TCP buffers, memory pressure.
Observation	iostat, fio, sar, vmstat, pidstat, bpftrace, smartctl, nvme-cli, dmesg, application metrics.
Safety	Baseline, snapshot/backup, rollback plan, one-change-at-a-time, test window, production guardrails.

Cas d’usage

Optimiser une base PostgreSQL/MySQL/Oracle sur Linux
Réduire latence p99 d’un serveur NVMe
Améliorer throughput backup ou streaming
Stabiliser un serveur NFS/SMB
Éviter saturation writeback et dirty pages
Préparer un POC stockage Linux reproductible

Baseline→Hypothesis→Change→Measure→Persist→Rollback doc

Apports du tuning

Permet de gagner performance sans changer de matériel
Réduit latence p99 et comportements imprévisibles
Clarifie le rôle de chaque couche Linux
Rend les décisions de tuning auditables
Évite les réglages magiques copiés sans contexte

Risques / limites

Réglage bénéfique pour sequential mais mauvais pour random
discard continu pouvant dégrader certains workloads
sysctl global impactant d’autres applications
mount options dangereuses si cohérence/journal mal compris
benchmark sans rollback ni baseline exploitable

Matrice de décision Linux storage tuning

Question	Décision à prendre
Quel workload ?	OLTP random, sequential backup, NAS metadata, VM images, logs, Kubernetes, object gateway ou archive.
Quel device ?	HDD, SATA SSD, NVMe, LUN SAN, iSCSI, NFS, SMB, cloud disk, mdadm, LVM ou device mapper.
Quel filesystem ?	XFS pour grosses charges, ext4 polyvalent, ZFS/Btrfs si snapshots/checksums avancés sont voulus.
Quel risque ?	Perte de cohérence, write amplification, latence p99, cache pollution, trim/discard, rollback difficile.
Quelle preuve ?	fio/iostat/sar avant-après, graphes p95/p99, logs applicatifs, versions kernel/firmware, configuration persistante.
Quelle persistance ?	udev, sysctl.d, tuned, fstab, systemd timer fstrim, scripts d’audit et documentation exploitation.

Règle pratique : sur NVMe moderne, scheduler none ou mq-deadline ; sur desktop interactif BFQ peut aider ; toujours tester avec le vrai workload.

Runbook tuning Linux storage

Capturer baseline : iostat, vmstat, sar, fio, logs application, dmesg, SMART/NVMe health.
Identifier type I/O : random/sequential, block size, read/write, queue depth, cache hit, dirty pages.
Choisir un seul réglage : scheduler, readahead, mount option, fstrim, LVM stripe, sysctl, network.
Appliquer en temporaire quand possible, mesurer p95/p99, throughput, saturation et erreurs.
Valider côté application : transaction time, checkpoint, restore, backup, file listing, pod latency.
Persister proprement via sysctl.d, udev rules, fstab, tuned ou systemd timer.
Documenter rollback et seuils de monitoring.

# Discovery
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,DISC-MAX,DISC-GRAN,MOUNTPOINT
cat /sys/block/nvme0n1/queue/scheduler
cat /sys/block/nvme0n1/queue/read_ahead_kb
findmnt -no OPTIONS /data
iostat -x 1
vmstat 1
sar -d 1
dmesg -T | tail -100
smartctl -a /dev/sda
nvme smart-log /dev/nvme0

# Temporary tuning examples
echo none > /sys/block/nvme0n1/queue/scheduler
blockdev --setra 4096 /dev/nvme0n1
fstrim -v /data

# fio validation
fio --name=linux-storage --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting

NO-GO : changement global sans baseline, sans rollback, sans test applicatif, sans p99, ou avec options dangereuses copiées depuis Internet sans comprendre le workload.

36.21 Logs et journald

Définition opérationnelle

journald, logrotate, filesystem pressure, sync writes, write amplification, partitionnement et rétention logs.

Chaîne Linux storage

Application→Filesystem→Page cache→Block layer→Driver / Fabric→Storage

Méthode : baseline → tune one knob → measure p99 → validate workload → persist setting → document rollback.

Composants à analyser

Composant	Rôle / explication
Workload	Base de données, VM, NAS, backup, logs, object gateway, Kubernetes node, streaming, random I/O.
Block layer	Device, scheduler, queue, LVM, mdadm, multipath, NVMe, iSCSI, discard, alignment.
Filesystem layer	XFS, ext4, ZFS, Btrfs, mount options, journal, metadata, cache, fragmentation.
Kernel layer	Page cache, dirty pages, writeback, readahead, IRQ, TCP buffers, memory pressure.
Observation	iostat, fio, sar, vmstat, pidstat, bpftrace, smartctl, nvme-cli, dmesg, application metrics.
Safety	Baseline, snapshot/backup, rollback plan, one-change-at-a-time, test window, production guardrails.

Cas d’usage

Optimiser une base PostgreSQL/MySQL/Oracle sur Linux
Réduire latence p99 d’un serveur NVMe
Améliorer throughput backup ou streaming
Stabiliser un serveur NFS/SMB
Éviter saturation writeback et dirty pages
Préparer un POC stockage Linux reproductible

Baseline→Hypothesis→Change→Measure→Persist→Rollback doc

Apports du tuning

Permet de gagner performance sans changer de matériel
Réduit latence p99 et comportements imprévisibles
Clarifie le rôle de chaque couche Linux
Rend les décisions de tuning auditables
Évite les réglages magiques copiés sans contexte

Risques / limites

Réglage bénéfique pour sequential mais mauvais pour random
discard continu pouvant dégrader certains workloads
sysctl global impactant d’autres applications
mount options dangereuses si cohérence/journal mal compris
benchmark sans rollback ni baseline exploitable

Matrice de décision Linux storage tuning

Question	Décision à prendre
Quel workload ?	OLTP random, sequential backup, NAS metadata, VM images, logs, Kubernetes, object gateway ou archive.
Quel device ?	HDD, SATA SSD, NVMe, LUN SAN, iSCSI, NFS, SMB, cloud disk, mdadm, LVM ou device mapper.
Quel filesystem ?	XFS pour grosses charges, ext4 polyvalent, ZFS/Btrfs si snapshots/checksums avancés sont voulus.
Quel risque ?	Perte de cohérence, write amplification, latence p99, cache pollution, trim/discard, rollback difficile.
Quelle preuve ?	fio/iostat/sar avant-après, graphes p95/p99, logs applicatifs, versions kernel/firmware, configuration persistante.
Quelle persistance ?	udev, sysctl.d, tuned, fstab, systemd timer fstrim, scripts d’audit et documentation exploitation.

Règle pratique : sur NVMe moderne, scheduler none ou mq-deadline ; sur desktop interactif BFQ peut aider ; toujours tester avec le vrai workload.

Runbook tuning Linux storage

Capturer baseline : iostat, vmstat, sar, fio, logs application, dmesg, SMART/NVMe health.
Identifier type I/O : random/sequential, block size, read/write, queue depth, cache hit, dirty pages.
Choisir un seul réglage : scheduler, readahead, mount option, fstrim, LVM stripe, sysctl, network.
Appliquer en temporaire quand possible, mesurer p95/p99, throughput, saturation et erreurs.
Valider côté application : transaction time, checkpoint, restore, backup, file listing, pod latency.
Persister proprement via sysctl.d, udev rules, fstab, tuned ou systemd timer.
Documenter rollback et seuils de monitoring.

# Discovery
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,DISC-MAX,DISC-GRAN,MOUNTPOINT
cat /sys/block/nvme0n1/queue/scheduler
cat /sys/block/nvme0n1/queue/read_ahead_kb
findmnt -no OPTIONS /data
iostat -x 1
vmstat 1
sar -d 1
dmesg -T | tail -100
smartctl -a /dev/sda
nvme smart-log /dev/nvme0

# Temporary tuning examples
echo none > /sys/block/nvme0n1/queue/scheduler
blockdev --setra 4096 /dev/nvme0n1
fstrim -v /data

# fio validation
fio --name=linux-storage --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting

NO-GO : changement global sans baseline, sans rollback, sans test applicatif, sans p99, ou avec options dangereuses copiées depuis Internet sans comprendre le workload.

36.22 Monitoring Linux storage

Définition opérationnelle

iostat, blktrace, bpftrace, perf, pidstat, smartctl, nvme-cli, sar, Prometheus node_exporter.

Chaîne Linux storage

Application→Filesystem→Page cache→Block layer→Driver / Fabric→Storage

Méthode : baseline → tune one knob → measure p99 → validate workload → persist setting → document rollback.

Composants à analyser

Composant	Rôle / explication
Workload	Base de données, VM, NAS, backup, logs, object gateway, Kubernetes node, streaming, random I/O.
Block layer	Device, scheduler, queue, LVM, mdadm, multipath, NVMe, iSCSI, discard, alignment.
Filesystem layer	XFS, ext4, ZFS, Btrfs, mount options, journal, metadata, cache, fragmentation.
Kernel layer	Page cache, dirty pages, writeback, readahead, IRQ, TCP buffers, memory pressure.
Observation	iostat, fio, sar, vmstat, pidstat, bpftrace, smartctl, nvme-cli, dmesg, application metrics.
Safety	Baseline, snapshot/backup, rollback plan, one-change-at-a-time, test window, production guardrails.

Cas d’usage

Optimiser une base PostgreSQL/MySQL/Oracle sur Linux
Réduire latence p99 d’un serveur NVMe
Améliorer throughput backup ou streaming
Stabiliser un serveur NFS/SMB
Éviter saturation writeback et dirty pages
Préparer un POC stockage Linux reproductible

Baseline→Hypothesis→Change→Measure→Persist→Rollback doc

Apports du tuning

Permet de gagner performance sans changer de matériel
Réduit latence p99 et comportements imprévisibles
Clarifie le rôle de chaque couche Linux
Rend les décisions de tuning auditables
Évite les réglages magiques copiés sans contexte

Risques / limites

Réglage bénéfique pour sequential mais mauvais pour random
discard continu pouvant dégrader certains workloads
sysctl global impactant d’autres applications
mount options dangereuses si cohérence/journal mal compris
benchmark sans rollback ni baseline exploitable

Matrice de décision Linux storage tuning

Question	Décision à prendre
Quel workload ?	OLTP random, sequential backup, NAS metadata, VM images, logs, Kubernetes, object gateway ou archive.
Quel device ?	HDD, SATA SSD, NVMe, LUN SAN, iSCSI, NFS, SMB, cloud disk, mdadm, LVM ou device mapper.
Quel filesystem ?	XFS pour grosses charges, ext4 polyvalent, ZFS/Btrfs si snapshots/checksums avancés sont voulus.
Quel risque ?	Perte de cohérence, write amplification, latence p99, cache pollution, trim/discard, rollback difficile.
Quelle preuve ?	fio/iostat/sar avant-après, graphes p95/p99, logs applicatifs, versions kernel/firmware, configuration persistante.
Quelle persistance ?	udev, sysctl.d, tuned, fstab, systemd timer fstrim, scripts d’audit et documentation exploitation.

Règle pratique : sur NVMe moderne, scheduler none ou mq-deadline ; sur desktop interactif BFQ peut aider ; toujours tester avec le vrai workload.

Runbook tuning Linux storage

Capturer baseline : iostat, vmstat, sar, fio, logs application, dmesg, SMART/NVMe health.
Identifier type I/O : random/sequential, block size, read/write, queue depth, cache hit, dirty pages.
Choisir un seul réglage : scheduler, readahead, mount option, fstrim, LVM stripe, sysctl, network.
Appliquer en temporaire quand possible, mesurer p95/p99, throughput, saturation et erreurs.
Valider côté application : transaction time, checkpoint, restore, backup, file listing, pod latency.
Persister proprement via sysctl.d, udev rules, fstab, tuned ou systemd timer.
Documenter rollback et seuils de monitoring.

# Discovery
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,DISC-MAX,DISC-GRAN,MOUNTPOINT
cat /sys/block/nvme0n1/queue/scheduler
cat /sys/block/nvme0n1/queue/read_ahead_kb
findmnt -no OPTIONS /data
iostat -x 1
vmstat 1
sar -d 1
dmesg -T | tail -100
smartctl -a /dev/sda
nvme smart-log /dev/nvme0

# Temporary tuning examples
echo none > /sys/block/nvme0n1/queue/scheduler
blockdev --setra 4096 /dev/nvme0n1
fstrim -v /data

# fio validation
fio --name=linux-storage --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting

NO-GO : changement global sans baseline, sans rollback, sans test applicatif, sans p99, ou avec options dangereuses copiées depuis Internet sans comprendre le workload.

36.23 sysctl, udev et persistance

Définition opérationnelle

Rendre les réglages durables : sysctl.d, udev rules, tuned, systemd timers, fstab et documentation.

Chaîne Linux storage

Application→Filesystem→Page cache→Block layer→Driver / Fabric→Storage

Méthode : baseline → tune one knob → measure p99 → validate workload → persist setting → document rollback.

Composants à analyser

Composant	Rôle / explication
Workload	Base de données, VM, NAS, backup, logs, object gateway, Kubernetes node, streaming, random I/O.
Block layer	Device, scheduler, queue, LVM, mdadm, multipath, NVMe, iSCSI, discard, alignment.
Filesystem layer	XFS, ext4, ZFS, Btrfs, mount options, journal, metadata, cache, fragmentation.
Kernel layer	Page cache, dirty pages, writeback, readahead, IRQ, TCP buffers, memory pressure.
Observation	iostat, fio, sar, vmstat, pidstat, bpftrace, smartctl, nvme-cli, dmesg, application metrics.
Safety	Baseline, snapshot/backup, rollback plan, one-change-at-a-time, test window, production guardrails.

Cas d’usage

Optimiser une base PostgreSQL/MySQL/Oracle sur Linux
Réduire latence p99 d’un serveur NVMe
Améliorer throughput backup ou streaming
Stabiliser un serveur NFS/SMB
Éviter saturation writeback et dirty pages
Préparer un POC stockage Linux reproductible

Baseline→Hypothesis→Change→Measure→Persist→Rollback doc

Apports du tuning

Permet de gagner performance sans changer de matériel
Réduit latence p99 et comportements imprévisibles
Clarifie le rôle de chaque couche Linux
Rend les décisions de tuning auditables
Évite les réglages magiques copiés sans contexte

Risques / limites

Réglage bénéfique pour sequential mais mauvais pour random
discard continu pouvant dégrader certains workloads
sysctl global impactant d’autres applications
mount options dangereuses si cohérence/journal mal compris
benchmark sans rollback ni baseline exploitable

Matrice de décision Linux storage tuning

Question	Décision à prendre
Quel workload ?	OLTP random, sequential backup, NAS metadata, VM images, logs, Kubernetes, object gateway ou archive.
Quel device ?	HDD, SATA SSD, NVMe, LUN SAN, iSCSI, NFS, SMB, cloud disk, mdadm, LVM ou device mapper.
Quel filesystem ?	XFS pour grosses charges, ext4 polyvalent, ZFS/Btrfs si snapshots/checksums avancés sont voulus.
Quel risque ?	Perte de cohérence, write amplification, latence p99, cache pollution, trim/discard, rollback difficile.
Quelle preuve ?	fio/iostat/sar avant-après, graphes p95/p99, logs applicatifs, versions kernel/firmware, configuration persistante.
Quelle persistance ?	udev, sysctl.d, tuned, fstab, systemd timer fstrim, scripts d’audit et documentation exploitation.

Règle pratique : sur NVMe moderne, scheduler none ou mq-deadline ; sur desktop interactif BFQ peut aider ; toujours tester avec le vrai workload.

Runbook tuning Linux storage

Capturer baseline : iostat, vmstat, sar, fio, logs application, dmesg, SMART/NVMe health.
Identifier type I/O : random/sequential, block size, read/write, queue depth, cache hit, dirty pages.
Choisir un seul réglage : scheduler, readahead, mount option, fstrim, LVM stripe, sysctl, network.
Appliquer en temporaire quand possible, mesurer p95/p99, throughput, saturation et erreurs.
Valider côté application : transaction time, checkpoint, restore, backup, file listing, pod latency.
Persister proprement via sysctl.d, udev rules, fstab, tuned ou systemd timer.
Documenter rollback et seuils de monitoring.

# Discovery
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,DISC-MAX,DISC-GRAN,MOUNTPOINT
cat /sys/block/nvme0n1/queue/scheduler
cat /sys/block/nvme0n1/queue/read_ahead_kb
findmnt -no OPTIONS /data
iostat -x 1
vmstat 1
sar -d 1
dmesg -T | tail -100
smartctl -a /dev/sda
nvme smart-log /dev/nvme0

# Temporary tuning examples
echo none > /sys/block/nvme0n1/queue/scheduler
blockdev --setra 4096 /dev/nvme0n1
fstrim -v /data

# fio validation
fio --name=linux-storage --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting

NO-GO : changement global sans baseline, sans rollback, sans test applicatif, sans p99, ou avec options dangereuses copiées depuis Internet sans comprendre le workload.

36.24 Checklist tuning Linux storage

Définition opérationnelle

GO/NO-GO : baseline, rollback, un changement à la fois, p99, fstrim, scheduler, mount options, monitoring.

Chaîne Linux storage

Application→Filesystem→Page cache→Block layer→Driver / Fabric→Storage

Méthode : baseline → tune one knob → measure p99 → validate workload → persist setting → document rollback.

Composants à analyser

Composant	Rôle / explication
Workload	Base de données, VM, NAS, backup, logs, object gateway, Kubernetes node, streaming, random I/O.
Block layer	Device, scheduler, queue, LVM, mdadm, multipath, NVMe, iSCSI, discard, alignment.
Filesystem layer	XFS, ext4, ZFS, Btrfs, mount options, journal, metadata, cache, fragmentation.
Kernel layer	Page cache, dirty pages, writeback, readahead, IRQ, TCP buffers, memory pressure.
Observation	iostat, fio, sar, vmstat, pidstat, bpftrace, smartctl, nvme-cli, dmesg, application metrics.
Safety	Baseline, snapshot/backup, rollback plan, one-change-at-a-time, test window, production guardrails.

Cas d’usage

Optimiser une base PostgreSQL/MySQL/Oracle sur Linux
Réduire latence p99 d’un serveur NVMe
Améliorer throughput backup ou streaming
Stabiliser un serveur NFS/SMB
Éviter saturation writeback et dirty pages
Préparer un POC stockage Linux reproductible

Baseline→Hypothesis→Change→Measure→Persist→Rollback doc

Apports du tuning

Permet de gagner performance sans changer de matériel
Réduit latence p99 et comportements imprévisibles
Clarifie le rôle de chaque couche Linux
Rend les décisions de tuning auditables
Évite les réglages magiques copiés sans contexte

Risques / limites

Réglage bénéfique pour sequential mais mauvais pour random
discard continu pouvant dégrader certains workloads
sysctl global impactant d’autres applications
mount options dangereuses si cohérence/journal mal compris
benchmark sans rollback ni baseline exploitable

Matrice de décision Linux storage tuning

Question	Décision à prendre
Quel workload ?	OLTP random, sequential backup, NAS metadata, VM images, logs, Kubernetes, object gateway ou archive.
Quel device ?	HDD, SATA SSD, NVMe, LUN SAN, iSCSI, NFS, SMB, cloud disk, mdadm, LVM ou device mapper.
Quel filesystem ?	XFS pour grosses charges, ext4 polyvalent, ZFS/Btrfs si snapshots/checksums avancés sont voulus.
Quel risque ?	Perte de cohérence, write amplification, latence p99, cache pollution, trim/discard, rollback difficile.
Quelle preuve ?	fio/iostat/sar avant-après, graphes p95/p99, logs applicatifs, versions kernel/firmware, configuration persistante.
Quelle persistance ?	udev, sysctl.d, tuned, fstab, systemd timer fstrim, scripts d’audit et documentation exploitation.

Règle pratique : sur NVMe moderne, scheduler none ou mq-deadline ; sur desktop interactif BFQ peut aider ; toujours tester avec le vrai workload.

Runbook tuning Linux storage

Capturer baseline : iostat, vmstat, sar, fio, logs application, dmesg, SMART/NVMe health.
Identifier type I/O : random/sequential, block size, read/write, queue depth, cache hit, dirty pages.
Choisir un seul réglage : scheduler, readahead, mount option, fstrim, LVM stripe, sysctl, network.
Appliquer en temporaire quand possible, mesurer p95/p99, throughput, saturation et erreurs.
Valider côté application : transaction time, checkpoint, restore, backup, file listing, pod latency.
Persister proprement via sysctl.d, udev rules, fstab, tuned ou systemd timer.
Documenter rollback et seuils de monitoring.

# Discovery
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,DISC-MAX,DISC-GRAN,MOUNTPOINT
cat /sys/block/nvme0n1/queue/scheduler
cat /sys/block/nvme0n1/queue/read_ahead_kb
findmnt -no OPTIONS /data
iostat -x 1
vmstat 1
sar -d 1
dmesg -T | tail -100
smartctl -a /dev/sda
nvme smart-log /dev/nvme0

# Temporary tuning examples
echo none > /sys/block/nvme0n1/queue/scheduler
blockdev --setra 4096 /dev/nvme0n1
fstrim -v /data

# fio validation
fio --name=linux-storage --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --time_based --runtime=300 --group_reporting

NO-GO : changement global sans baseline, sans rollback, sans test applicatif, sans p99, ou avec options dangereuses copiées depuis Internet sans comprendre le workload.