LINUX.ORG.RU

Pi-KVM вышел на Kickstarter

 , , , ,

Pi-KVM вышел на Kickstarter

7

2

Спустя год после первого релиза, Pi-KVM представил свое собственное железо на Kickstarter.

Pi-KVM - это проект, объединяющий в себе софт и инструкции, которые позволяют превратить Raspberry Pi в полностью функциональный IP-KVM. Это устройство подключается к HDMI- и USB-портам сервера, и позволяет управлять им удаленно по сети, независимо от операционной системы. Можно включить, выключить или перезагрузить сервер, настроить BIOS и даже полностью переустановить ОС с образа на эмулированном виртуальном носителе. Вся функциональность (в том числе и передача видео) доступна через веб-интерфейс, не требующий никаких дополнительных плагинов и апплетов, и реализованный только средствами HTML5.

Представленное на кикстартере устройство (Pi-KVM v3 HAT) является небольшой платой для Raspberry Pi, которая содержит в себе всё, что нужно было раньше покупать отдельно и/или собирать самостоятельно, а еще имеет ряд дополнительных уникальных фичей. Pi-KVM v3 HAT является альтернативой для тех, кто не хочет возиться со сборкой сам, но желает получить надежное устройство продакшн-уровня.

В числе заявленных возможностей:

  • HDMI-видеовход (1080p 50Hz) с возможностью захвата звука;
  • Встроенный контроллер ATX для управления питанием сервера;
  • Прерыватель USB для эмулирования действия «вытащить-вставить»;
  • Последовательная CISCO-консоль и USB-TTL, которые можно использовать для администрирования Pi-KVM или подключения к серверу;
  • Часы с ионистором для точного логгирования;
  • … и многое другое (см. раздел Features).

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

  • Новый режим передачи видео с помощью WebRTC/H.264, значительно снижающий потребление трафика по сравнению со старым MJPEG;
  • Экспериментальная поддержка H.264 в VNC (разработан стандарт, зааппрувлен в IANA, поддержка доступна в тестовой ветке TigerVNC);
  • Собственные патчи на ядро, добавляющие совместимость USB-клавиатуры и мыши с Apple UEFI (теперь можно зайти в UEFI или Boot Manager и что-нибудь там понастраивать);
  • Поддержка относительной мышки и возможность динамического переключения между ней и абсолютной для систем, которые не поддерживают последнюю.
  • PS/2-клавиатура, доступная через подключенный Arduino, а так же эмуляция Bluetooth-клавиатуры и мышки.
  • Возможность управления GPIO через веб-интерфейс (можно подключить реле, сервы для нажатия физических кнопок или считывать внешние сигналы).
  • Интеграция с KVM-свичами типа Ezcoo и Tesmart, которые позволяют превратить Pi-KVM в многопортовое устройство.
  • Средства мониторинга температуры и напряжения Raspberry Pi;
  • Встроенные клиенты IPMI и Wake-on-LAN, позволяющие управлять питанием подключенных серверов прямо из веб-инетфейса.
  • Серверная поддержка Redfish и IPMI;
  • Возможность настройки USB-Ethernet для связи с сервером. Pi-KVM будет сам давать ему адрес по DHCP и даже позволяет сделать аплинк с маршрутизацией через Raspberry.

>>> Подробности

★★★★

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

Я сейчас с драйвером его продолжаю биться, скорость CSI-2 я смог в DTB файлах задать и в драйвере, и мне чтобы оно увидело мою эмуляцию CCI (оно же I2C) нужно битбанг I2C, а для этого скорость надо для I2C прибить, до комфортных например 10 кГц

I-Love-Microsoft ★★★★★
()

VGA-вход то возможен каким-нить образом? А то большинство серверов до сих пор с ним.

И правильно ли я понимаю, что эту штуку возможно использовать через wifi?

STinger
()
Ответ на: комментарий от lvdm1

Raspberry Pi - Замечательнейшее устройство . Такой вопрос: оно подойдет для маленького интернето-фильмового десктопа?

