При скачивании мой антивирус наглухо заблокировал файл **Setup.exe**. Вердикт: `Trojan:Win32/Yomal!rfn`.

"Да это просто ложная тревога на взлом!" (Нет)

Обычно модераторы любят писать: «Антивирусы просто не любят пиратки». Но эта отмазка здесь не работает: я проверил другие репаки этой же игры от других команд — они абсолютно чистые, и этот вирус там не обнаруживается. Детект вылезает только здесь.

https://www.virustotal.com/gui/file/c0fed932467f41b56da6aabbd2d97f9a712d54b4dfea99946069d529b95835a2/detection

Но самое интересное вскрылось во вкладке Community, где висят технические отчёты систем анализа безопасности:
1. В инсталлятор зашит код хакерской утилиты **reGeorgTunnel**. Её используют для поднятия скрытых туннелей. Проще говоря, этот Setup.exe превращает ваш ПК в прокси-сервер, через который посторонние люди могут анонимно гонять свой левый трафик.
2. Песочница FileScan.io дала оценку опасности: 100 из 100. Вирус вовсю пытается скрываться от отладчиков (anti-debug) и ломится на левые домены `eng.city` и `rus.city`.

Я создал официальную жалобу, расписал пруфы. Мне отвечает модератор **NorthOn**: *«Жалоба отклонена. Это Riskware.Repack. Список антивирусов не любящих репаки по ссылке...»*

Знаете, что сделал модератор?

Из 16 ругающихся антивирусов только ОДИН (Webroot) выдал мягкую плашку "Riskware.Repack". Модератор просто скопировал этот единственный удобный вердикт, проигнорировал все предупреждения про трояны и закрыл тему, чтобы защитить статус своего коллеги-куратора.
Я попытался написать ему в ЛС: *"Дружище, посмотри вкладку Community, там код для кражи трафика reGeorg, в других репаках этого вируса нет, куратор просто скопировал зараженный файл из сети"*.
Итог? МГНОВЕННЫЙ ВЕЧНЫЙ БАН. Меня просто отрезали от форума, чтобы не мешал.

Самое циничное, что на страницах трекера сейчас изо всех сил рекламируют и продвигают VPN-сервис "Впринципе" (vprintsipe.com). Получается потрясающий парадокс: на главной странице вам активно советуют инструменты для приватности и сетевой безопасности, а в это же время в топ-раздачах кураторов сидит сетевой бэкдор, и за попытку сообщить о нём модераторы выдают банхаммером по лицу.

В общем, ребята, проверяйте файлы перед установкой и не отключайте защитники по первому требованию форумных администраторов. Свою систему от этого репака я очистил, а вам советую обходить подобные раздачи стороной. Всем безопасности!

# Добавляем репозиторий apt.bcachefs.org (unstable / bcachefs-tools-release) и затем ставим всю обвязку

sudo apt install bcachefs-tools bcachefs-kernel-dkms fio btrfs-progs

По итогу получаем собранный модуль (bcachefs.ko.zst версии 1.38.6), и dmesg ожидаемо сыплющий ворнингами про tainting kernel и verification failed. Ну это просто надо иметь ввиду - теперь вы живете на внешнем модуле, и при каждом обновлении ядра нужно будет пристально следить за DKMS.

bcachefs: loading out-of-tree module taints kernel

bcachefs: module verification failed: signature and/or required key missing - tainting kernel

bcachefs: filldir64 fastpath disabled: struct layout unverified for this kernel

2. Базовый single-disk сценарий

Первый тест был максимально тупой и прямолинейный:

1. Создать ФС на одном диске.

2. Смонтировать.

3. Записать файл 1 GiB и 5000 мелких файлов.

4. Запустить usage/scrub.

5. Размонтировать и выполнить offline check.

Для Bcachefs:

sudo bcachefs format -f -L bcf_single /dev/sdb

sudo mount -t bcachefs -o noatime /dev/sdb /mnt/bcf

