LINUX.ORG.RU
Форум — Admin  

Дефрагментация slog mirror(ZFS)

 , ,


1

2

Сабж. Есть два лог раздела на двух ssd, нужно ли беспокоится о фрагментации zil на этих разделах? Как ее избежать или выполнить дефрагментацию? Хост используется для KVM. Документацию читал, но ответа не нашел.

Ответ на: комментарий от Deleted

Это не очевидно? Какой в ней смысл? Фрагментация мешает винтам, которые от случайного доступа старадают. А для SSD выдать что последующий блок, что из конца диска - одинаковая задача. Хуже того, дефрагментация снизит ресурс записи SSD.

blind_oracle ★★★★★
()
Ответ на: комментарий от Deleted

Это почему?

Потому что прежде, чем спрашивать, надо понять
1. Что такое фрагментация
2. Почему это плохо
3. Что такое дефрагментация

Как только ты правильно ответишь на эти три вопроса, так сразу вопрос заданный в топике потеряет смысл.

zgen ★★★★★
()
Ответ на: комментарий от blind_oracle

А для SSD выдать что последующий блок, что из конца диска - одинаковая задача

Покажете мне SSD, у которого скорость случайного чтения равна скорости последовательного?

дефрагментация снизит ресурс записи SSD

Насколько?

Deleted
()
Ответ на: комментарий от zgen

А можно просто посмотреть на ТТХ любого SSD.

Макс. устойчивая скорость последовательного чтения 	550 Мбайт/с 	550 Мбайт/с 	550 Мбайт/с 	550 Мбайт/с
Макс. устойчивая скорость последовательной записи 	470 Мбайт/с 	520 Мбайт/с 	520 Мбайт/с 	520 Мбайт/с
Макс. скорость произвольного чтения (блоки по 4 Кбайт) 	100000 IOPS 	100000 IOPS 	100000 IOPS 	100000 IOPS
Макс. скорость произвольной записи (блоки по 4 Кбайт) 	90000 IOPS 	90000 IOPS 	90000 IOPS 	90000 IOPS
Deleted
()
Ответ на: комментарий от Deleted

100 тысяч IOPS * 4096 байт = 409.6 мбайт/сек, внезапно. Не 550, конечно, но почти. Причём этих 550 там, скорее всего, на практике нет, как раз 400-450 будет. Судя по моим тестам скорость при рандомной работе с SSD уже при 8к блоках не отличается от последовательной.

blind_oracle ★★★★★
()
Ответ на: комментарий от Deleted

Насколько?

На сколько-то. Зависит от множества факторов, как ты понимаешь. Чем больше записей будет при дефрагментации, тем больше износ.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

Какой в ней смысл? Фрагментация мешает винтам

SSD имеют блочную структуру и фрагментация при гранулярности меньше размера блока (обычно 128кбайт) снижает скорость на записи при исчерпании места и при отсутствии TRIM.

TRIM, кстати, тоже ресурс расходует, поскольку делает для каждого вычищаемого частично заполненного блока цикл чтение/стирание пустого/запись.

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

записи при исчерпании места и при отсутствии TRIM.

Это что-то из разряда стрелять себе в ногу. Либо берут энетрпрайзные ссд с большим запасом места сверх заявленного, либо юзают TRIM.

Теоретически всё так, но на практике *любая* запись на SSD меньше блока идёт через считать\изменить\записать блок. ФС же работает блоками сильно меньше блока SSD (обычно 4к, в сабжевом ZFS конечно побольше, 128k - 1M), поэтому как эти блоки будут ложиться на NAND решает уже контроллер, а это чёрный ящик.

Посему при прочих равных дефрагментация для SSD *вредна*. И даже богомерзкий :) оффтопик при установке на SSD её вырубает сам. Ты раньше убьёшь диск чрезмерной записью чем увидишь профит от дефрагментированности.

TRIM, кстати, тоже ресурс расходует, поскольку делает для каждого вычищаемого частично заполненного блока цикл чтение/стирание пустого/запись.

TRIM, строго говоря, просто говорит контроллеру какие блоки можно recycle-ить и всё. Как ими там потом контроллер распоряжается - тоже тёмный лес.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

на практике *любая* запись на SSD меньше блока идёт через считать\изменить\записать блок.

Не любая. Только запись в блоки с нестёртой информацией. Если в блоке пустые ячейки очищены и происходит запись в них — то цикл состоит только из операции записи.

KRoN73 ★★★★★
()
Ответ на: комментарий от blind_oracle