Да.

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

Надо использовать активный конвертер. Wifi работает, конечно.

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

хм sync && sync && sync && poweroff, а просто poweroff не катит у меня проблемы бывали только по внезапному ресету, если вызывался poweroff то всё грамотно завершалось.

Очень к стати может быть что моя повышенная аварийность ext2 и связана с тем что я делал журналы больших размеров, (но не настолько больших чтобы ext3/4 навернулись немедленно)

в ext2 нет журнала, ext3/4 только наличием журналом и отличаются. Можно как ext2 подключать, чем виндузятники и ползуются.

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

Ну не сразу же, не при первом же poweroff'e всё обваливается...
Хотя как-то с установочным диском совсем эпик был, перегружаюсь, а половины базовых команд просто нету, так как был огромный откат журнала.

Ну и возможно в подтверждение моих слов есть комментарий:

и не знаешь, что разные виды реплик на уровне ФС нуждаются в ряде проверок, что данные «правильно реплицировались». Вот тут, кстати докер-фаны и просираются знатно, когда просралась потоковакая реплика и некорректно заsync’алась, и речь не про базы уровня 10-20 Гб, а про терабайтные базы,


Переоценен ли K8S/Docker с некоммерческой точки зрения? (комментарий)

twinpeaks , давай признавайся, там ведь у вас EXT3 или EXT4 используется?

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

Пфффф. Значит, с аффтаром девайса мы, в принципе, похоже рассуждаем.

Как будто тут может быть так уж много вариантов применения.

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

Ну не сразу же, не при первом же poweroff'e всё обваливается...

debian 7-9-10, xfce штатным завершением работы не пользуюсь, (запрос через раз пароля напрягает) sudo poweroff вынесен на отдельную кнопку, c внесением nopassword в sudoerc, быстрое завершение. Задержек при следующем запуске, как при аварийном завершении не наблюдаю.

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

Похожее было, ноут по питанию отрубился и серия скачанных файлов манги в расход.

В контейнере? если в основной системе - то вашу не любовь к ext понимаю. os не скажите?

Докером и snap контейнерами не пользуюсь, использую в lxc контейнеры (вроде в докер обёртка над lxc ну или cgroup, могу и ошибаться). Может докер воду мутит, но всё равно файловую систему это не извиняет.

Если бы сейчас с нуля ставил (ставлю, ноуты меняю, но раздел на hdd home уже 8 лет не менялся), использовал бы btrfs: иногда лимиты нужны, да и сжатие не лишнее.

s-warus ★★★
()
Ответ на: комментарий от torvn77

torvn77 ★★★★★ (07.09.21 15:38:15) twinpeaks , давай признавайся, там ведь у вас EXT3 или EXT4 используется?

Увидел твой меншон. Не очень понял, «где там». Но если тебе интересно, с какой fs - в основном нормальные РСУБД у меня сидят.

То, все под XFS и на systemd. Оркестрируется через Ansible. Работает хорошо.

Молодое поколение - различную наркоманию устраивает, аля:

  • Ceph Rook заюзать
  • попробовать btrfs вместо xfs или ext4
  • подложить себе динамит под лобное место helm-chart, поведение которого они контроллировать не могут

P.S. вообще ты меня дернул во время, когда я после бара пришел домой. Я малость не понимаю о чем речь, но попытался сказать, как есть хоть и двоится в глазах. Это примерно, как подняться на 4-ый этаж, но ниже.

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

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

P.S. Вообще субъективно btrfs немного тормознутая , так что критику замены xfs на btrfs одобряю, если и менять её, то имхо минимум на F2FS или что там новое специально для твёрдотельных накопителей придумали.

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

torvn77 ★★★★★ (08.09.21 00:13:30) часть людей отрицает то,то что файловые системы ext3 или ext4 могут и приводят к проблемам и приключениям, в то время как btrfs нет

