Дано: Система с BTRFS, в которой 2 SSD диска склеены в RAID0 средствами самой ФС.
C момента установки работало без нареканий, вообще без единого.
Сегодня в процессе сборки тяжелого Android проекта все намертво повисло, пропал звук, 0 реакции на попытки перейти в tty / REISUB, в общем, ничего не оставалось кроме как сделать аварийное выключение.
В логах после перезагрузки не нашел абсолютно ничего, даже намёков на проблему, но интересует другое.
Если btrfs device stats и scrub status выдают вот такие данные, можно ли спать спокойно?
Концепцию CoW понимаю, но пляски с fsck в ext4 в прошлом дают о себе знать, да и вообще, аварийное выключение всегда воспринималось мною как крайне опасное мероприятие.
Т.е. верно ли я трактую идею, что максимум потерь - это данные, которые не успели записаться и остались в «старой версии» (абсолютно не критично, поскольку это была сборка) и второй момент, что могли потеряться данные в очереди на запись, которые висели в кэшах оперативной памяти?
➜ ~ sudo btrfs device stats / && sudo btrfs device stats /home
[/dev/nvme1n1p2].write_io_errs 0
[/dev/nvme1n1p2].read_io_errs 0
[/dev/nvme1n1p2].flush_io_errs 0
[/dev/nvme1n1p2].corruption_errs 0
[/dev/nvme1n1p2].generation_errs 0
[/dev/nvme0n1p1].write_io_errs 0
[/dev/nvme0n1p1].read_io_errs 0
[/dev/nvme0n1p1].flush_io_errs 0
[/dev/nvme0n1p1].corruption_errs 0
[/dev/nvme0n1p1].generation_errs 0
[/dev/nvme1n1p3].write_io_errs 0
[/dev/nvme1n1p3].read_io_errs 0
[/dev/nvme1n1p3].flush_io_errs 0
[/dev/nvme1n1p3].corruption_errs 0
[/dev/nvme1n1p3].generation_errs 0
[/dev/nvme0n1p2].write_io_errs 0
[/dev/nvme0n1p2].read_io_errs 0
[/dev/nvme0n1p2].flush_io_errs 0
[/dev/nvme0n1p2].corruption_errs 0
[/dev/nvme0n1p2].generation_errs 0
➜ ~ sudo btrfs scrub status / && sudo btrfs scrub status /home
UUID: 6dbfff5e-02c9-4f4e-aed7-c9e20424076b
Scrub started: Tue Feb 17 17:24:50 2026
Status: finished
Duration: 0:00:02
Total to scrub: 15.40GiB
Rate: 7.70GiB/s
Error summary: no errors found
UUID: c589e670-abd1-4b5f-bd59-92bdcc418313
Scrub started: Tue Feb 17 17:24:56 2026
Status: finished
Duration: 0:01:00
Total to scrub: 583.55GiB
Rate: 9.70GiB/s
Error summary: no errors found
Каюсь, в администрировании Linux систем не силён, постараюсь описать ситуацию максимально подробно.
Дано: Домашний сервер, в роли которого выступает мини-пк, на нём запущено множество Docker контейнеров с нужными мне сервисами (Immich, Jellyfin, Cgit, etc).
Всё это работает 24/7@365, недавно, спустя около 60 дней аптайма обнаружил систему в полностью зависшем состоянии.
Покурив мат. часть я понимаю что произошло, первопричина вне моего контроля, но вопрос вот в чем: Есть ли способы автоматического восстановления сервера при возникновении таких ситуаций?
Поскольку сейчас есть 2 проблемы:
Приходится делать hard reset
Я не всегда физически рядом с этим сервером, чтобы нажать кнопку.
Буду признателен за любую полезную информацию по теме.
Вопрос, наверное, странный, но однозначного ответа я на него найти не смог.
Дано: Рабочая станция, которой через несколько месяцев будет 5 лет с момента сборки. К самой станции у меня абсолютно 0 вопросов и ровно столько же причин думать об апгрейдах или заменах.
Все 5 лет в системе стоит необслуживаемая водянка от ASUS (ROG STRIX LC 360 RGB).
И вот в один из вечеров посетила меня паранойя: А какой у них срок службы и надо ли их менять со временем, чтобы оно не протекло? (и может ли оно протечь)
Раз в несколько месяцев система чистится от пыли, визуально криминала не видно. Температуры тоже держатся в пределах допустимых. Из стресса для железа - системник пережил поездку поездом Уфа -> Москва, но это было год назад и с тех пор ничего замечено не было.
Т.е. объективных причин для замены буд-то бы нет, но доля страха и шизы присутствует.
С момента моей последней фотографии в галерее прошло почти 5 лет. Что-то поменялось, что-то осталось неизменным.
Давайте по порядку.
Прежде всего, я искренне считаю, что удалённая работа – это лучшее, что происходило с рынком труда.
За эти 5 лет я окончательно переехал из Уфы в Москву и тратить по 3 часа в день на дорогу (в обе стороны), чтобы выполнить работу, которую я могу с таким же успехом сделать сидя дома – это просто глупость, как по мне. А протирать штаны и создавать иллюзию бурной деятельности можно и в офисе. Наличие в нём сотрудника вовсе не говорит о том, что он делает что-то полезное.
Привет, ЛОР.
У меня вопрос такого плана.
У ArchLinux есть грейды зеркал (Tier 1 / Tier 2), описаны в Wiki, и дают своего рода гарантии по скорости попадания в них изменений.
Сейчас их досят, инфраструктура лежит уже недели 2, но это половина беды, у меня уже несколько месяцев развернуто свое зеркало арча, раньше я всегда синхронизировался с repository.su (Tier 1), но последнее время и он начал сбоить, переехал на mirror.yandex.ru, по скорости и стабильности стало сильно лучше, но у него статус Untiered (https://archlinux.org/mirrors/yandex.ru/).
Вопрос: Чем это может быть чревато?
Визуально из отличий вижу только несколько лишних директорий от самого Яндекса, в остальном, вроде бы, все тоже самое (https://mirror.vsulimov.com/archlinux/).
Они ведь из-за средств проверки подписи в pacman не могут пакеты подменять на что-то невалидное?
Привет, ЛОР.
Достаточно долго у меня существует следующая конфигурация:
Все данные (~2 TB) лежат на одном NAS, раз в неделю они бэкапятся на внешний HDD (все диски Enterprise уровня, не черепичные, так что тут все ок), а все клиенты получают к ним доступ по nfs/smb.
И все прекрасно, за исключением того, что нет offsite бэкапа с т.з. географического расположения.
Есть идея взять облако и зеркалировать туда, но переход на NAS и локальное хранение были в первую очередь обусловлены приватностью и безопасностью, поскольку среди этих данных есть критически важные (базы с паролями, исходники, и т.д.).
Собственно, вопрос: Какие есть самые адекватные и надежные способы безопасно хранить снимки диска в шифрованном виде в облаке?
Привет, ЛОР.
Помогите, пожалуйста, решить проблему.
Дано: Сервер в локальной сети, который подключен к NAS и на нем поднят MPD.
Конфиг MPD следующий
music_directory "/var/lib/mpd/music"
playlist_directory "/var/lib/mpd/playlists"
db_file "/var/lib/mpd/database"
log_file "/var/log/mpd/mpd.log"
pid_file "/var/run/mpd.pid"
state_file "/var/lib/mpd/state"
sticker_file "/var/lib/mpd/sticker.sql"
audio_output {
type "httpd"
name "My HTTP Stream"
encoder "vorbis"
port "8800"
bitrate "128"
format "44100:16:1"
always_on "yes"
tags "yes"
}
На клиенте в локальной сети использую ncmpcpp с параметром -h ip:port.
К серверу подключается, библиотеку видит, но звука при воспроизведении нет, равно как и в Volume плеера указано n/a.
На клиентской системе ArchLinux + PipeWire.
Подскажите, пожалуйста, что я делаю не так?
Что хочется: Сделать для разделов / и /home RAID0 на второй диск (сейчас он вообще голый, сносил все через nvme format).
Подскажите, пожалуйста, как правильно достичь желаемого?
Зеркалирование в данной конфигурации не нужно, все важные данные у меня лежат на NAS и блинах, нужна только скорость от RAID0 из-за второго физического диска.
Есть следующая железная конфигурация.
APC UPS, Synology NAS (который ретранслирует события UPS в локальную сеть) и множество клиентов, которые эти события слушают через nut (mode=netclient).
Сервер корректно завершает свою работу, а вот с рабочей станцией возникли трудности.
Скрипт, который пытаюсь выполнить при переходе в режим ONBAT, выглядит вот так
#!/bin/sh
echo "UPS is on battery, initiating immediate shutdown" | logger
/usr/bin/systemctl poweroff
Однако, все заканчивается ошибкой в логах journalctl
Call to PowerOff failed: Interactive authentication required.
Привет, ЛОР.
Заранее извиняюсь за лютый оффтоп, но нужна помощь.
Дано: Система с 2-мя физически разными SSD.
Один полностью отдан под Linux, другой полностью отдан под Windows.
Раньше на диске с Linux стоял KDE Neon, и его загрузчик позволял грузить Windows (причем не помню, чтобы я особо что-то делал для этого), сейчас я переехал на Arch и возникла проблема.
Systemd-boot на диске с Arch про Windows ничего не знает, EFI не позволяет выбрать диск с Windows, он там загрузчика вообще не видит, судя по всему, вопрос: Как правильнее всего это дело оживить?
Привет, ЛОР.
Столкнулся с не очень понятным сообщением при попытке обновить KDE Neon штатными средствами
sudo pkcon refresh && sudo pkcon update
Выдает следующее
vsulimov@workstation:~$ sudo pkcon update
Getting updates [=========================]
Finished [=========================]
Testing changes [=========================]
Finished [=========================]
Fatal error: The following packages have unmet dependencies:
neon-desktop: Depends: powerdevil but it is not going to be installed
Recommends: neon-boot-space but it is not installable
Подскажите, пожалуйста, как это трактовать и как это чинить?
Привет, ЛОР.
Заранее попрошу сильно не бить, поскольку являюсь front-end разработчиком и в тему серверов полез впервые.
Возник вопрос/проблема следующего плана.
Есть VPS со статическим IP. На нём много чего держится, но по большей части это VPN туннели.
Есть docker образ, в котором развернут cgit, он висит на отдельном порту и к нему сейчас можно получить доступ по ссылке вида http://vps_ip:port/cgit.
Есть доменное имя, купленное у RU-CENTER.
Есть бесплатный DNS от CloudFlare.
Я хочу скрестить все это воедино, но пока не очень понимаю как.
Запись DNS в CloudFlare позволяет делать связку из domain name -> IPv4, но мне нужен еше сторонний порт и путь.
В общем, вопрос, как это делают нормальные люди и в какую сторону копать?
Привет, ЛОР.
У меня сейчас есть личные сервисы развернутые локально (NAS, Git-Server, CalDAV), для доступа к ним за пределами локальной сети используется WireGuard (сервером выступает роутер Keenetic).
Однако, возникла потребность вывесить наружу сервисы, которые должны быть доступны всем (Простой Web Server с одностраничным сайтом, cgit с репозиториями).
У меня в принципе жуткое непринятие стандартных решений и вся моя инфраструктура self-hosted, насколько возможно.
В роли сервера будет выступать мини-пк, который работает 24/7 с Ubuntu Server на борту, доменное имя есть, статический IP тоже, вопрос в следующем: Насколько безопасно торчать всему этому в мир и какие правила безопасности обязательно стоит соблюсти?
Да, немного оффтоп, но хочется прям максимально странного.
Дано: Рабочая машина в виде MacBook Pro, на которой стоит Cisco AnyConnect, хочется иметь возможность прокидывать его через WireGuard, чтобы цепляться с Linux за этот туннель и иметь доступ к ресурсам, которые этим самым Cisco закрыты.
Ставить это проприетарное ненужно на свою систему нет никакого желания, попробовал сделать в лоб, поднял на macOS WireGuard сервер, зацепился за него, пинговаться пингуется, но все то что закрыто Cisco через такой туннель недоступно.
Привет, ЛОР.
Начал изучать Rust, за плечами 10 лет разработки на Java/Kotlin, так что в теме не зеленый, но вопрос возник очень примитивный.
Смотрим книгу по типам данных, там написано следующее.
Let’s say you have a variable of type u8 that can hold values between 0 and 255. If you try to change the variable to a value outside that range, such as 256, integer overflow will occur, which can result in one of two behaviors. When you’re compiling in debug mode, Rust includes checks for integer overflow that cause your program to panic at runtime if this behavior occurs. Rust uses the term panicking when a program exits with an error; we’ll discuss panics in more depth in the “Unrecoverable Errors with panic!” section in Chapter 9.
When you’re compiling in release mode with the --release flag, Rust does not include checks for integer overflow that cause panics. Instead, if overflow occurs, Rust performs two’s complement wrapping. In short, values greater than the maximum value the type can hold “wrap around” to the minimum of the values the type can hold. In the case of a u8, the value 256 becomes 0, the value 257 becomes 1, and so on. The program won’t panic, but the variable will have a value that probably isn’t what you were expecting it to have. Relying on integer overflow’s wrapping behavior is considered an error.
Читая прямо и в лоб, если собираем в debug - упадем в panic, если в релизе - получим 0/1/2, в зависимости от того, насколько вышли за границы u8.
А теперь практика.
fn main() {
let mut number: u8 = 255;
number += 1;
}
Вот этот код не собирается, ни в debug, ни в release, ошибка компилятора следующая
error: this arithmetic operation will overflow
--> src/main.rs:3:5
|
3 | number += 1;
| ^^^^^^^^^^^ attempt to compute `u8::MAX + 1_u8`, which would overflow
|
= note: `#[deny(arithmetic_overflow)]` on by default
Однако, стоить добавить всего одну строчку к этому коду
fn main() {
let mut number: u8 = 255;
number += 1;
println!("The number is: {number}");
}
И поведение программы соответствует описанному в книге, собственно, вопрос: Почему вызов println! так влияет на это?
В первом случае оно даже не собирается и overflow ловится на этапе компиляции, но стоит добавить println! и все начинает работать совсем иначе.
Дошли у меня руки наконец-то организовать себе NAS и уйти от облачных решений.
Основная проблема была в том, что у меня в ходу все 3 ОС и нет адекватного универсального решения + фотографии с телефона/фотоаппарата/плюшки в виде возможности смотреть видео с любого устройства в локальной сети и т.д.
Взял Synology DS223j и HDD на 4ТБ enterprise уровня (SEAGATE Exos 7E10).
Настроил, все прекрасно, летает-работает-монтируется по nfs через fstab, но, в текущей конфигурации это решение абсолютно не отказоустойчивое, а это для меня критически важный показатель, поскольку там лежат все данные, от оцифровок кассет 1996 года до сегодняшних дней.
Соб-но, полез гуглить и понял, что RAID сам по себе не является заменой бэкапов (если докинуть один диск и начать его зеркалить).
Потому у меня вопрос: Как лучше поступить в данной ситуации, чтобы получить максимально отказоустойчивую систему на случай непредвиденных ситуаций?
У меня в голове 2 варианта:
Все таки RAID (взять еще один идентичный диск и слепить их в зеркало)
Взять внешний HDD на 4 ТБ и бекапиться средствами Synology раз в n дней.
По второму крайне смущает отсутствие у внешних накопителей S.M.A.R.T., нет возможности узнать о неисправностях диска, если таковые будут, первое, почему-то, в интернете тоже особо надежным не считают, в общем, дискасс.