Всё равно при чтении или записи разбросанных блоков есть ненулевые потери. Возможно, они незаметны в повседневном использовании, но говорить, что дефрагментация на SSD не нужна - неправильно.

Deleted
()
Ответ на: комментарий от KRoN73

Да, само собой, я имел в виду запись в блок где что-то уже есть.

blind_oracle ★★★★★
()
Ответ на: комментарий от Deleted

И будет оптимизация ради оптимизации.

Radjah ★★★★★
()
Ответ на: комментарий от Deleted

«Все равно» это такой непробиваемый аргумент? Да нет никакой разницы. Вообще.

Вот тест энтерпрайзного Intel DC S3700 на 200 гиг, проведен только что.

Рандомное чтение 32Гб блоками по 4к: 

test: (g=0): rw=randread, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=64
fio-2.1.11
Starting 1 process
Jobs: 1 (f=1): [r(1)] [100.0% done] [294.8MB/0KB/0KB /s] [75.5K/0/0 iops] [eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=7815: Tue Feb  2 10:37:33 2016
  read : io=32768MB, bw=301239KB/s, iops=75309, runt=111388msec
    slat (usec): min=2, max=11997, avg= 6.27, stdev= 6.45
    clat (usec): min=312, max=12846, avg=841.96, stdev=83.62
     lat (usec): min=318, max=12851, avg=848.40, stdev=83.66
    clat percentiles (usec):
     |  1.00th=[  716],  5.00th=[  772], 10.00th=[  788], 20.00th=[  804],
     | 30.00th=[  820], 40.00th=[  828], 50.00th=[  836], 60.00th=[  844],
     | 70.00th=[  852], 80.00th=[  876], 90.00th=[  900], 95.00th=[  932],
     | 99.00th=[ 1032], 99.50th=[ 1112], 99.90th=[ 1912], 99.95th=[ 2224],
     | 99.99th=[ 2672]
    bw (KB  /s): min=285800, max=303680, per=100.00%, avg=301254.85, stdev=3409.70
    lat (usec) : 500=0.01%, 750=2.58%, 1000=96.00%
    lat (msec) : 2=1.32%, 4=0.08%, 10=0.01%, 20=0.01%
  cpu          : usr=19.30%, sys=48.95%, ctx=1892054, majf=0, minf=1423
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.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.1%, >=64=0.0%
     issued    : total=r=8388608/w=0/d=0, short=r=0/w=0/d=0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
   READ: io=32768MB, aggrb=301239KB/s, minb=301239KB/s, maxb=301239KB/s, mint=111388msec, maxt=111388msec

Последовательное чтение 32Гб блоками по 4к: 

test: (g=0): rw=read, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=64
fio-2.1.11
Starting 1 process
Jobs: 1 (f=1): [R(1)] [100.0% done] [297.9MB/0KB/0KB /s] [76.3K/0/0 iops] [eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=29637: Tue Feb  2 10:40:33 2016
  read : io=32768MB, bw=302991KB/s, iops=75747, runt=110744msec
    slat (usec): min=2, max=11744, avg= 6.39, stdev= 8.10
    clat (usec): min=299, max=27263, avg=837.20, stdev=126.06
     lat (usec): min=305, max=27271, avg=843.78, stdev=126.15
    clat percentiles (usec):
     |  1.00th=[  700],  5.00th=[  764], 10.00th=[  780], 20.00th=[  796],
     | 30.00th=[  812], 40.00th=[  820], 50.00th=[  828], 60.00th=[  836],
     | 70.00th=[  852], 80.00th=[  868], 90.00th=[  900], 95.00th=[  932],
     | 99.00th=[ 1032], 99.50th=[ 1096], 99.90th=[ 1912], 99.95th=[ 2256],
     | 99.99th=[ 3056]
    bw (KB  /s): min=284528, max=305352, per=100.00%, avg=302995.55, stdev=3425.14
    lat (usec) : 500=0.01%, 750=3.39%, 1000=95.17%
    lat (msec) : 2=1.34%, 4=0.08%, 10=0.01%, 20=0.01%, 50=0.01%
  cpu          : usr=17.21%, sys=50.63%, ctx=1890250, majf=0, minf=580
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.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.1%, >=64=0.0%
     issued    : total=r=8388608/w=0/d=0, short=r=0/w=0/d=0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
   READ: io=32768MB, aggrb=302990KB/s, minb=302990KB/s, maxb=302990KB/s, mint=110744msec, maxt=110744msec
Никакой разницы, все в пределах погрешности. При записи картина аналогичная, показать не могу т.к. на диске данные. Если увеличить размер блока до 16к, то скорость вырастает до 412Мб/с в обоих случаях. Так что удачи с дефрагментацией :D

blind_oracle ★★★★★
()
Ответ на: комментарий от NetworkRider

А где там у тебя SLOG? Насколько я вижу у тебя просто две раздела SSDшек в зеркале добавлены в пул. Пул с логом выглядит как-то так: 

# zpool status
  pool: zfs_hdd
 state: ONLINE
  scan: scrub repaired 0 in 15h27m with 0 errors on Mon Dec  7 14:38:18 2015
config:

        NAME           STATE     READ WRITE CKSUM
        zfs_hdd        ONLINE       0     0     0
          raidz2-0     ONLINE       0     0     0
            D01_9Y0RA  ONLINE       0     0     0
            D02_B9G2A  ONLINE       0     0     0
            D03_B01GA  ONLINE       0     0     0
            D04_B9GDA  ONLINE       0     0     0
            D05_AU1HA  ONLINE       0     0     0
            D06_BD4HA  ONLINE       0     0     0
            D07_7P85D  ONLINE       0     0     0
            D08_93WJA  ONLINE       0     0     0
            D09_4394K  ONLINE       0     0     0
            D10_BDYKA  ONLINE       0     0     0
        logs
          mirror-1     ONLINE       0     0     0
            SSD1_SLOG  ONLINE       0     0     0
            SSD2_SLOG  ONLINE       0     0     0
            SSD3_SLOG  ONLINE       0     0     0

errors: No known data errors

blind_oracle ★★★★★
()
Ответ на: комментарий от Deleted

Ты считаешь, что контроллер SSD пишет «линейно» на массив памяти? А как тогда выравнивние износа осуществляется?

Почитай на тему

Flash Translation Layer

greenman ★★★★★
()
Последнее исправление: greenman (всего исправлений: 1)
Ответ на: комментарий от blind_oracle

zpool list -v 

NAME   SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
rpool  5.44T   691G  4.76T         -     5%    12%  1.00x  ONLINE  -
  mirror  2.72T   345G  2.38T         -     5%    12%
    sda2      -      -      -         -      -      -
    sdb2      -      -      -         -      -      -
  mirror  2.72T   345G  2.38T         -     5%    12%
    sdc      -      -      -         -      -      -
    sdd      -      -      -         -      -      -
  mirror  9.25G  16.5M  9.23G         -    90%     0%
    ata-INTEL_SSDSC2BA800G4_BTHV5170053Z800OGN-part1      -      -      -         -      -      -
    ata-INTEL_SSDSC2BA800G4_BTHV52640ADK800OGN-part1      -      -      -         -      -      -
cache      -      -      -      -      -      -
  ata-Samsung_SSD_850_PRO_1TB_S252NWAG305766T-part2   651G   337G   314G         -     0%    51%



zpool status

 pool: rpool
 state: ONLINE
  scan: scrub repaired 0 in 0h24m with 0 errors on Mon Feb  1 01:51:39 2016
config:

        NAME                                                  STATE     READ WRITE CKSUM
        rpool                                                 ONLINE       0     0     0
          mirror-0                                            ONLINE       0     0     0
            sda2                                              ONLINE       0     0     0
            sdb2                                              ONLINE       0     0     0
          mirror-1                                            ONLINE       0     0     0
            sdc                                               ONLINE       0     0     0
            sdd                                               ONLINE       0     0     0
        logs
          mirror-2                                            ONLINE       0     0     0
            ata-INTEL_SSDSC2BA800G4_BTHV5170053Z800OGN-part1  ONLINE       0     0     0
            ata-INTEL_SSDSC2BA800G4_BTHV52640ADK800OGN-part1  ONLINE       0     0     0
        cache
          ata-Samsung_SSD_850_PRO_1TB_S252NWAG305766T-part2   ONLINE       0     0     0

errors: No known data errors
NetworkRider
() автор топика
Ответ на: комментарий от NetworkRider

Ммм.. ничего? У меня на обычном (не лог) raidz пуле из трех SSD сейчас фрагментация 73% при том что занята только половина. Проблем не наблюдаю.

blind_oracle ★★★★★
()
Последнее исправление: blind_oracle (всего исправлений: 1)
Ответ на: комментарий от NetworkRider

На slog нет фрагментации и быть не может.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Admin