Апчхи! Прости, у меня - аллергия на пздж. Btrfs-то не приводит к проблемам? ))) Кстати, народ в курсах, что RedHat даже открестился от btrfs? Ну пусть попробуют под интенсивной нагрузкой с ней поработать, к примеру кластер Postgres или даже Elastic покрутить в течении 6 месяцев, потом расскажут пусть о впечатлениях эксплуатации :)

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/storage_administration_guide/ch-btrfs

Btrfs is available as a Technology Preview feature in Red Hat Enterprise Linux 7 but has been deprecated since the Red Hat Enterprise Linux 7.4 release. It will be removed in a future major release of Red Hat Enterprise Linux.

twinpeaks
()
Ответ на: комментарий от torvn77

torvn77 ★★★★★ (08.09.21 00:56:59) А если нагрузки нет?

Ну тут, я не знаю что сказать :) Для меня основной показатель - это нагрузка, все-таки. Ибо, для чего еще нужно подбирать правильную FS для ПРОД-систем? Да и годная FS должна годно работать под нагрузкой и быть готовой к fault tolerance сценариям.

В принципе-то, все проблемы можно найти тут:

Если вопрос в контексте, юзания на home laptop… Btrfs давно прославилась, как FS которая теряет данные…

Помню где-то год назад, ради интереса собирал RAID-массив с btrfs, просто поиграться. Баги и проблемы, у btrfs были… В итоге, после этого убедился, что btrfs все еще сырой.

Плюс, в Гугле нашел такой линк:

The following is a list of bugs that are causing repeated operational issues on RAID5 arrays on btrfs. Confirmed recently on 5.4.41.

Походу, я не одинок в нахождении проблем btrfs при мало-мальски нормальных-рабочих сценариях.

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

Кручу btrfs под нагрузкой 24/7, один раздел насилую, поднимая/гася более одной виртуалки в секунду с онлайн-сжатием, на втором храню репы с дедупликацией под четверку и тоже со сжатием. Умножить на два хоста. Этакий случайный стресс-тест btrfs уже второй год. Все отлично. Без btrfs грустно плакал бы и жевал бы XFS.

И при всем при этом тараканник наш все равно гонит пургу. Если уж это однажды и сломается, я даже пытаться рекаверить ничего не буду.

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

Спасибо за инфу при оказии перейду на btrfs. Тем более что для домашнего использования, raid использовать не планирую.

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

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

ну не знаю, у меня с ext тоже рекавер невсегда получался, в целом как я понимаю на Linux вообще утилиты для рекавера носят символический характер и основной способ восстановления информации это бекап.

И при всем при этом тараканник наш все равно гонит пургу.

Просто надо понимать то, что "терабайтная база с ИБП двойного преобразования" и локалхост на SSD 64 ГБ или даже флешке в 16 ГБ это совершенно разные вещи.

По заветам предшественников ОС не следует ставить на один раздел, а разбивать на несколько для уменьшения разрушений причиняемых ошибками записи.
Ну и теперь подумай, что будет если флешку в 16 ГБ разбить на несколько разделов, особенно если с учётом того, что надо оставлять часть раздела пустым для снижения износа ячеек?
Будет куча маленьких разделов с кучей пустого места и с async,data=ordered и поверх всей этой тесноты работают огнелис и хром с включенным дисковым кешем и дефолтной частотой записи состояния на диск.
При всём этом переодически происходит паралич системы из-за исчерпания свободного ОЗУ с последующим исправлением в виде нажатия кнопки Reset.

Я понимаю так, что именно таким образом вы эксплуатируете продакшн?
В таких условиях вообще любая ФС без субтомов будет крайне неудобна в эксплуатации и приводить к неоптимальному использованию диска, а к EXTx добавляется ещё и использование async(у btrfs этой олпции просто нет)

