OK, сразу после того, как ты мне любезно укажешь место, в котором я утверждаю, что данная утилита в составе OpenBSD есть. ;)
Я задал уточняющий вопрос именно для того, чтобы понять о какого рода «просмотре дисков» ты говоришь. FYI, disklabel(8) делает почти тоже и даже больше, но не глобально, а для отдельного устройства.
Я задал уточняющий вопрос именно для того, чтобы понять о какого рода «просмотре дисков» ты говоришь.
Ну... типа какие диски в системе есть :)
Чаще всего мне это интересно, когда у меня корзина дисков на 48 и мне нужно понять, все мы там сигейты определенной партии уже поменяли, или ещё чего-то осталось. Ну или посмотреть, что там по SCSI подхватилось из сети (nvmeof пока нет, но когда будет, это тоже будет интересно).
FYI, disklabel(8) делает почти тоже и даже больше, но не глобально, а для отдельного устройства.
disklabel показывает disklabel. Что не удивительно. А я просто список дисков хочу увидеть. Все осложняется тем, что у openbsd до сих пор статический /dev, поэтому наличие device node ничего не говорит о том, есть ли за ним реальный диск. У них конечно есть для этого sysctl, но блин.
Прямо идея для пет-проджекта. Выгребать устройства посредством sysctl, опрашивать их посредством disklabel и выводить согласно набору ключей. :\
В OpenBSD давно напрашивается sysctl типа hw.tree.<type>.<device> с выводом в виде таблицы. Но поскольку никто в здравом уме не использует openbsd для хранения хоть чего-то важного (потому что FS теряет файлы, а блочная подсистема медленная шоппц), то и тулза особо не нужна.
Согласен, задумчивая она пц. На рабочем лэптопе Опёнок с первого дня живёт на ssd, и производительностью никогда не пугал, но и файлов я не терял ни разу.
Впрочем, мб выборка не репризентативна, всего пара хостов.
Согласен, задумчивая она пц. На рабочем лэптопе Опёнок с первого дня живёт на ssd, и производительностью никогда не пугал
Не, для досктопа и роутера у неё вполне мощностей хватает. Но вот какой-нибудь postgres поверх SSD уже вызывает проблемы из-за так и не выпиленного BKL. Подвижки есть, но в 2k19 это уже выглядит странно.
но и файлов я не терял ни разу
Месяца три назад у меня вывалился кабель из раутера. В итоге, ядро оказалось битым, а lost+found пополнился частью *.o файлов из /usr/share/relink/чего-то-там.
Месяца три назад у меня вывалился кабель из раутера. В итоге, ядро оказалось битым, а lost+found пополнился частью *.o файлов из /usr/share/relink/чего-то-там.
А, теперь понял о каких случаях повреждения fs речь, сталкивался, но без особых последствий. В основном, когда какие-нибудь злодеи отключали БП от док-станции или сам забыл включить его в розетку. :) Потом стал более сосредоточенным оброс скриптами для sensorsd. ;)
А, теперь понял о каких случаях повреждения fs речь, сталкивался, но без особых последствий. В основном, когда какие-нибудь злодеи отключали БП от док-станции или сам забыл включить его в розетку. :) Потом стал более сосредоточенным оброс скриптами для sensorsd. ;)
Ну как бы и вот. В лялехе я такого не видел с момента глупых багов в XFS, которые ногами в 80-е уходят.
Я старовер на своих Линуксах использую ext4, как-то так повелось. За исключением домашнего NAS построенного на HP MicroServer c CentOS, но и там xfs только для системы.
Я старовер на своих Линуксах использую ext4, как-то так повелось. За исключением домашнего NAS построенного на HP MicroServer c CentOS, но и там xfs только для системы.
Да я тоже, но с ext4 такого в принципе никогда не случалось. А вот XFS «радовал» вплоть до 2014-го вроде.
turtle_bazon, ssh2 XFS чуть-чуть более прогрессивная по дизайну и ее потенциал масштабироваться под многопоточностью выше. соотвественно, после того, как RH ее сделал базовой (RHEL6, кажется) она стала достойным выбором.
другое дело, что туповатый systemd (а точнее ее разработчик) вшил вызов system(fsck) в сишный код без осознания, что fsck.xfs не чинит автоматически fs. я уже не помню подробностей, но systemd+xfs просто не могли починиться после подения на RHEL7 в самом его начале.
xfs за счет заморозки состояния хорошо вяжется с lvm snapshots.
а вообще и ext4, и xfs - это уже отчасти устаревашие фс. нет гарантий от bitrot для больших помоек.
проверял вчера ночью, как там ZFS поживает, на freebsd - отсутсвует интеграция кеша новомодной фс и vm подсистемы linux/freebsd. короче, куда не кинь ограничения и недоделки.
рад, что ты спросил вместо обвинений в тупости (или это еще впереди?).
Сохранять текстовые логи в текстовые логи? Зачем?
ты знаешь, что syslog - это не текстовые логи вообще-то? syslog - это RFC 5424, протокол удаленной передачи логов? теперь смотри.
есть такая классическая ситуация... ну допустим ISP, домашние сеточки (в одной такой я работал), там линуксов штук 20-30 (на самом деле не знаю точно, сколько в других отделах), а сетевого оборудования ... черт, я уже не помню... ну пара тысяч умных свичей на город, допустим. и они все могут сливать логи по syslog в одно какое-то место. общий коллектор логов.
жорналд не является стандартом - это а. жорналд - изначальное не содержал средств для удаленной передачи логов - это б (а то, что содержит сейчас - это г).
для интеграции линуксов теперь надо настраивать вот это самое проксирование логов в rsyslog. journald пока разберется со своими структурами и ring buffer всеравно создаст нагрузку на сервер. если это нагруженный сервер, где много логов, он создаст большую нагрузку. молись, чтобы при этом не надо было сохраняться вот этим самые нетекстовые логи локально, ибо journald by design более тормозной (делал минитесты. он раза в три более тормозной), чем любой писатель текстовых логов. особенно rsyslog, который уже больше десятилетия задрачивают на перфоманс в таких ситуациях.
в принципе, я не против, если ты прочитаешь вышесказанное и решишь меня обо*рать. мол, «не надо», «не будет» и прочее.
после переписки с alpha, которая как бы разрабатывает базовую систему в RedHat и которая считает, что проксирование вполне заменяет syslog бекэнд (и, очевидно, даже не представляет ситуации с ISP), вы меня можете просто пристрелить, чтоб я не мучался. мне просто не понятно, почему, реализуя крон, ntp, dhcp, systemd не реализует прямую передачу логов по syslog протоколу.
ты знаешь, что syslog - это не текстовые логи вообще-то? syslog - это RFC 5424, протокол удаленной передачи логов? теперь смотри.
Знаю. Более того — не только (и не столько) этот. Потом что legacy syslog все ещё более активно используется (в том числе той же openbsd).
есть такая классическая ситуация... ну допустим ISP, домашние сеточки (в одной такой я работал), там линуксов штук 20-30 (на самом деле не знаю точно, сколько в других отделах), а сетевого оборудования ... черт, я уже не помню... ну пара тысяч умных свичей на город, допустим. и они все могут сливать логи по syslog в одно какое-то место. общий коллектор логов.
Я так на работе делаю.
жорналд не является стандартом - это а. жорналд - изначальное не содержал средств для удаленной передачи логов - это б (а то, что содержит сейчас - это г).
Никто этого и не утверждал.
для интеграции линуксов теперь надо настраивать вот это самое проксирование логов в rsyslog. journald пока разберется со своими структурами и ring buffer всеравно создаст нагрузку на сервер. если это нагруженный сервер, где много логов, он создаст большую нагрузку. молись, чтобы при этом не надо было сохраняться вот этим самые нетекстовые логи локально, ибо journald by design более тормозной (делал минитесты. он раза в три более тормозной), чем любой писатель текстовых логов. особенно rsyslog, который уже больше десятилетия задрачивают на перфоманс в таких ситуациях.
Кхм... во-первых, я знаю, какой rsyslogd быстрый (нет, не такой быстрый, как хотелось бы), потому что в начале года я чинил потери логов на нашем централизированном лог-хранилище. Во-вторых, в моей конторе мы шлем ВСЕ логи со ВСЕХ наших серверов (несколько сотен штук). И это не умные свичи, это фронты, которые фигачат 24/7. И нет, journald <-> rsyslogd даже не в top5 потребителей ресурсов.
И нет, journald <-> rsyslogd даже не в top5 потребителей ресурсов.
просто мощное железо прикрывает плохой дизайн. ничего из твоего ответа не отменяет факта, что нативный syslog в journald нужен.
во-вторых, очевидно, у вас journald не пишет логи локально. то есть логи локально вы вообще не храните. а если девелоперам надо смотреть логи и у них нет доступа до коллектора? хватает ring buffer?
хрен его знает, отвечает или нет... если сыпаться не начнет, то отвечает. у меня есть помойка на xfs с таким рейдом, где вообще по-моему ни одна контрольная сумма (посчитано скриптом с год назад) уже не совпадает... может, посчитал криво. копать надо.
во-первых, я знаю, какой rsyslogd быстрый (нет, не такой быстрый, как хотелось бы), потому что в начале года я чинил потери логов на нашем централизированном лог-хранилище.
ок, fair enough. НО он, мл*, всеравно в три раза быстрее, чем структурированные логи journald! если бы ты начала писать эти самые структурированные логи, то он бы и проксировал с потерями в три раза выше!
И нет, journald <-> rsyslogd даже не в top5 потребителей ресурсов.
чуть не забыл. основная масса логов точно генерируется через native journald api? или все-таки у вас nginxы, которые используют syslog интерфейс? тогда логи поступают сразу в rsyslog и уже оттуда забираются journald. тогда да, нагрузки на него почти нет. я проверял.
кстати я думаю не выложить ли эти тестики для обсуждения отдельной темой.
ты уверен, что у вас логи именно проксируются через journald (отправлены нативно), а не выгребаются жорналд уже после, асинхронно, в то время, как rsyslog их там отправляет?
Нет, на терминаторе часть логов уходит в эластик безразвратно (у.рсислога модуль есть), часть на лету гзипится (тем же рсислогом) и пишется в по хитрым правилам созданные файлы для удобного анализа.
вот, уважаемый разработчик из redhat alpha, на примере чужой системы показываю тебе, что journald не применяется ни для хранения логов локально, ни для структурированного хранения логов. Его, цитирую,
Nginx'ы пишут в /dev/log, который выгребается journald и релеится в rsyslogd.
/dev/log создается rsyslogd. это его native interface. systemd использует вместо него какой-то свой сокет в системе. можно сказать, что у вас наоборот rsyslog служит релеем для journald, который вам вообще не нужен, но удалить нельзя.
/dev/log создается rsyslogd. это его native interface. systemd использует вместо него какой-то свой сокет в системе. можно сказать, что у вас наоборот rsyslog служит релеем для journald, который вам вообще не нужен, но удалить нельзя.
Не совсем, /dev/log создается модулем imuxsock, вроде так он называется. Но в RHEL этот файл создается самим journald.
мм, а можно ваш конфиг journald без коментов, если это не секрет. я когда тестил, у меня все-таки модуль rsyslog его создавал и по-моему все-таки создание его через journald по умолчанию отключено.
я проводил (правда очень грубые) тесты с отправкой логов через нативный сокет journald, когда он их потом действительно релеит в rsyslog. там было все очень-очень грустно.
мм, а можно ваш конфиг journald без коментов, если это не секрет. я когда тестил, у меня все-таки модуль rsyslog его создавал и по-моему все-таки создание его через journald по умолчанию отключено.
там по умолчанию ForwardToSyslog=no т.е. он через себя логи не прокачивает.
а по поводу стрейс - ну просто зацепился за девайс и слушает. не так важно, кто его создал, но факт в том, что логи туда попадают в формате syslog, а потом забираются и rsyslog, и journald. journald особо не парится и как успевает их оттуда достает. может и с отставанием в 5 минут, ты всеравно это не заметишь. а rsyslogd фигачит со всей дури по сети лишь бы успеть.
а по поводу стрейс - ну просто зацепился за девайс и слушает. не так важно, кто его создал, но факт в том, что логи туда попадают в формате syslog, а потом забираются и rsyslog, и journald.
Пажжи, пажжи, пажжи. Сокеты так не работают. Один создает, второй коннектится. Коннектов может быть много, но они все изолированны друг от друга. Один пир не может послать другому пиру сообщение, иначе dbus был бы не нужен.
journald особо не парится и как успевает их оттуда достает. может и с отставанием в 5 минут, ты всеравно это не заметишь. а rsyslogd фигачит со всей дури по сети лишь бы успеть.
Опять же нет, потому что journald там на epoll'е висит.
Я вот хочу ZOL посмотреть. Пока руки не дошли. Пока пользуюсь XFS. На Debian. Иногда, где уже ext4 установлена и что-то очень лениво всё переделывать, пользуется. Но с xfs заметны какие-то подтормаживания и прочая ерунда. Особенно под нагрузкой.