Re: Fragmentation: encore un problème sur SSD?

Défragmenter des fichiers sur un SSD est inutile

OK. Donc si on va jusqu'au bout du raisonnement, tu veux dire que si aucun bloc de ton (FS|fichier) n'est séquentiel ça ne pose aucun problème ?

Faisons un petit test sur un "vieux" SanDisk Ultra II (SDSSDHII480G) avec LVM + luks + ext4:

$ cat seqread.fio 
[seqread]
rw=read
size=4g
directory=/xxx/fio
$ fio seqread.fio 
seqread: (g=0): rw=read, bs=4096B-4096B,4096B-4096B,4096B-4096B, ioengine=psync, iodepth=1
fio-2.18
Starting 1 process
seqread: Laying out IO file(s) (1 file(s) / 4096MiB)
Jobs: 1 (f=1): [R(1)][100.0%][r=235MiB/s,w=0KiB/s][r=60.1k,w=0 IOPS][eta 00m:00s]
seqread: (groupid=0, jobs=1): err= 0: pid=7370: Tue Aug 15 12:58:14 2017
 read: IOPS=59.7k, BW=233MiB/s (244MB/s)(4096MiB/17586msec)
 clat (usec): min=0, max=8186, avg=16.28, stdev=123.09
 lat (usec): min=0, max=8186, avg=16.34, stdev=123.09
 clat percentiles (usec):
 | 1.00th=[ 0], 5.00th=[ 0], 10.00th=[ 0], 20.00th=[ 1],
 | 30.00th=[ 1], 40.00th=[ 1], 50.00th=[ 1], 60.00th=[ 1],
 | 70.00th=[ 1], 80.00th=[ 1], 90.00th=[ 1], 95.00th=[ 1],
 | 99.00th=[ 956], 99.50th=[ 988], 99.90th=[ 1020], 99.95th=[ 1064],
 | 99.99th=[ 1544]
 lat (usec) : 2=96.33%, 4=1.13%, 10=0.66%, 20=0.25%, 50=0.06%
 lat (usec) : 100=0.01%, 250=0.01%, 500=0.01%, 750=0.01%, 1000=1.32%
 lat (msec) : 2=0.24%, 4=0.01%, 10=0.01%
 cpu : usr=4.05%, sys=9.50%, ctx=16556, majf=0, minf=9
 IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
 submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
 complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
 issued rwt: total=1048576,0,0, short=0,0,0, dropped=0,0,0
 latency : target=0, window=0, percentile=100.00%, depth=1
Run status group 0 (all jobs):
 READ: bw=233MiB/s (244MB/s), 233MiB/s-233MiB/s (244MB/s-244MB/s), io=4096MiB (4295MB), run=17586-17586msec
Disk stats (read/write):
 dm-1: ios=16233/21, merge=0/0, ticks=32472/42, in_queue=32525, util=99.52%, aggrios=16433/24, aggrmerge=0/0, aggrticks=32844/42, aggrin_queue=32890, aggrutil=99.43%
 dm-0: ios=16433/24, merge=0/0, ticks=32844/42, in_queue=32890, util=99.43%, aggrios=16431/9, aggrmerge=2/15, aggrticks=24757/23, aggrin_queue=24767, aggrutil=99.43%
$ cat randread.fio 
[randread]
rw=randread
size=4g
directory=/xxx/fio
$ fio randread.fio
randread: (g=0): rw=randread, bs=4096B-4096B,4096B-4096B,4096B-4096B, ioengine=psync, iodepth=1
fio-2.18
Starting 1 process
randread: Laying out IO file(s) (1 file(s) / 4096MiB)
Jobs: 1 (f=1): [r(1)][100.0%][r=17.5MiB/s,w=0KiB/s][r=4462,w=0 IOPS][eta 00m:00s]
randread: (groupid=0, jobs=1): err= 0: pid=7443: Tue Aug 15 13:02:44 2017
 read: IOPS=4460, BW=17.5MiB/s (18.3MB/s)(4096MiB/235079msec)
 clat (usec): min=106, max=401746, avg=221.49, stdev=467.85
 lat (usec): min=106, max=401747, avg=221.70, stdev=467.85
 clat percentiles (usec):
 | 1.00th=[ 181], 5.00th=[ 185], 10.00th=[ 189], 20.00th=[ 201],
 | 30.00th=[ 209], 40.00th=[ 211], 50.00th=[ 213], 60.00th=[ 217],
 | 70.00th=[ 221], 80.00th=[ 231], 90.00th=[ 247], 95.00th=[ 262],
 | 99.00th=[ 298], 99.50th=[ 362], 99.90th=[ 1160], 99.95th=[ 2064],
 | 99.99th=[ 7136]
 lat (usec) : 250=91.39%, 500=8.33%, 750=0.11%, 1000=0.04%
 lat (msec) : 2=0.07%, 4=0.02%, 10=0.03%, 20=0.01%, 50=0.01%
 lat (msec) : 250=0.01%, 500=0.01%
 cpu : usr=1.63%, sys=30.37%, ctx=1049367, majf=0, minf=8
 IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
 submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
 complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
 issued rwt: total=1048576,0,0, short=0,0,0, dropped=0,0,0
 latency : target=0, window=0, percentile=100.00%, depth=1
Run status group 0 (all jobs):
 READ: bw=17.5MiB/s (18.3MB/s), 17.5MiB/s-17.5MiB/s (18.3MB/s-18.3MB/s), io=4096MiB (4295MB), run=235079-235079msec
Disk stats (read/write):
 dm-1: ios=1052300/5593, merge=0/0, ticks=223175/61682, in_queue=285049, util=93.76%, aggrios=1052598/5708, aggrmerge=0/0, aggrticks=221445/61682, aggrin_queue=283274, aggrutil=92.99%
 dm-0: ios=1052598/5708, merge=0/0, ticks=221445/61682, in_queue=283274, util=92.99%, aggrios=1052562/2206, aggrmerge=36/3534, aggrticks=190612/44612, aggrin_queue=234676, aggrutil=79.82%
 sdb: ios=1052562/2206, merge=36/3534, ticks=190612/44612, in_queue=234676, util=79.82%

Lecture séquentielle: 244MB/s 60K IOPS
Lecture aléatoire: 18MB/s 4K IOPS

En fait la vraie question est comment un FS donné fragmente dans une utilisation courante / donnée ?

Sur un FS classique tel que ext4, la fragmentation est, grosso modo, liée à l'augmentation de taille des fichiers. Si le bloc suivant n'est pas libre quand tu veux faire grossir un fichier, il faut en trouver un autre autre part. Sauf cas pathologique ça fragmente assez rarement, et on peut sûrement arriver à ton raccourci (ie. l'impact est suffisamment faible pour qu'on le néglige).

Sur un FS basé sur du COW je serais beaucoup moins sur. Je ne connais rien à btrfs, mais je peux imaginer de nombreux cas d'écriture ou le COW mène à une très forte fragmentation. On retombe sur des lectures purement aléatoires... 10x plus lentes. Et c'est peut être aussi pour ça que btrsfs à un outil de defrag et une defrag online !

https://btrfs.wiki.kernel.org/index.php/Gotchas#Fragmentation

Tu me fais un test comparatif de perf ssd + btrfs avec et sans fragmentation ?

à part pour réduire artificiellement sa durée de vie.

Tu me fais un calcul au dos de l'enveloppe ou une étude réelle ? Les SSD ne sont pas en sucre.