С другой стороны BTRFS в таких условиях показывает только плюсы:
1. Противоречие между маленьким объёмом вызывающим ускоренный износ ячеек и необходимостью разбивкой накопителя для снижения последствий ошибок ФС снимается субтомами без особого снижения надёжности.
2. сквозное сжатие увеличивает скорость чтения и экономит место.
3. журналирование сделано так, что даже если у меня commit=3600 при внезапном отключении питания не происходит каких либо заметных ужасов.


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

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

флешку в 16 ГБ

огнелис и хром

Я даже вникать не буду, из какого мира ты пришёл, просто пройду мимо.

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

Кручу btrfs под нагрузкой 24/7, один раздел насилую, поднимая/гася более одной виртуалки в секунду с онлайн-сжатием, на втором храню репы с дедупликацией под четверку и тоже со сжатием. Умножить на два хоста. Этакий случайный стресс-тест btrfs уже второй год. Все отлично. Без btrfs грустно плакал бы и жевал бы XFS.

По-подробнее плиз. Под чем Вы крутите btrfs конкретнее?

  • RAID использовали с btrfs?
  • что есть ваша «нагрузка 24/7», можно поподробнее? IOPS приведите или др. статистику, которая лучше говорит о нагрузке

И при всем при этом тараканник наш все равно гонит пургу. Если уж это однажды и сломается, я даже пытаться рекаверить ничего не буду.

Это очень громкое заявление :) С учетом того, что даже RedHat пометил, как deprecated эту Вашу btrfs и открестился. Можно, конечно сказать, что в RedHat - «дебилы» сидят, да и вообще много кто «туфту» гонит из Гугла, где 100500 первых ссылок хором говорят о проблемах с потерей данных в btrfs.

Теперь, касаемо моего примера. Я спорить не буду, ибо не очень заинтересован. Могу сказать про свой мини-сетап, когда я тестил btrfs:

  1. попробуйте RAID-10 с mdadm заюзать с этим вашим btrfs
  2. установите Postgres на 2-ух тачках
  3. настройте потоковую синхронную реплику между ними
  4. начните использовать high load benchmark, который будет вам в день прирост базы делать по 100 Гб в день
  5. попереключайтесь между master-slave в плане реплик
  6. поребутьте ваши тачки

И потом расскажите, что увидите при таком тестировании. Если же, у Вас будет все ок с btrfs - совет, да любовь Вам с ним.

Для ПРОДа, я лично везде XFS использую, ибо показала данная ФС наиболее лучшую стабильность, лично для меня.

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

RAID использовали с btrfs?

На одном из этих хранилищ образов ВМ btrfs RAID0. btrfs RAID 1 юзал когда-то несколько лет для домашнего NAS еще.

что есть ваша «нагрузка 24/7», можно поподробнее?

Запустил виртуалку из снапшота в файле с цепочкой в пяток-десяток предков — погонял — погасил с выбрасыванием или сохранением. ~16 ВМ параллельно, в среднем каждую секунду одна стартует, одна гасится.

IOPS приведите или др. статистику, которая лучше говорит о нагрузке

Знал бы, как замерить.

у Вас будет все ок с btrfs - совет, да любовь Вам с ним.

У меня уже ОК. Нет альтернативы, понимаешь, мне и рефлинки нужны, и сжатие.

Можно, конечно сказать, что в RedHat - «дебилы» сидят

Но-но, я вообще-то вместе с этими двумя хостами сам в Red Hat сижу.

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

t184256 ★★★★★ (08.09.21 17:49:46) Но-но, я вообще-то вместе с этими двумя хостами сам в Red Hat сижу.

Ну, я уже приводил ранее с офиц. сайта:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/storage_administration_guide/ch-btrfs

Btrfs is available as a Technology Preview feature in Red Hat Enterprise Linux 7 but has been deprecated since the Red Hat Enterprise Linux 7.4 release. It will be removed in a future major release of Red Hat Enterprise Linux

Слушай, не буду спорить :) Нравится тебе и нравится. Мой персональный опыт говорит о другом, я после ряда багов с btrfs в ближайшие два года ее рассматривать точно не буду. Ибо, у меня по работе обслуживание баз данных, и там нужна близкая стабильность к 100% , XFS такую стабильность дает. Не хочу потом проснуться в 3-4 утра и чинить последствия багов btrfs…

