тут нужно найти аля msk-ix присутсвующий в вашем дц ну или сменить дц на адекватный

Могу подтвердить слова Сергея - даже гарантированный аплинк 300Мб/c более чем на порядок дороже, чем абонентский

hetzner-у это не мешает продавать честный гигабит и работае он действительно на гигабит. У них люди другие?

hetzner-у это не мешает продавать честный гигабит и работае он действительно на гигабит. У них люди другие?

hetzner-у это не мешает продавать честный гигабит и работае он действительно на гигабит. У них люди другие?

hetzner-у это не мешает продавать честный гигабит и работае он действительно на гигабит. У них люди другие?

скорее с ними соединяются а не они соединяются

скорее с ними соединяются а не они соединяются

Это имеет значение, если они не Tier 1?

Это имеет значение, если они не Tier 1?

Давайте с трафиком во флуд

Да никто из крупных на аплинках не шейпит, это маразм, шейпинг если и есть, то на клиентских портах именно что б соблюсти купленную скорость

Да никто из крупных на аплинках не шейпит, это маразм, шейпинг если и есть, то на клиентских портах именно что б соблюсти купленную скорость

Да никто из крупных на аплинках не шейпит, это маразм, шейпинг если и есть, то на клиентских портах именно что б соблюсти купленную скорость

шейпят, как лично видевший говорю. На аплинке от TIER2 к TIER1 точно шейпят, не буду называть прова, но он в тройке по РФ. А вот по магистральным - вопрос, там на оборудке не был.

Я не знаю на 100% кто там и что, но проблема есть и даже удалось достучаться до милека, сидят сейчас до меня иперфы гоняют, разбираются

Шепер как именно был настроен? И на каком оборудовпнии? Обычно на бордере не стейтфул фаерволлы стоят и залимитить весь порт могут, а вот per ip или по флоу нет, у них иные задачи

даже интересно стало чем вся эпопея завершится)))

на BRASS по одному из хорайзн, в сторону магистральных линков, по полосе

на BRASS по одному из хорайзн, в сторону магистральных линков, по полосе

Так причем тут тогда операторы меж дц? Брасс это клиентская штуковина и там это норма

а мы разве не про это? Тогда сорри, я контекст потерял

Пока наразбирались, что уронили скорость до 100мбит. В один поток натестили 50мбит, в 40 потоков 400 мбит. Вот и думай после этого

я лично видел эти настройки у магистрала, не буду говорить у какого

ну тот же qos на случай перегрузок могут настроить, но порты ж тоже в полку никто не держит

я лично видел эти настройки у магистрала, не буду говорить у какого

есть пиковые моменты, они практически у всех окдинаковые

Щас, чую, админ опять придет и нас гонять будет

здесь все свои, так что можно не скрывать имя этого чудесного представителя операторов связи)))

у меня пиковый момент уже неделю, судя по всему ))

это ж в прямую относится к функционалу zfs send/recv ) да и всегда приятно в чатах что-то новое узнать)

это ж в прямую относится к функционалу zfs send/recv ) да и всегда приятно в чатах что-то новое узнать)

https://github.com/openzfs/zfs/releases/tag/zfs-0.8.5

Если я создал снапшот, выглядит это так: NAME USED AVAIL REFER MOUNTPOINT mega/subvol-104-disk-0@october_08_2020 2,03M - 53,0G - Т.к. снапшот хранит только ссылки на данные, то получается что 53Гб это те данные, которые уже не будут перезаписаны внутри сабвола, т.к. на них снапшот ссылается ? И соответственно чем больше снапшотов, тем больше это "неприкасаемое" пространство ?

Это copy on write, там не перезапись а сохранение версии блока, которая была на момент снапшота. Чем больше изменений произошло с момента снапшота, тем больше старых блоков не удалилось и размер снапшота вырос. Разные снапы могут ссылаться на одну версию блока.

NAME USED AVAIL REFER MOUNTPOINT mega/subvol-104-disk-0@october_08_2020 335M - 53,0G - 1) Сейчас used - 335М (было 2,03М) , так понимаю это и есть изменения с момента снапшота и по факту занимаемое снапшотом место? 2) Только не понимаю почему именно размер снапшота растёт.. это же просто сохранённые версии блоков.. вот это вроде понятно "Чем больше изменений произошло с момента снапшота, тем больше старых блоков не удалилось", выходит что снапшот хранит историю изменения блоков (было - стало) из первоначальных 53Гб ? а потом если надо откатывается к "было" игнорирую всё из "стало" ?

Это copy on write, там не перезапись а сохранение версии блока, которая была на момент снапшота. Чем больше изменений произошло с момента снапшота, тем больше старых блоков не удалилось и размер снапшота вырос. Разные снапы могут ссылаться на одну версию блока.

Ну кстати вот цитата: "При создании снимка его пространство первоначально используется совместно с файловой системой и, возможно, с предшествующими снимками. При изменении файловой системы пространство, которое ранее использовалось совместно, полностью передается снимку и учитывается в свойстве used этого снимка."

Ну это всё нюансы учета. А вот интересно то, что при удалении снимков, никогда нельзя заранее точно сказать сколько места высвободится. И решить эту проблему можно только используя параметры -npv или -nv для человекочитаемого вывода, которые предотвращают удаление, но позволяет вывести информацию о высвобождаемом пространстве в команде zfs destroy -npv Ситуация ещё сложнее если нужно удалить сколько-то снимков чтобы освододить Х гигабайт. Лично я делаю это перебором, благо, можно сделать так: zfs destroy -npv <filesystem|volume>@<snap>[%<snap>][,...]

не понял о чём это)

вроде этот https://github.com/mafm/zfs-snapshot-disk-usage-matrix

Извините за тупой вопрос. А в страйпе 2+2+3 можно сменить 2тб на 4тб? Пул станет 9тб без потери инфы?

второе

щас я вам тесты raid 10 из 4х nvme 960GB + slog на оптанах (900p) выложу. >2Gb/s на случайной записи.