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

Скорость записи ZFS

 


1

3

Недавно в руки попало 64 относительно старых дисков на 2Тб. Решил поиграться с ZFS на десктопе, собрал пул из 4х дисков (RAIDZ1). Собираюсь сделать на этом файлопомойку.

Был не очень приятно удивлен скоростью записи, результаты прикладываю.

Скорость записи на ZFS:

[root@crow data]# rsync -ah --progress /mnt/metis_torrents/The\ Last\ Of\ Us.2022.S01.WEB-DL.1080p ./
sending incremental file list
The Last Of Us.2022.S01.WEB-DL.1080p/
The Last Of Us.2022.S01.WEB-DL.1080p/The Last Of Us.2022.S01E01.WEB-DL.1080p.x265.AMZN.mkv
          2.43G 100%   43.31MB/s    0:00:53 (xfr#1, to-chk=8/10)
The Last Of Us.2022.S01.WEB-DL.1080p/The Last Of Us.2022.S01E02.WEB-DL.1080p.x265.AMZN.mkv
          1.83G 100%   36.72MB/s    0:00:47 (xfr#2, to-chk=7/10)
The Last Of Us.2022.S01.WEB-DL.1080p/The Last Of Us.2022.S01E03.WEB-DL.1080p.x265.AMZN.mkv
          2.78G 100%   38.37MB/s    0:01:09 (xfr#3, to-chk=6/10)
The Last Of Us.2022.S01.WEB-DL.1080p/The Last Of Us.2022.S01E04.WEB-DL.1080p.x265.AMZN.mkv
          1.26G 100%   35.69MB/s    0:00:33 (xfr#4, to-chk=5/10)
The Last Of Us.2022.S01.WEB-DL.1080p/The Last Of Us.2022.S01E05.WEB-DL.1080p.x265.AMZN.mkv
          1.59G 100%   50.92MB/s    0:00:29 (xfr#5, to-chk=4/10)
The Last Of Us.2022.S01.WEB-DL.1080p/The Last Of Us.2022.S01E06.WEB-DL.1080p.x265.AMZN.mkv
          2.20G 100%   44.97MB/s    0:00:46 (xfr#6, to-chk=3/10)
The Last Of Us.2022.S01.WEB-DL.1080p/The Last Of Us.2022.S01E07.WEB-DL.1080p.x265.AMZN.mkv
          1.52G 100%   43.80MB/s    0:00:33 (xfr#7, to-chk=2/10)
The Last Of Us.2022.S01.WEB-DL.1080p/The Last Of Us.2022.S01E08.WEB-DL.1080p.x265.AMZN.mkv
          1.51G 100%   42.37MB/s    0:00:33 (xfr#8, to-chk=1/10)
The Last Of Us.2022.S01.WEB-DL.1080p/The Last Of Us.2022.S01E09.WEB-DL.1080p.x265.AMZN.mkv
          1.43G 100%   42.71MB/s    0:00:32 (xfr#9, to-chk=0/10)

Скорость записи просто на один из дисков (ext4):

[root@crow data]# rsync -ah --progress /mnt/metis_torrents/The\ Last\ Of\ Us.2022.S01.WEB-DL.1080p /mnt/libvirt_tmp/
sending incremental file list
The Last Of Us.2022.S01.WEB-DL.1080p/
The Last Of Us.2022.S01.WEB-DL.1080p/The Last Of Us.2022.S01E01.WEB-DL.1080p.x265.AMZN.mkv
          2.43G 100%  643.08MB/s    0:00:03 (xfr#1, to-chk=8/10)
The Last Of Us.2022.S01.WEB-DL.1080p/The Last Of Us.2022.S01E02.WEB-DL.1080p.x265.AMZN.mkv
          1.83G 100%  520.19MB/s    0:00:03 (xfr#2, to-chk=7/10)
The Last Of Us.2022.S01.WEB-DL.1080p/The Last Of Us.2022.S01E03.WEB-DL.1080p.x265.AMZN.mkv
          2.78G 100%  568.73MB/s    0:00:04 (xfr#3, to-chk=6/10)
The Last Of Us.2022.S01.WEB-DL.1080p/The Last Of Us.2022.S01E04.WEB-DL.1080p.x265.AMZN.mkv
          1.26G 100%  205.02MB/s    0:00:05 (xfr#4, to-chk=5/10)
The Last Of Us.2022.S01.WEB-DL.1080p/The Last Of Us.2022.S01E05.WEB-DL.1080p.x265.AMZN.mkv
          1.59G 100%  145.96MB/s    0:00:10 (xfr#5, to-chk=4/10)
The Last Of Us.2022.S01.WEB-DL.1080p/The Last Of Us.2022.S01E06.WEB-DL.1080p.x265.AMZN.mkv
          2.20G 100%  110.91MB/s    0:00:18 (xfr#6, to-chk=3/10)
The Last Of Us.2022.S01.WEB-DL.1080p/The Last Of Us.2022.S01E07.WEB-DL.1080p.x265.AMZN.mkv
          1.52G 100%  105.93MB/s    0:00:13 (xfr#7, to-chk=2/10)
The Last Of Us.2022.S01.WEB-DL.1080p/The Last Of Us.2022.S01E08.WEB-DL.1080p.x265.AMZN.mkv
          1.51G 100%  107.04MB/s    0:00:13 (xfr#8, to-chk=1/10)
The Last Of Us.2022.S01.WEB-DL.1080p/The Last Of Us.2022.S01E09.WEB-DL.1080p.x265.AMZN.mkv
          1.43G 100%  110.03MB/s    0:00:12 (xfr#9, to-chk=0/10)

Подскажите, пожалуйста, оно так и должно работать или можно получше настроить?

Данные о машине:

  • CPU: AMD Ryzen 7 2700X Eight-Core Processor
  • RAM: 64Gb

Пул создавался с опцией ashift=12, настройки по умолчанию не менял, только отключил atime.

★

 ← 1 2 3 4 5 →

Оно энтерпрайзное и вообще из светлого будущего спущено на нас. У них уже квантовые, там пофиг.

Мне интереснее, зачем копировать файлы из под рута?

И файлы интересные… спрошу-ка у знакомого тов. Маёра, может он подскажет.

mrjaggers
()
Ответ на: комментарий от alex07

ZFS это жирное тормозное bloatware, поэтому такая скорость может быть нормой. Но подождём фанатов этой «распрекрасной» ФС, они любят бегать вокруг неё и крутить ручки в надежде превратить её во что-то юзабельное, может и в этот раз что-нибудь посоветуют)

alex1101 ☆
()
Ответ на: комментарий от alex07

Да, выкинь эти неизвестно какие диски и эту ZFS.

Ну можно конечно ждать тут советов умных, но для этого надо самому хоть что-то сделать. А не спераченное попкинцо пару раз скопировать.

mrjaggers
()
Ответ на: комментарий от alex1101

почему не собрать банальный RAID1?

RAID1 это два диска в зеркале. А мне надо много места, с хоть какими-то гарантиями не угробить массив при вылете одного диска.

Upd: к слову сказать RAID1 у меня стоит и работает, но для по-настоящему важных данных.

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

RAID1 это два диска в зеркале

Да.

А мне надо много места

Так у тебя будет 64 ТБ в RAID1. В RAID5, который ты хотел, тебе будет доступно ~115 ТБ, но при этом массив сможет пережить вылет только одного диска из 64. Что-то мне подсказывает, что это очень низкий уровень надёжности. А с RAID1 массив переживёт вылет половины дисков.

alex1101 ☆
()
Ответ на: комментарий от alex1101

Так у тебя будет 64 ТБ в RAID1.

Я же не говорю, что я все 64 диска поставил. В системник только 8 помещается, остальные на полке лежат. В любом случае, полагаю, речь идет о RAID10, а не о RAID1.

alex07 ★
() автор топика

руки попало 64 относительно старых дисков

В зеркале и стрипе рейде скорость всегда будет приблизительно равна самому медленному носителю. Т.е если я сделал рейд на бтрфс с 2 hdd и одной флешкой все будет медленно донельзя. А потом zfs разве уже не фузе? Щас клоуны опять будут лепить клоунов )

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

приблизительно равна самому медленному носителю

Вот это и удивляет, учитывая что речь про 7200rpm enterprise диски. Причем скорость копирования на точно такой же диск, но вне массива, в два раза выше.

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

в том случае если все диски в рейде не имеют битых секторов или еще что замедляет работу. И потом фузе это плохо

Я заметил, что скорость в рейде выше или равна обычной только если это чистый стрип.

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

в том случае если все диски в рейде не имеют битых секторов или еще что замедляет работу.

Перед подключением дисков я каждому сделал проверку с помощью badblocks (стандартная запись-чтение 4 паттерна на весь объем), а затем еще прогнал smartctl -t long. Битых секторов обнаружено не было, SMART выдает хорошие результаты.

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

Никогда не пользовался этим бенчмарком, но вот результат на ZFS:

[root@crow data]# fio --filename=./test.img --size=1GB --direct=1 --rw=randrw --bs=4k --ioengine=libaio --iodepth=256 --runtime=60 --numjobs=5 --time_based --group_reporting --name=iops-test-job
iops-test-job: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=256
...
fio-3.36
Starting 5 processes
iops-test-job: Laying out IO file (1 file / 1024MiB)
Jobs: 5 (f=0): [f(5)][100.0%][r=699MiB/s,w=697MiB/s][r=179k,w=178k IOPS][eta 00m:00s]
iops-test-job: (groupid=0, jobs=5): err= 0: pid=246948: Thu Oct 26 10:39:22 2023
  read: IOPS=166k, BW=648MiB/s (679MB/s)(37.9GiB/60001msec)
    slat (usec): min=3, max=90454, avg= 6.74, stdev=70.07
    clat (usec): min=137, max=140977, avg=3846.97, stdev=4922.13
     lat (usec): min=145, max=141023, avg=3853.71, stdev=4924.26
    clat percentiles (usec):
     |  1.00th=[ 2024],  5.00th=[ 2147], 10.00th=[ 2212], 20.00th=[ 2245],
     | 30.00th=[ 2311], 40.00th=[ 2343], 50.00th=[ 2442], 60.00th=[ 2540],
     | 70.00th=[ 2671], 80.00th=[ 2868], 90.00th=[ 3916], 95.00th=[17957],
     | 99.00th=[25035], 99.50th=[27657], 99.90th=[34866], 99.95th=[40633],
     | 99.99th=[81265]
   bw (  KiB/s): min=81888, max=1116288, per=100.00%, avg=666473.94, stdev=80699.26, samples=595
   iops        : min=20472, max=279072, avg=166618.40, stdev=20174.84, samples=595
  write: IOPS=166k, BW=647MiB/s (679MB/s)(37.9GiB/60001msec); 0 zone resets
    slat (usec): min=7, max=97399, avg=20.93, stdev=100.77
    clat (usec): min=4, max=140938, avg=3846.19, stdev=4927.67
     lat (usec): min=134, max=141000, avg=3867.12, stdev=4961.36
    clat percentiles (usec):
     |  1.00th=[ 2024],  5.00th=[ 2147], 10.00th=[ 2212], 20.00th=[ 2245],
     | 30.00th=[ 2311], 40.00th=[ 2343], 50.00th=[ 2442], 60.00th=[ 2540],
     | 70.00th=[ 2671], 80.00th=[ 2868], 90.00th=[ 3916], 95.00th=[17957],
     | 99.00th=[25035], 99.50th=[27657], 99.90th=[35390], 99.95th=[40633],
     | 99.99th=[86508]
   bw (  KiB/s): min=82512, max=1114760, per=100.00%, avg=666197.21, stdev=80751.78, samples=595
   iops        : min=20628, max=278690, avg=166549.23, stdev=20187.96, samples=595
  lat (usec)   : 10=0.01%, 250=0.01%, 500=0.01%, 750=0.01%, 1000=0.01%
  lat (msec)   : 2=0.73%, 4=89.43%, 10=2.69%, 20=3.78%, 50=3.34%
  lat (msec)   : 100=0.02%, 250=0.01%
  cpu          : usr=7.37%, sys=61.66%, ctx=630782, majf=0, minf=85
  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.0%, >=64=0.1%
     issued rwts: total=9947430,9942958,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=256

Run status group 0 (all jobs):
   READ: bw=648MiB/s (679MB/s), 648MiB/s-648MiB/s (679MB/s-679MB/s), io=37.9GiB (40.7GB), run=60001-60001msec
  WRITE: bw=647MiB/s (679MB/s), 647MiB/s-647MiB/s (679MB/s-679MB/s), io=37.9GiB (40.7GB), run=60001-60001msec

А вот результат на обычном ext4:

[root@crow libvirt_tmp]# fio --filename=./test.img --size=1GB --direct=1 --rw=randrw --bs=4k --ioengine=libaio --iodepth=256 --runtime=60 --numjobs=5 --time_based --group_reporting --name=iops-test-job
iops-test-job: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=256
...
fio-3.36
Starting 5 processes
iops-test-job: Laying out IO file (1 file / 1024MiB)
Jobs: 5 (f=5): [m(5)][100.0%][r=492KiB/s,w=588KiB/s][r=123,w=147 IOPS][eta 00m:00s]
iops-test-job: (groupid=0, jobs=5): err= 0: pid=248365: Thu Oct 26 10:42:45 2023
  read: IOPS=135, BW=542KiB/s (555kB/s)(31.9MiB/60214msec)
    slat (usec): min=3, max=251228, avg=11952.66, stdev=20681.34
    clat (msec): min=205, max=5796, avg=4446.51, stdev=749.17
     lat (msec): min=216, max=5797, avg=4458.46, stdev=749.56
    clat percentiles (msec):
     |  1.00th=[  709],  5.00th=[ 3138], 10.00th=[ 4044], 20.00th=[ 4245],
     | 30.00th=[ 4396], 40.00th=[ 4463], 50.00th=[ 4597], 60.00th=[ 4665],
     | 70.00th=[ 4732], 80.00th=[ 4866], 90.00th=[ 5000], 95.00th=[ 5134],
     | 99.00th=[ 5403], 99.50th=[ 5470], 99.90th=[ 5604], 99.95th=[ 5671],
     | 99.99th=[ 5805]
   bw (  KiB/s): min=  184, max=  984, per=99.48%, avg=539.16, stdev=29.69, samples=559
   iops        : min=   46, max=  246, avg=134.79, stdev= 7.42, samples=559
  write: IOPS=140, BW=562KiB/s (575kB/s)(33.0MiB/60214msec); 0 zone resets
    slat (usec): min=4, max=247541, avg=23966.49, stdev=28837.89
    clat (msec): min=110, max=6005, avg=4485.99, stdev=772.88
     lat (msec): min=155, max=6052, avg=4509.95, stdev=773.13
    clat percentiles (msec):
     |  1.00th=[  684],  5.00th=[ 3138], 10.00th=[ 4044], 20.00th=[ 4279],
     | 30.00th=[ 4396], 40.00th=[ 4530], 50.00th=[ 4597], 60.00th=[ 4732],
     | 70.00th=[ 4799], 80.00th=[ 4933], 90.00th=[ 5067], 95.00th=[ 5201],
     | 99.00th=[ 5470], 99.50th=[ 5604], 99.90th=[ 5873], 99.95th=[ 5873],
     | 99.99th=[ 6007]
   bw (  KiB/s): min=  184, max= 1120, per=99.00%, avg=556.79, stdev=33.07, samples=560
   iops        : min=   46, max=  280, avg=139.20, stdev= 8.27, samples=560
  lat (msec)   : 250=0.13%, 500=0.45%, 750=0.55%, 1000=0.30%, 2000=1.66%
  lat (msec)   : >=2000=96.91%
  cpu          : usr=0.03%, sys=0.16%, ctx=13574, majf=0, minf=64
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.2%, 16=0.5%, 32=1.0%, >=64=98.1%
     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.1%
     issued rwts: total=8156,8454,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=256

Run status group 0 (all jobs):
   READ: bw=542KiB/s (555kB/s), 542KiB/s-542KiB/s (555kB/s-555kB/s), io=31.9MiB (33.4MB), run=60214-60214msec
  WRITE: bw=562KiB/s (575kB/s), 562KiB/s-562KiB/s (575kB/s-575kB/s), io=33.0MiB (34.6MB), run=60214-60214msec

Disk stats (read/write):
  sdb: ios=8144/8464, sectors=65152/67864, merge=0/19, ticks=1612936/2015426, in_queue=3632602, util=99.89%

Какие-то аномальные результаты….

alex07 ★
() автор топика
Последнее исправление: alex07 (всего исправлений: 2)

В этом тестировании не хватает теста записи на просто ZFS на просто одном диске. Сделай и поставь рядом. Если я правильно помню, у ZFS есть чексуммы для записанных данных. Какой алгоритм работы у ZFS, вообще и с чексуммами, в частности? Оно делает проверочную вычитку после записи?

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

Ну вот, тут уже сопоставимые результаты, а учитывая что у тебя zfs с raidz1 собран, то понятна разница в пользу него.

А твои чудеса со скоростью копирования, вполне типична для файловых систем которые все в память пихают, а уже потом неспешно на диск скидывают.

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

Ну вот, тут уже сопоставимые результаты, а учитывая что у тебя zfs с raidz1 собран, то понятна разница в пользу него.

Какие же оно сопоставимые? Там разница в 1000 раз плюс-минус. Если я правильно всё понимаю.

Я вот про это.

ZFS:

   READ: bw=648MiB/s (679MB/s), 648MiB/s-648MiB/s (679MB/s-679MB/s), io=37.9GiB (40.7GB), run=60001-60001msec
  WRITE: bw=647MiB/s (679MB/s), 647MiB/s-647MiB/s (679MB/s-679MB/s), io=37.9GiB (40.7GB), run=60001-60001msec

Ext4 (1 диск):

   READ: bw=542KiB/s (555kB/s), 542KiB/s-542KiB/s (555kB/s-555kB/s), io=31.9MiB (33.4MB), run=60214-60214msec
  WRITE: bw=562KiB/s (575kB/s), 562KiB/s-562KiB/s (575kB/s-575kB/s), io=33.0MiB (34.6MB), run=60214-60214msec
alex07 ★
() автор топика
Последнее исправление: alex07 (всего исправлений: 3)
Ответ на: комментарий от alex1101

А с RAID1 массив переживёт вылет половины дисков.

Это если очень повезёт. А если не повезёт - не переживёт и вылет двух. Поэтому нафиг все эти raid0 (включая 1+0), надо смонтировать 32 директории по 2тб и вручную по ним раскидывать. Сдохнут неудачные 2 диска - потеряешь не больше 2тб данных.

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

Хм, ну вот это уже больше похоже на правду:

pool                                           alloc   free   read  write   read  write
---------------------------------------------  -----  -----  -----  -----  -----  -----
data                                           25.3G  7.24T      0  2.75K      0   461M
  raidz1-0                                     25.3G  7.24T      0  2.74K      0   461M
    ata-WDC_WD20EZRX-00D8PB0_WD-WMC4M0395121       -      -      0    588      0   119M
    ata-HGST_HUS724020ALA640_PN2166P2H7RG8J        -      -      0    559      0   114M
    ata-WDC_WD2003FYYS-18W0B0_WD-WMAY02509617      -      -      0    725      0   112M
    ata-WDC_WD2003FYYS-18W0B0_WD-WMAY02509937      -      -      0    937      0   116M
---------------------------------------------  -----  -----  -----  -----  -----  -----

Я правильно понимаю что пишет на все диски со скоростью прим. 100М? И общая скорость записи 461М?

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

Это скорее не общая скорость в смысле скорости записи файлов, а сумма количества записанных данных за секунду. Если бы это было чисто зеркало, то всё равно было бы 461М, но файлы в пул само собой записывались бы со скоростью около 100, по копии в каждый диск.

unC0Rr ★★★★★
()

Олимпиада по натягиванию совы btrfs zfs на глобус линукс продолжается. Жертвы среди мышек пользователей исчисляются тысячами, но они продолжали жрать кактус использовать сырые промышленные файловые системы на потеху ретроградам с mdraid/lvm/ext4 наперевес.

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

mdraid/lvm/ext4 наперевес.

А зачем весь этот зоопарк разных инструментов когда ZFS всё в одном пакете предлагает? Плюс у них, вроде как, аналог RAID5 более надежный чем у mdadm.

К слову сказать, mdraid/lvm/ext4, это именно то что я использую на действительно важных данных.

сырые промышленные файловые системы

И это, пишут что ZFS вполне себе production-ready. Обманывают, как обычно?

alex07 ★
() автор топика
Последнее исправление: alex07 (всего исправлений: 3)
Ответ на: комментарий от Aster

Зачем вообще использовать это bloatware (zfs)?

А в чем выражается bloatware?

И зачем нужен рейд в файлопомойке?

В том что бэкапы делать смысла нет, все в торрентах есть. Но при потере одного диска не хочется терять всю помойку.

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

насколько я понимаю pool это не стрип, а скорее raid1 по аналогии с бтрфс пулом. Сейчас ради интереса состряпал пул btrfs из 3 ssd и вместо увеличения скорости я имею наоборот уменьшение. Что в принципе и следует ожидать от зеркала. Мерил с dd перед этим убрал кэш

sudo sh -c «/usr/bin/echo 3 > /proc/sys/vm/drop_caches»

получилось с одним 203mb/sec, 2 показали ~181, а с тремя уже 175 и ниже. Я не знаю насколько zfs крута, но пул с кучей девайсов не будет слишком производительным. По крайней мере не линейный рост скорости )). Имхо конечно

Но я бы глянул на эксперимент тс с raid0

monkdt
()

Чо за диски? ZFS не очень хорошо работает с SMR, потому что у них рандомная запись страдает.

На вертушках, как минимум имеет смысл включить сжатие на уровне ФС.

P.S. то что у тебя выше fio выдал говно вместо результатов – это как раз из-за рандомных чтения/записи вместо последовательных (ext4 тут сосёт по некоторым причинам). Попробуй те же параметры, только с –rw=write.

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

Чо за диски?

HGST HUS724020ALA640
WDC WD20EZRX-00D8PB0
WDC WD2003FYYS-18W0B0

Ну вот такие, например. Если верить сайту https://nascompares.com/answer/list-of-wd-cmr-and-smr-hard-drives-hdd/ то они все CMR.

SMR это черепичная запись, верно?

сжатие на уровне ФС

Это типа lz4 компрессия на ZFS? По умолчанию, включено. Проверял.

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

SMR это черепичная запись, верно?

Да.

К слову, тебе нужно вырубить ARC перед бенчмарком. Сделай echo 10485760 > /sys/module/zfs/parameters/zfs_arc_max, это выставит его размер в 10 мегабайт. Потом сделай fio.

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 2)
Ответ на: комментарий от alex07

А зачем весь этот зоопарк разных инструментов когда ZFS всё в одном пакете предлагает?

Чтобы не создавать подобные треды.

Плюс у них, вроде как, аналог RAID5 более надежный чем у mdadm

Любые софтовые рейды за пределами RAID1/RAID10 - извращенный способ самоубийства. Если тебе нужен RAID 5/6, который не рассыплется от первой же проблемы, тебе нужен аппаратный контроллер с кэшем, батарейкой и поддержкой spare drives.

И это, пишут что ZFS вполне себе production-ready. Обманывают, как обычно?

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

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

Если тебе нужен RAID 5/6, который не рассыплется от первой же проблемы, тебе нужен аппаратный контроллер с кэшем, батарейкой и поддержкой spare drives.

АХАХАХАХАХАХАХАХАХАХАХАХАХАХАХАХАХАХАХАХАХАХАХАХАХ

Господи, кто-то ещё на хардварные рейды в этом мире наяривает.

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

Господи, кто-то ещё на хардварные рейды в этом мире наяривает.

Представляешь, когда у тебя 10к серверов, тебе просто некогда трахаться с тюнингом модных и молодежных файловых систем, да и менеджмент за такое может яйки дверью прищемить и сказать, что так и было.

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

Господи, кто-то ещё на хардварные рейды в этом мире наяривает.

Представляешь, когда у тебя 10к серверов, тебе просто некогда трахаться с тюнингом модных и молодежных файловых систем, да и менеджмент за такое может яйки дверью прищемить и сказать, что так и было.

Представил. Если они одинаковые, то настройка делается один раз и всё. Internet Archive знаешь? Вот у них ZFS с петабайтами данных. Всё норм, всё работает.

С другой стороны, хардварные рейды – это не магия, а просто говнина на отдельной плате. Если ты думаешь, что эту говнину какие-то специальные эльфы из космоса делают, то у меня для тебя плохие новости.

P.S. ZFS вышла 15 лет назад. Она не новая, если тебе меньше 50.

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

Представил. Если они одинаковые, то настройка делается один раз и всё.

Нет, не одинаковые. Железо стареет, его перестают выпускать, вместо него выпускают другое, которое затем идет по тому же пути. Происходит это быстрее, чем это железо успевает морально и физически устаревать.

Кроме того, типов нагрузки существует охулиард, на одних только ProLiant Gen10 только предустановленных ворклоад профайлов почти два десятка, а дериваций можно навертеть на порядок больше.

Каждой нагрузке нужен свой профайл, если ты не хочешь платить за электричество двойной счёт (напоминаю, серверов больше 10к).

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

Но ты продолжай держать нас в курсе, о том как это все не нужно и можно заменить однократной настройкой ZFS.

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

Но ты продолжай держать нас в курсе, о том как это все не нужно и можно заменить однократной настройкой ZFS.

Так в этом случае и хардварный рейд не поможет. Ты тут какие-то мутные абстрактные примеры из своей жопы вытаскиваешь, хотя мы все видим, что ZFS давно много кем используется. Начиная от всяких ютуберов типа Linus Tech Tips, у которого весь сторадж с 8k видео на нём, и заканчивая агентством атомной энергетики США, которые разработку OpenZFS спонсируют уже годы.

P.S. ей богу, не вижу смысла размазывать сторадж по 10к серверов. Тупой сценарий какой-то.

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
 ← 1 2 3 4 5 →
General