Кстати, нашел еще интересую ссылку:

Там, тоже, косяки btrfs обсуждают и приводят аргументацию неплохую местами.

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

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

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

В контексте всего этого я не понимаю, как можно советовать btrfs мне на квм вместо дубовой связки ext4+ro.

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

То, что RH утратила к BTRFS бизнесинтерес не означает того, что эта ФС плохая, это значит что RH не будет больше в неё вкладывать денег и всё.
В остальном это идеальная FS для корня системы, профиты от которой перевешивают все её недостатки.

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

torvn77 ★★★★★ (09.09.21 00:44:04)

То, что RH утратила к BTRFS бизнесинтерес не означает того, что эта ФС плохая, это значит что RH не будет больше в неё вкладывать денег и всё.

Я бы призадумался бы над темой:

  • почему они утратили интерес?
  • и дело ли только в бизнесе?
  • а бизнес как оценивает btrfs? оценивает ее баги, возможные проблемы в обслуживании с серверами? ибо, все-таки RedHat ориентируется на серверную составляющую, RHEL, OpenShift, OpenStack и др., может не очень хорошо btrfs себя показывает
  • а может btrfs плохая для PROD-площадок, где сплошником RAID’ы или дистрибутивный Ceph?

PS: нашел линк, где бывший сотрудник RedHat поясняет:

PS2: еще нашел

Although FileStore is generally capable of functioning on most POSIX-compatible file systems (including btrfs and ext4), we only recommend that XFS be used. Both btrfs and ext4 have known bugs and deficiencies and their use may lead to data loss. By default all Ceph provisioning tools will use XFS.

twinpeaks
()
Ответ на: комментарий от liksys

liksys ★★★ (09.09.21 00:32:34)

В контексте всего этого я не понимаю, как можно советовать btrfs мне на квм вместо дубовой связки ext4+ro.

А я Вам и не советовал :) Я персонально не очень к btrfs отношусь, ранее описывал - почему.

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

почему они утратили интерес?

1. При всей её надёжности я ощущаю btrfs как немного тормознутую, это не важно для моего локалхоста или проекта подобного RPI-KVM, но будет критично для RH.
2. Само появление btrfs выглядела как попытка спешно создать альтернативу ZFS, сейчас как тут в треде пишут RH собралось и делает более продуманную Stratis.

В конце концов по вашей же ссылке поясняется то, что в целом соответствует тому что тут говорю я:

Suse использует его по умолчанию и имеет большой внутренний опыт.
Мы используем его по-разному внутри Facebook.
Он становится быстрее и стабильнее, по общему признанию, медленнее, чем мне хотелось бы, но мы приближаемся к этому.
Это заявление Red Hat является отражением инженерного опыта Red Hat и того, как они поставляют ядра, а не обвинением самой Btrfs.

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

Ну, со своей стороны я могу добавить, что все сервера который я обслуживаю - полностью на RHEL и сидят :) Ни одного Дебиана, ни одного Сусе - нет.

Есть Oracle Linux, CentOS помимо RHEL, но это все родственное семейство. Посему все тесты я проводил тоже на RH-ориентированном семействе.

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

Я персонально не очень к btrfs отношусь, ранее описывал - почему.

Я действительно хотел бы видеть btrfs как наиболее зрелого представителя ФС нового поколения, но основная моя мотивация это: я не хочу ФС старого поколения типа EXTx и всей этой разбивки на то переполненные, то пустующие разделы, которые к тому же приводят к неравномерному износу блоков занимаемых теми или иными разделами.
Плюс у меня есть уже озвученные здесь притензии к ФС EXT3/4 как к таковым.

Если есть ещё одна ФС с изоляцией ошибок в конкретном субтоме, дублированным журналом и сквозным сжатием то вносите свои предложения.

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

