Бывают на свете приложения и программисты, которые о сетевом доступе знают только "расшарить файл по сети"
Подоконники
Mark ☢️
Евгений
Прямо сейчас systemd схавал ВСЕ 64 ЯДРА
edo1
Сейчас проверил три варианта
edo1
edo@edo-home:~$ dd if=/dev/zero of=/dev/null bs=1M count=10240
10240+0 записей получено
10240+0 записей отправлено
10737418240 байт (11 GB, 10 GiB) скопирован, 0,698013 s, 15,4 GB/s
edo1
edo@edo-home:~$ dd if=/dev/zero bs=1M count=10240 | dd of=/dev/null bs=1M
10240+0 записей получено
10240+0 записей отправлено
10737418240 байт (11 GB, 10 GiB) скопирован, 3,85303 s, 2,8 GB/s
edo1
edo@edo-home:~$ dd if=/dev/zero bs=1M count=10240 |pv| dd of=/dev/null bs=1M
10GiB 0:00:03 [2,73GiB/s] [ <=> ]
4+163562 записей получено
4+163562 записей отправлено
10737418240 байт (11 GB, 10 GiB) скопирован, 3,66054 s, 2,9 GB/s
edo1
итого: pv пофиг
Евгений
ну ок. Оно уже полсуток тарахтит
Mark ☢️
Я знаю как ускорить
Евгений
Там raid5 с одним вылетевшим драйвом
edo1
Нобарриер не корраптит фс
гхм. сам он не корраптит, но гарантирует, что barrier в любой момент файловая система в консистентном состоянии
Mark ☢️
А. На чтении тормозит ...
Евгений
ускорить тока топором
Евгений
12 мешкобайт в секунду
Mark ☢️
гхм. сам он не корраптит, но гарантирует, что barrier в любой момент файловая система в консистентном состоянии
Барриер никак не связан с консистентностью фс
edo1
???
edo1
а нафига тогда его придумали?
Mark ☢️
А вот данные на ней могут быть не теми что ожидал кто его переключал
Mark ☢️
Якобы
Mark ☢️
А потом поняли что хуйня всё это
Mark ☢️
Это барьер между изменениями метаданных и данных
edo1
@socketpair ты что-то не то пишешь
Mark ☢️
Суть - при сбое питания будет либо недопис либо мусор
edo1
барьер придумали как альтернативу синку, да
edo1
и в этом плане он ускоряет офигенно
Mark ☢️
Пруф блять
edo1
суть барьера - что данные запишутся в известном нам порядке на диск и никак иначе
Mark ☢️
edo1
аналогично - пруф
Mike
Плахов в fb поделился ссылкой, что настройки годные: https://www.hastexo.com/resources/hints-and-kinks/more-recommendations-ceph-openstack/
Кто-то не знал? Параметры про scsi и есть в доке openstack и ceph. И именно с virtios-scsi работает trim
Mark ☢️
Опция в фс это делать ли барьер между записью метаданных и данных
Mark ☢️
Для нормальных прилаг это похуй
Mark ☢️
Поэтому типа для ускорения барьер можно отключить
Mark ☢️
А для говнософта это катастрофа
Mark ☢️
Который про атомарные операции типа мува и про фсинк не знает
edo1
There is a hitch, though: the filesystem code must, before writing the commit record, be absolutely sure that all of the transaction's information has made it to the journal. Just doing the writes in the proper order is insufficient; contemporary drives maintain large internal caches and will reorder operations for better performance. So the filesystem must explicitly instruct the disk to get all of the journal data onto the media before writing the commit record; if the commit record gets written first, the journal may be corrupted.
edo1
https://lwn.net/Articles/283161/
edo1
причём тут говнософт?
edo1
речь про то, что журналируемая файловая без барьера становится хрустальной вазой
edo1
одно неверное движение - и каша
edo1
и там уже придётся звать fsck с непонятными перспективами
edo1
напомню, изначально речь была про то, нужен ли fsck в случае аварийной миграции виртуалки на другой хост.
я говорю - что нет, если только горе-оптимизаторы не включили nobarrier.
ну, разумеется, плюсом подразумевается, что багов нет в коде fs (мы же живём в идеальном мире)
edo1
журнал как раз и придуман был для того, чтобы в случае факапа мы могли либо откатить, либо принять последние изменения метаданных (а не получить кашу). но из-за кэшей надо либо делать mount -o sync (что ну очень плохо с точки зрения производительности), либо вот придумали няшные барьеры
Anonymous
причём тут говнософт?
При том что уважающий себя софт сброс кешей делает, после критичный операции. Независимо есть nobarrier или нет
edo1
Блин, ну не надо путать тёплое с мягким
edo1
Софт сбрасывает данные
edo1
А тут речь о консистентности фс в целом
Mark ☢️
https://lwn.net/Articles/400541/
Mark ☢️
2010 год правда
Mark ☢️
Кароче. Я не прав. Отключение барьеров риальне приведет к коррапту фс
Yuf
Часто ли практикуют openstack conpute node на ceph
Yuf
?
Sn00part
часто. мирантис опенстек так только и работает.
Mike
Говорю тебе, как потребитель мирантиса в проде в течении трёх лет.
Sn00part
кило поди какой-нибудь? ну так обнови до последних сборок. я там работал есличо
Mike
Что мне обновлять этот мертвый дистриб? В 8-ке, 9-ке можно делать отдельные osd. И так и нужно делать.
edo1
Речь про совмещение vm и osd?
Mike
Гипервизора и ceph
edo1
а почему все так негативно относятся к совмещению?
Mike
Не хотят повторять урок dreamhost
edo1
разве там в этом дело было? )))
Mike
Да, приводил тут ссылки
J
а почему все так негативно относятся к совмещению?
Потому что в энтерпрайзе не принято своей головой думать. Чтобы совмещать нужна аккураьность и лучше понимать для чего ты это делаешь.
Mike
edo1
я рассуждаю так: если речь про то, что нам может не хватить памяти и может прийти oom killer, то 256 на одном хосте несёт меньше рисков, чем 128 на гипервизоре+128 на хранилище
J
А там где по-крупному внедряют ни разбираться ни брать на себя ответственность не хочет никто)
Mike
Sergei
А там где по-крупному внедряют ни разбираться ни брать на себя ответственность не хочет никто)
а денег там вагон, их никто не считает и зарабатывать их не нужно? (я просто спросил, реально не знаю)