LINUX.ORG.RU
ФорумTalks

Занялся оптимизацией моей тормозоZFS

 ,


1

3

Хотел бы узнать нормальную скорость работы ФС.

Возьмите пожалуйста файл побольше и скиньте какая скорость получилась

rsync -avh --progress oldfile.mp4 newfile.mp4

P.S. Не SSD пожалуйста

★★★★★

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

Ну так кеш сработает, чо

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

И неясно зачем сокеты при локальном режиме работы rsync

это локальный af_unix, а зачем, это ты у разрабов rsync спроси. запускал так же, вот кусок трейса

23917:  rsync -avh --progress /arhiiv/vendors/2009-2_MK4.iso ./2009-2_MK4.iso
  Current rlimit: 256 file descriptors
   0: S_IFCHR mode:0620 dev:552,0 ino:201874253 uid:395 gid:7 rdev:195,3
      O_RDWR|O_NOCTTY|O_LARGEFILE
      /dev/pts/3
      offset:579870488
   1: S_IFCHR mode:0620 dev:552,0 ino:201874253 uid:395 gid:7 rdev:195,3
      O_RDWR|O_NOCTTY|O_LARGEFILE
      /dev/pts/3
      offset:579870488
   2: S_IFCHR mode:0620 dev:552,0 ino:201874253 uid:395 gid:7 rdev:195,3
      O_RDWR|O_NOCTTY|O_LARGEFILE
      /dev/pts/3
      offset:579870488
   3: S_IFDOOR mode:0444 dev:560,0 ino:45 uid:0 gid:0 size:0
      O_RDONLY|O_LARGEFILE FD_CLOEXEC  door to nscd[748]
      /system/volatile/name_service_door
   4: S_IFSOCK mode:0666 dev:562,0 ino:6094 uid:0 gid:0 size:0
      O_RDWR|O_NONBLOCK
        SOCK_STREAM
        SO_SNDBUF(16384),SO_RCVBUF(5120)
        sockname: AF_UNIX 
        peer: rsync[23917] zone: global[0]
   5: S_IFREG mode:0644 dev:285,65550 ino:8306 uid:40109 gid:1 size:4329517056
      O_RDONLY|O_LARGEFILE
      /arhiiv/vendors/2009-2_MK4.iso
      offset:3708289024
   7: S_IFSOCK mode:0666 dev:562,0 ino:1113 uid:0 gid:0 size:0
      O_RDWR|O_NONBLOCK
        SOCK_STREAM
        SO_SNDBUF(16384),SO_RCVBUF(5120)
        sockname: AF_UNIX 
        peer: rsync[23917] zone: global[0]

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

Задавая больше размер блока ты экономишь на вызовах ядра и на лукапах в кеш. Поверь уж, любой нормальный LRU будет держать блок в памяти после того как его только что использовали. Другое дело - алгоритм журнала и сброса на диск, тут да, может быть существенная разница

А через этот сокет точно вся инфа летит?

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

Достаточно опасно. У меня домашний ноут. Убрал чексумы с системы, оставил для /home. Систему переставлю если что, а вот доки пусть будут.

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

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

Задавая больше размер блока ты экономишь на вызовах ядра и на лукапах в кеш.

спасибо, кэп. и тебя не смущает, что zfs отдаёт по 128к, rsync засирает кэш по 4к, а файловая система всё-равно обратно пишет по 128к?

вот попробуй выстави 'zfs set recordsize=4k твой_пул/твоя_фс' или на весь пул и удивись. благо это можно на лету делать ^^

А через этот сокет точно вся инфа летит?

да.

EvgGad_303 ★★★★★
()
Ответ на: комментарий от om-nom-nimouse

dd с мегабайтным размером блоков выдал скорость 250Мб/с, а на 128кб блоках - 160Мб/с.

попробуй покрути 'zfs set recordsize' - это определяет максимальный размер блока, он в zfs плавающий. за подробностями сюда.
этот параметр можно менять на ходу, но применятся он будет только к новым поступлениям.

EvgGad_303 ★★★★★
()
sent 9.01G bytes  received 31 bytes  13.54M bytes/sec

внутри пула

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

Я моджахед, мне не нужны данные.

То же самое могут говорить про себя пользователи классических ФС, но до тех пор, пока не удостоверятся в обратном, прогнав fsck и mhdd по поверхности диска.

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

То же самое могут говорить про себя пользователи классических ФС

Там хоть и нет аналогичных реализаций, но там и ARC как такового нет.

Недавно тут обзор ходил, что ext4 показала самую высокую стабильность.

// у самого fletcher4

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

Там хоть и нет аналогичных реализаций, но там и ARC как такового нет.

А что это меняет?

ARC в ZFS является кэшем чтения данных. В классических ФС для этого предназначен файловый кэш в памяти.

В классических ФС есть ещё буфер на запись, транзакции из которого упорядочиваются при фиксировании на носителе разве что в UFS2 с включенным Soft-Updates, а в других классических ФС упорядочение записи может гарантировать журналирование, которое в общем случае отвечает только за метаданные ФС, а не данные пользователя (отдельно включать нужно, это небыстрая опция).

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