что все сервера который я обслуживаю - полностью на RHEL и сидят :)

Если у вас старые ядра то там btrfs действительно не фонтан, мои восхищения btrfs относятся в основном к ядрам 4.х и моложе.

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

а бизнес как оценивает btrfs? оценивает ее баги, возможные проблемы в обслуживании с серверами?

Бизнес с самого начала предпочитает намного более взрывоопасную XFS.
Но я же не предлагаю btrfs под данные, я предлагаю её использовать под корень, а раздел с особоценными данными может использовать и другую ФС, но ведь главное в RPI-KVM таких особоценных данных просто нет.

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

а может btrfs плохая для PROD-площадок, где сплошником RAID’ы или дистрибутивный Ceph?

Я никогда не пользовался райдом в btrfs, я всегда делал настройку на дупликацию метаданных(сами данные я довольно быстро перестал дуплицировать так как btrfs оказалась достаточно надёжна, да и место лишним не будет.

И по очень старым слухам, которые от старости обратились в скелеты райд у btrfs действительно глючноват, но я его использовать не предлагаю, хватает и обычного -m dup

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

RAID-ы то не просто так используют… Один из частых моментов, к примеру, в дата-центре электричество на 5 минут вышло. И данные 5 минут могут потом стоить в то, что диски полетят. Это наиболее частая причина, почему подбирают RAID и более стабильные и проверенные временным файловые системы. Чтобы, после включения сервера обратно в работу, хотя бы один или два диска работали из 4-ех (если RAID-10), после подобного выхода из строя. Так же, чтобы можно было потом заказать новые диски и заменить поломанные в сервере.

Не знаю, почему Вы решили, что XFS - взрывоопасна. По мне так, совсем невзвроопасна, ибо с ней проблем как раз, таки и не было у меня в опыте эксплуатации. А вот, с ext4 || btrfs таки были.

Плюс, ранее присылал уже:

Although FileStore is generally capable of functioning on most POSIX-compatible file systems (including btrfs and ext4), we only recommend that XFS be used. Both btrfs and ext4 have known bugs and deficiencies and their use may lead to data loss. By default all Ceph provisioning tools will use XFS.

Думаю, что тоже не просто так указывают.

PS : ну и да, ес-но на ПРОДах мы не юзаем kernel v5.x , стабильность ядра - тоже не маловажный фактор. И 5-ое ядро, пока много кто не признают стабильным для ПРОД-систем.

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

Не знаю, почему Вы решили, что XFS - взрывоопасна.

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

По крайней мере XFS в стародавние времена описывали вот так и я не вижу причин как либо эту ситуацию менять сейчас, потому что таковы издержки большой скорости работы.
(Я к стати хотел на XFS себе систему для торрентов сделать, но потом решил использовать ZFS)
Хотя по новы слухам там много чего реализовали и она стала намного надёжнее и стабильнее.

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

Вообще, по скорости работы XFS процитирую след. информацию:

Metadata operations in XFS were slower compared to journaling file systems implemented later and designed to work with much larger logs resulting in, for example, slower performance with operations such as deletions of large numbers of files. However, a new XFS feature implemented by John Nelson and called delayed logging, available since version 2.6.39 of the Linux kernel mainline, is said to resolve this. Performance benchmarks done by the developer in 2010 revealed performance levels to be similar to ext4 at low thread counts, and superior at high thread counts.

Про то, что Вы говорите насчет «надолго откладывать запись», то это Вы явно про известный факт с fsync() вызовом с XFS.

НО! Большая часть буферизации выполняется на уровне VFS. Вы можете принудительно передать данные на следующий уровень (в случае XFS), выполнив сброс или установив синхронизацию диска. Да и никто не отменял тюнинг «write barrier» в Linux kernel. К примеру, выставив:

-o nobarrier

но, это при условии что у Вас - CentOS v7 условной с версией Linux kernel v3.x.x , т.к. насколько помню с v4.x.x какой-то версии nobarrier - вообще убрали. Можно еще с write cache поиграться:

echo «write through» > /sys/block/$device/queue/write_cache

Но, это уже можно долго обсуждать насчет оптимизаций для работы FS. Я пошел спать, Вам - спокойной ночи.

twinpeaks
()
Ответ на: комментарий от liksys

А почему мне не посоветовать то, что лично у меня очень хорошо работает?

Вы поинтересуйтесь что у btrfs делает опция commit и что означает то,то она у меня 3600, а потом сделайте выводы.

Хотя следует признать что несмотря на свои заверения я всё равно делаю тройной sync после обновлений и записи важных данных.

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

У меня очень простая позиция. Я не хочу использовать экспериментальные файловые системы там, где нужна надежность. Мне надостаточно заверения «у меня всё работает» на фоне отказа от нее RHEL и прочих неприятных историй.

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

тут просто часть людей отрицает то,то что файловые системы ext3 или ext4 могут и приводят к проблемам и приключениям

Конечно, отрицают. В проде крутят ext2/3/4 (я лично ext2, а также ext3/4 с момента их появления), никаких проблем.

zemidius
()
Ответ на: комментарий от torvn77

Это лично твое истории против историй RH и прочих эксплуататоров из продакшна. Железное решение ext4+ro лучше, чем надеяться на btrfs.

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

Смотри, мои оппонеты высококвалифицированные энтерпрайзные админы и как они говорят ФС EXT3/4 у них работает очень хорошо в условиях их интерпрайза с ИБП к которому подключены аккамуляторы очень большой мощности, но btrfs у них сопровождаются историями, та как видимо действительно что-то иногда происходит.

А теперь посмотри на меня, я не энерпрайзный админ и если спросить меня что за опция nodesize точного отвекта я тебе не дам.
И видимо по этому EXT файловые системы у меня приводят к сбоям, в то время как btrfs даже если и делает ошибки(предположим такое) то в любом случае способно перенести полное отсуктствие у меня более менее вменяемой квалификации.

И вот тут мы возращаемся к вопросу, для кого ты делаешь своё устройство?
Для энтерпрайзных админов чтобы они подключили к нему KVM свичи и использовали в как компонент своего энтерпрайза или ты делаешь устройство для домашнего энтузиаста, корый навыков админа может не иметь вообще?

Если ты делаешь устройства для энерпрайзных админов, то это точно нормально что ты предлагаешь им покупать плату без корпуса?
И на оборот, если ты делаешь своё устройство без корпуса для гиков и дилетантов, то точно разумно использовать на нём ФС ext3/4 с которой судя по треду умеет обращаться исключительно админы кровавого энтерпрайза и отказывать в использовании BTRFS, которая как раз способна переносить отсутствие квалификаций у простого человека, при том что мне как простому человеку будет удобнее современная ФС, из которых BTRFS наиболее проста в применении?
(ну ещё есть ZFS, вполне себе энтерпрайзная, и пока незавершённые F2FS и упомянутая здесь Stratis)

И если ты так уверен в EXT3/4 то почему хочешь ставить её в RO, я вот за BTRFS в режиме RW спокоен, особенно если настроить запуск тройного sync при завершении работы ОС и после установки обновлений.

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

RO надежнее RW - это аксиома. КВМ не должен иметь штатную возможность выдернуть его из розетки без предварительных синков и прочих плясок с бубном. А еще RO увеличивает время жизни флешки. И да, у меня ext4 не умирал просто так. Прямо скажем, вообще не умирал так, что не мог восстановиться. Поэтому модному и хипстеров btrfs+rw я предпочту старомодный дубовый ext4+ro.

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

Дурак

Посмотри в зеркало, тараканник.

если не делать тройной синк

«Безумие — это точное повторение одного и того же действия раз за разом в надежде на изменение»

Никогда не делал ни тройной, ни одинарный sync после записи важных данных, ничего не терял.

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

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

Где опечатка? )

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