Мене интересует если внутри ntfs или ext

у zvol скорость записи уже аллоцированного блока и не аллоцированного отличается, но не драматично. Т.е. для перформанса имеет смысл вызывать trim изнутри vm регулярно

Трим не выйдет, там будет забито всё и удаляться самое старое

что за специфик пулс такие?

Как я понимаю английский, имеется в виду некий, каким-то образом указанный пул, а не все подряд. Т.е Это не special pool а specific, т.е. выбранный, указанный

вот тут на 4 шаге в 11 пункте оно?

А что происходит при полном заполнении special ?

Ну тут жестко захордкоженый в юнит, а не специфик. А специфик, как я себе это представляю, это типа такого: systemctl enable zfs-import@bpool и чтобы оно само находило этот пул и сервис создавало. Но я не знаю как там на самом деле устроено, не смотрел.

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

59 +[Unit] 60 +Description=Import ZFS pool %i 61 +Documentation=man:zpool(8) 62 +DefaultDependencies=no 63 +Requires=systemd-udev-settle.service 64 +After=systemd-udev-settle.service 65 +After=cryptsetup.target 66 +After=multipathd.target 67 +Before=zfs-import.target 68 + 69 +[Service] 70 +Type=oneshot 71 +RemainAfterExit=yes 72 +ExecStart=@sbindir@/zpool import -N -d /dev/disk/by-id -o cachefile=none %I 73 + 74 +[Install] 75 +WantedBy=zfs-import.target

Под горячую руку - можно ли "на горячую" без потери данных делать для пула destroy cache, log, spetial?

Ну, пенальти по перфомансу в таком случае не страшно, главное, чтобы данные остались на месте.

но нельзя их отключать нештатно, т.е. если special отвалится целиком (а это болжет быть mirror), то о данных можно забыть, впрочем как и любой другой обычный vdev

Не, я рассматриваю именно сценарий замены физических носителей, используемых под spetial. Т.е. сейчас пара sata SSD, хочу заменить на пару nvme ssd

Со spetial-девайсами та же схема?

пинаем провайдеров со всех сторон. Попробовали другого прова - там вообще 60Мбит )) при заявленном 1Гбит канале ))) Боль и печаль ((

И еще - на обоих концах FreeBSD 12.1

net.ipv4.tcp_congestion_control = bbr чудеса творит (посредством резкого увеличения ретрансмитов). Погугли про BBR

причем тормозит именно аплоад спб->hetzner. Просто если iperfом без VPN тестить все не так печально, как с openvpn

самое смешное, если socat-ом сделать редирект, в московском selectel, то скорость намного лучше, около 200мегабит, но тоже не фонтан, конечно. Кстати, я переносил данные между ДЦ hetzner HEL1-DC2 -> FSN1-DC4 и тоже было не быстро, в районе 200 мегабит, тогда как обычно, скорость за 500-700.

а про сокат можно подробнее?

socat TCP4-LISTEN:8080 TCP4:123.456.789.12:80 тоже самое можно через dnat сделать или ,например nc -l -p 8080| nc 123.456.789.12 80 смысл в том что мы конектимся к селектелу, а хост селектела конектится в hetzner и перебрасывает пакеты в это новое соединение.

именно zfs передавать через socat пробовали?

надо socat попробовать

Вообще, первый раз когда я столкнулся в "затухающими" соединениями, это на частном подключении в гостях на провайдере дом.ру хотел игру на ПК поставить из стима, а она гигов 50. И вот на подключении в 100 мегабит, скорость держится первые 5 минут, а потом 50Мегабит, 20 мегабит, 10 мегабит, 2 мегабита, и 0.5 Мегабит. В результате игра так за 2 часа и не поставилась. Для сравнения, на нормальном провайдере, она же скачивается за 15 минут примерно. Я считаю, что это не ошибка а такая "оптимизация" от админов некоторых провайдеров. Они думают, что никто не заметит. возможно и на магистральных что-то похожее началось?

помониторить tcp windows size у потока. если сильно меньше 1мбайт, то и будет тормозить

дефолтный режим у iperf в режиме клиента это upload. Чтобы в обратном направлении ключ -R

помониторить tcp windows size у потока. если сильно меньше 1мбайт, то и будет тормозить

win 2053