sudo bcachefs fs usage -h -a /mnt/bcf

sudo bcachefs scrub /mnt/bcf

sudo bcachefs fsck -n -f /dev/sdb

Для Btrfs:

sudo mkfs.btrfs -f -L btr_single /dev/sdc

sudo mount -t btrfs -o noatime /dev/sdc /mnt/btr

sudo btrfs filesystem usage -T /mnt/btr

sudo btrfs scrub start -B /mnt/btr

sudo btrfs check --readonly /dev/sdc

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

Можно еще отдельно сказать про команды Bcachefs. Они непривычны, но в целом на удивление логичны: вместо mkfs.bcachefs используется bcachefs format, диагностика идёт через bcachefs fs usage, проверка через bcachefs fsck.

3. Сжатие

Для проверки сжатия использовал простой набор:

1. zero-512m.bin, 512 MiB нулей.

2. random-256m.bin, 256 MiB случайных данных.

Bcachefs создавалась сразу с zstd:

sudo bcachefs format -f -L bcf_zstd --compression=zstd /dev/sdb

Btrfs монтировалась с compress=zstd:

sudo mount -t btrfs -o noatime,compress=zstd /dev/sdc /mnt/btr

У Bcachefs понравилась отдельная секция в fs usage:

Итоговое использование места:

Bcachefs - около 283 MiB

Btrfs - около 274 MiB

Обе ФС отработали отлично (нули сжали, рандом пропустили). Разница в несколько мегабайт тут не имеет особого смысла.

Из интересного - у Bcachefs утилита fs usage выдает шикарную и очень наглядную статистику по сжатым/несжимаемым данным прямо в консоль.

4. Снапшоты

Снапшоты проверял простым бытовым сценарием:

1. Создать subvolume.

2. Записать state.txt со значением original.

3. Создать read-only snapshot.

4. В живом subvolume поменять файл на changed.

5. Прочитать файл из snapshot.

Bcachefs:

bcachefs subvolume create /mnt/bcf/subv

bcachefs subvolume snapshot -r /mnt/bcf/subv /mnt/bcf/snap1

Btrfs:

btrfs subvolume create /mnt/btr/subv

btrfs subvolume snapshot -r /mnt/btr/subv /mnt/btr/snap1

Результат у обеих ФС одинаковый:

live=changed

snapshot=original

Здесь ноль сюрпризов. Снапшоты работают так, как от CoW-ФС и ожидаешь.

5. Производительность fio и мелкие файлы

Теперь к цифрам. Ещё раз: это синтетические тесты внутри одного сомнительного стенда.

Параметры fio:

single disk

без сжатия

sequential read/write: bs=1M, size=2G

random write: bs=4k, numjobs=4, iodepth=16, runtime=30

Первые три строки ниже - это fio. Создание и удаление 10000 мелких файлов замерялись отдельно обычным shell-сценарием: создание дерева файлов и последующий rm -rf этого дерева.

Результаты:

На этом стенде Bcachefs заметно быстрее на последовательной записи, random write 4K и создании мелких файлов. Btrfs, наоборот, быстрее на последовательном чтении и чуть быстрее удаляет дерево мелких файлов.

Само собой всё это автоматически не приводит нас к выводу, что Bcachefs быстрее Btrfs. Всё таки подложка в виде Proxmox/ZFS может сильно влиять на такие цифры. Но как лабораторный результат - как минимум любопытно.

Отдельный нюанс: во время нагрузки у Bcachefs в dmesg появилась строка:

bcachefs (sdb): bch2_journal_flush_seq stuck? Waited 10s for seq 32

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

6. Multi-device

Одна из причин вообще смотреть на Bcachefs - обещание функциональности уровня современных CoW-ФС с более гибкой моделью устройств.

Bcachefs с двумя копиями данных и метаданных создаётся так:

bcachefs format -f -L bcf_raid1 --replicas=2 /dev/sdb /dev/sdc

После записи 512 MiB полезной нагрузки bcachefs fs usage показал ожидаемую репликацию:

Btrfs RAID1 создавался привычно:

mkfs.btrfs -f -d raid1 -m raid1 -L btr_raid1 /dev/sdb /dev/sdc

У него всё ожидаемо отображается через Data ratio: 2.00 и Metadata ratio: 2.00.

Нюанс в терминологии: у Bcachefs модель --replicas=2 читается проще. Мы описываем желаемое количество копий, а не выбираем отдельные RAID-профили для data и metadata. Для админа это вполне приятная деталь.

7. Потеря диска на живую

Ну и само собой важная часть для любой multi-device ФС нифига не красивая таблица fio, а поведение при отказе.

Сначала пробовал имитировать отказ изнутри гостевой ОС через /sys/block/*/device/delete и device/state=offline. В этой ВМ метод оказался ненадёжным: устройство либо оставалось видимым, либо состояние быстро возвращалось в running.

Поэтому финальный тест делал через QMP hot-unplug на уровне Proxmox/QEMU. Постоянную конфигурацию ВМ не менял, удалял только live-устройство.

Bcachefs

Сценарий:

1. Bcachefs на /dev/sdb и /dev/sdc.

2. Форматирование с --replicas=2.

3. Запись 256 MiB payload.

4. QMP device_del scsi2, то есть удаление второго диска.

5. Проверка чтения старого файла и запись нового файла.

После hot-unplug /dev/sdc исчез из lsblk. Чтение и запись продолжили работать:

/mnt/bcf/payload.bin: OK

-rw-rw-r-- 1 user user 20 ... /mnt/bcf/after-qmp-hotunplug.txt

Диагностика Bcachefs показала, что часть метаданных уже требует восстановления реплик:

В dmesg появились ожидаемые ошибки по удалённому устройству:

bcachefs: error writing btree node ... sdc io: BLK_STS_OFFLINE

bcachefs (sdc): offline from block layer

bcachefs: error writing btree node ... sdc io: BLK_STS_REMOVED

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

Btrfs

Для Btrfs аналогичный сценарий делал на другой паре дисков:

1. Btrfs RAID1 на /dev/sdd и /dev/sde.

2. Так же запись 256 MiB payload.

3. QMP device_del scsi4.

4. Проверка чтения и запись нового файла.

После удаления /dev/sde ФС тоже продолжила работать:

/mnt/btr/payload.bin: OK

-rw-rw-r-- 1 user user 20 ... /mnt/btr/after-qmp-hotunplug.txt

btrfs filesystem usage -T показал missing device:

WARNING: failed to get device size for /dev/sde: No such file or directory

Device missing: 20.00GiB

В dmesg появились ошибки записи на удалённое устройство:

BTRFS error (device sdd): bdev /dev/sde errs: wr 1, rd 0, flush 0, corrupt 0, gen 0

BTRFS warning (device sdd): lost super block write due to IO error on /dev/sde (-5)

BTRFS error (device sdd): error writing primary super block to device 2

В этом конкретном сценарии обе ФС повели себя адекватно: RAID1-подобная конфигурация пережила потерю одного диска на живую, данные остались читаемыми, запись продолжилась.

8. Что там по UX

Понравилось в Bcachefs:

1. bcachefs fs usage -h -a очень информативен.

2. Хорошо видно data/metadata, compression, btree и состояние устройств.

3. Модель --replicas=2 читается проще, чем отдельные профили -d raid1 -m raid1.

4. Снапшоты и subvolume-команды выглядят логично.

5. Потерю одного устройства при репликации ФС пережила.

Минусы:

1. Вместо нормальной поставки в составе ядра - поставляется как DKMS-модуль со всеми вытекающими (вообще надо было постараться настолько сильно выбесить мейнтейнеров ядра своим стилем разработки, чтоб тебя со скандалом вып*здили из mainline)

2. В dmesg был warning про bch2_journal_flush_seq stuck.

3. Сценарий возврата или замены диска после hot-unplug надо тестировать отдельно.

У Btrfs главный плюс скучный, но весомый: он давно есть в дистрибутивах, хорошо документирован, привычен и в принципе практически стабилен.

Итоги

1. Bcachefs после снятия experimental уже имеет смысл тестировать в homelab.

2. В базовых сценариях ФС отработала нормально: создание, монтирование, scrub/fsck, сжатие, снапшоты, multi-device.

3. На этом стенде Bcachefs хорошо выступила на записи и мелких файлах, но это синтетические тесты.

4. Потерю одного диска при --replicas=2 Bcachefs пережила: данные читались, запись продолжалась, диагностика показала деградацию.

Если резюмировать, то основные вопросы пока не столько к самой ФС, сколько к эксплуатационной обвязке: DKMS, обновления ядра, загрузка модуля и восстановление после отказов.

ИМХО, для лаборатории, тестового NAS, домашнего стенда и удовлетворения инженерного любопытства - да, Bcachefs уже интересно гонять. Для продакшена или единственной копии важных данных - только после собственных аварийных тестов и с нормальными бэкапами.

Столица встретила сурово, но справедливо. Нужно было за что-то цепляться, чтобы банально не остаться на улице и отбивать аренду жилья. С того же 2023 года я устроился работать в охрану. Это была понятная, стабильная работа, которая дала мне главное — передышку. Я закрепился в Москве, встретил будущую жену (которая сейчас поддерживает меня на все 100%), обустроил быт. Нашел свой островок стабильности.

Но вот в чем фокус: охрана — это отличный плацдарм, чтобы не умереть с голоду, но худшее место, если ты хочешь развиваться. Уже три года сидя на объекте, я вижу, как мир технологий летит вперед, а я просто продаю свое время, деградируя под монотонный шум рации.

Короче, меня переклинило. Назад в Удмуртию и к алкогольному анабиозу я не вернусь. Охранять чужие двери до пенсии — не хочу. Мозг требует жестких, сложных задач. Я выбрал системное администрирование.

Мне уже успели наговорить классического дерьма: "Куда ты лезешь в 27?", "В IT уже поздно" , "Рынок джунов мертв". Послушал, сделал выводы и забил болт. Когда ты в 25 лет на морально-волевых выбирался из алкогольной ямы и менял регион, разбивать стены лбом становится привычкой.

План у меня суровый и без иллюзий. Никаких дорогих инфоцыганских курсов. Закупаю б/у железо на Авито, прокачиваю свой ноут (на днях полностью перебрал его, выкинул высохшую пасту, накатил фазовый переход Honeywell, чтобы он не расплавился), докупаю оперативку до 32 ГБ и разворачиваю домашнюю лабораторию на виртуалках.

Мой дедлайн — середина ноября. До этого момента я жестко ботаю сети, Active Directory, Linux, Windows Server и автоматизацию. В ноябре — открываю резюме и иду штурмовать собесы до победного оффера.

Этот путь я решил фиксировать в реальном времени. Без нытья и без прикрас — со всеми техническими затыками, факапами и первыми победами. Создал для этого ламповый Телеграм-канал, где буду выкладывать отчеты по лабам и шагам: https://t.me/iz_ohrany_v_it

Если ты сейчас сидишь на вахте, на складе, за баранкой такси или на КПП и думаешь, что твоя жизнь кончена — подписывайся, будем пробивать эту стену вместе. Погнали.

Пересечение двух файлов (ключ - NR==FNR работает только для первого файла):

awk 'NR==FNR {lut[$0]=1; next} $0 in lut {print}' FILE1 FILE2

Разность - заменить условие на !($0 in lut). Объединение - просто cat + uniq.

Важно: условие $0 in lut лучше, чем lut[$0], - последний при промахе создаёт пустые элементы массива и жрёт память на больших файлах.

Производительность:
- LC_ALL=C awk '...' - отключает Unicode, иногда даёт большой буст
- mawk вместо GNU awk - значительно быстрее