Современные файловые системы Linux
 
Выбор файловой системы в Linux может оказаться сложной задачей для новичка. На что смотреть? На тесты и бенчмарки, которые проводятся на пустом SSD и не отражают реальность?
 
Сегодня мы коротко  разберем актуальный квартет: ext4, XFS, Btrfs и ZFS, подсветив все их основные плюсы и минусы.
 
1️⃣ ext4: Проверенная временем классика
 
Это классическая блочная журналируемая ФС с записью «на месте» (In-place update). Максимальная стабильность, предсказуемость и надежность, минимальное потребление ресурсов CPU и RAM. Все это проверено десятилетиями.
 
Но это именно классическая ФС и если вы хотите снапшоты, пулы, сжатие и проверку целостности – ничего этого нет.
 
Есть еще «родовая травма»  - таблица индексных дескрипторов (inodes) размечается один раз на этапе форматирования и впоследствии изменена быть не может.
 
Если диск используется под сценарии с миллионами крошечных файлов (почтовый сервер с Maildir, кэш аватарок веб-сервера, мелкие сессии, очереди задач), наступает классический парадокс: свободное место есть , а записать файл нельзя.
 
2️⃣ XFS: Enterprise-стандарт
 
XFS - 64-битная высокомасштабируемая журналируемая ФС с аллокацией по экстентам (extents) и разделением пространства на независимые группы размещения (Allocation Groups).
 
Обеспечивает высокую производительность при параллельной многопоточной записи/чтении и работе с крупными файлами (видео, дампы, медиа).
 
Дефолтная ФС в enterprise-дистрибутивах (RHEL / Rocky / AlmaLinux).
 
Но есть и достаточно серьезные недостатки - раздел XFS нельзя уменьшить, вообще никак: система XFS умеет расти (xfs_growfs), но архитектурно не умеет уменьшаться.
 
А далее имеем классический случай, на смену одним дискам на 1 ТБ (честный двоичный байт 2^40 = 1024 ГБ) купили маркетинговый «терабайт»  (10^12  байт ~ 931 ГиБ). И что? И все, приехали.
 
3️⃣ Btrfs: «Спасение» силами гигантов индустрии
 
На заре своего появления (конец 2000-х / начало 2010-х) Btrfs имела репутацию крайне нестабильной, «сырой» и опасной системы. Она регулярно теряла данные при падениях питания, страдала от критических багов в аллокаторе свободного места, а алгоритмы RAID5/6 были в целом неработоспособные.
 
Red Hat со временем и вовсе официально признала Btrfs устаревшей (deprecated в RHEL 7.4) и полностью вырезала её поддержку в RHEL 8, сделав будущее этой ФС очень туманным.
 
Поворотным моментом стал приход в Meta* новой команды инженеров (Крис Мейсон, Йозеф Бачик и прочие). Они переписали и довели до ума самые проблемные места, код работы со свободным пространством, асинхронную очистку, сжатие ZSTD и интеграцию с механизмами ядра Linux.
 
В итоге это превратило вечную «бета» в надежную систему, которая используется по умолчанию для SUSE и Fedora.
 
4️⃣ ZFS: Монолитная СХД в одном флаконе
 
Это не просто ФС, а связка: файловая система + менеджер томов + RAID  с пулом накопителей и легкими датасетами. Полный сквозной контроль целостности: контрольные суммы на каждый блок, самовосстановление, снапшоты, репликация и собственный кэш ARC в RAM.
 
Но за это все приходится платить, в первую очередь высокими требованиями к RAM и высоким коэффициентом WAF (что характерно для всех CoW систем).


Хотя в грамотных руках это того стоит, вы получаете очень гибкое, настраиваемое и масштабируемое хранилище корпоративного уровня.
 
Выводы:
 
🔹Нужна железобетонная стабильность «поставил и забыл»? ext4.

🔹Высокие параллельные нагрузки, базы или огромные файлы без нужды сжимать раздел? XFS.

🔹Десктоп, снапшоты системы перед апдейтом и сжатие на лету? Btrfs.

🔹СХД, отказоустойчивые пулы, виртуализация и контроль целостности? ZFS.

* Meta признана экстремистской организацией в России.

Подключаем диск из NAS в Linux, или монтирование RAID и LVM разделов

Всем нам знакомы и привычны аппаратные NAS, они используются дома и на работе для хранения самых различных данных. Но любое оборудование может выходить из строя, обычно неожиданно и перед администратором может встать задача копирования данных с дисков NAS.

На первый взгляд в ней нет ничего сложного: в основе прошивки Linux, а значит берем любую Linux систему, подключаем, монтируем, сливаем...

Однако не все так просто и для выполнения этой задачи могут потребоваться достаточно глубокие знания систем хранения Linux и навыков работы с ними.

Разбирать подобные ситуации лучше на примерах, тем более в нашем случае он как будто специально, достаточно показательный.

На днях к нам обратился коллега с просьбой помочь достать информацию с диска, вышедшего из строя NAS Synology DS216. На наш вопрос в чем там проблема он уклончиво ответил, что как-то все сложно и он боится сделать что-нибудь не так и испортить данные.

Ну что же, давайте разбираться. Итак, перед нами следующие вводные: есть диск из двухдискового NAS, работавшего с зеркальным RAID-массивом, в качестве файловой системы использовалась ext4.

✅ Читать далее: https://interface31.ru/post/podklyuchaem-disk-iz-nas-v-linux-ili-montirovanie-raid-i-lvm-razdelov/

Как изменить SID в Windows 10/11 и Server 2025

О проблеме дублирующихся SID мы писали в нашей прошлой заметке, сегодня расскажем о том, как изменить его без переустановки системы.

❗️Важно! Данный способ является неофициальным и потенциально может привести к нарушению работы системы и/или потере информации. Поэтому все действия вы производите исключительно на свой страх и риск!

Для работы мы будем использовать утилиту SIDCHG, которую следует скачать с официального сайта, там же расположен лицензионный ключ пробной версии, который представлен в качестве изображения и меняется каждый месяц, на октябрь 2026 года ключ такой:

77JAY-XcFfv-2OiLw-2f

После чего узнайте текущий SID машины, например, при помощи PsGetsid64 от Sysinternals.

‼️ Если система использует BitLocker (а Windows 11 использует его по умолчанию), то шифрование нужно отключить, а диски расшифровать.

Статус можно узнать командой:

manage-bde -status C:

Отключить:

manage-bde -off C:

Если дисков несколько – повторить для каждого, после чего следует дождаться процесса расшифровки и перезагрузить ПК.

‼️ Если вы используете EFS, то скопируйте зашифрованные файлы в другое место, а также не забудьте экспортировать сертификат с ключами.

Будьте готовы к тому, что некоторое программное обеспечение может потребовать повторной активации.

🔹 Затем отключите службу UCPD — это User Choice Protection Driver

sc config UCPD start=disabled 
schtasks.exe /change /Disable /TN "\Microsoft\Windows\AppxDeploymentClient\UCPD velocity"

Перезагрузитесь, иначе защита полноценно отключена не будет.

Выключите онлайн-защиту антивируса, включая Defender и запустите скачанную утилиту с ключом R:

SIDCHG64.exe /R

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

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

schtasks.exe /change /Enable /TN "\Microsoft\Windows\AppxDeploymentClient\UCPD velocity"
sc config UCPD start=auto

После чего убедитесь, что SID действительно изменился.

👉 В некоторых случаях могут начать нестабильно работать современные приложения и меню Пуск, в этом случае нужно выполнить сброс их настроек, для этого снова запустите утилиту:

SIDCHG64.exe / RESETALLAPPS

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

SIDCHG64.exe /RESETAPPS=App_1

Где App_1 – имя современного приложения, можно перечислить несколько значений через запятую.

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

Режимы выделения виртуальной памяти в Linux

Еще один вопрос, который вызывает ряд неверных толкований и ошибок в применении – это режим выделения виртуальной памяти в Linux. А именно политика overcommitment – избыточного выделения памяти процессам, чем есть в системе на самом деле.

Постойте, но зачем выделять памяти больше, чем ее есть на самом деле? Может быть надо жить по средствам? Но не все так просто. Многие процессы запрашивают памяти больше, чем используют на самом деле.

Объем заметки не позволяет углубиться в суть происходящих процессов, поэтому допустим определенные упрощения. Во-первых, процесс может резервировать память «на всякий случай», во-вторых – в память могут отображаться разреженные структуры, например, файл 1 ГБ, у которого реально занято 250 МБ, остальное нули (виртуальный диск).

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

Таким образом выделение памяти процессу не означает ее обязательного использования. Реальное использование физической памяти начинается только после обращения к ней. При этом для процесса не делается разницы между оперативной памятью и подкачкой, и то и другое – физическая память.

Выделение памяти – это, по сути, обещание ядра такую память предоставить, а не ее жесткое резервирование. В результате может сложиться ситуация, что сразу несколько процессов потребуют предоставить зарезервированную память, но ее не окажется в наличии. В этом случае на сцену выходит OOM-killer и убивает самый «негодный» процесс.

Режим работы этого механизма можно задать при помощи опции

vm.overcommit_memory

Которая может принимать одно из трех значений: 0, 1 и 2

🔹vm.overcommit_memory = 0 – значение по умолчанию, лимит выделения памяти рассчитывается ядром эвристически, с учетом реального ее использования. Такая стратегия позволяет наиболее эффективно использовать всю наличную память.

В таком режиме ядро обычно допускает умеренный overcommit на основе объема свободной памяти, swap и освобождаемого дискового кэша.

Из минусов мы имеем некоторую неопределенность. Один и тот же запрос на выделение памяти, может быть, как одобрен ядром, так и отклонен. Также имеется возможность неожиданного срабатывания OOM-killer.

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

🔹 vm.overcommit_memory = 1 – выделение памяти происходит всегда, все лимиты отключены. Очень специфический режим, который тем не менее может оказаться полезным для процессов активно использующих порождение потомков и общую память (веб-сервера).

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

🔹 vm.overcommit_memory = 2 – жесткий лимит на выделение памяти, для этого режима используется еще одна опция:

vm.overcommit_ratio = 100

Которая обозначает какой процент памяти используется для вычисления лимита, который производится по формуле:

CommitLimit = swap_total + (RAM_total × vm.overcommit_ratio / 100)

По умолчанию vm.overcommit_ratio = 50 и поэтому если вы его не зададите явно, то лимит будет меньше имеющейся в наличии физической памяти.

Данный режим рекомендуется использовать вместе с приложениями, которые сами управляют выделением памяти, например, СУБД. В документации PostgreSQL такая настройка указана явно.

Причина здесь проста. В случае тяжелого запроса лучше получить явный отказ в выделении памяти и выдать пользователю ошибку «недостаточно памяти», нежели процесс СУБД окажется завершен OOM-killer и потребует аварийного перезапуска.

В ряде систем с высокими требованиями к стабильности рекомендуется уменьшить лимит выделения до 70-80%.

Как в Linux узнать скорость USB-портов и их текущий режим работы

Вопрос достаточно интересный и непраздный, очень часто нужно определить наиболее быстрый USB-порт устройства, чтобы, например, перекинуть большой объем данных.

Воткнуть в синий порт давно уже не вариант, так как разновидностей стандарта USB 3.x сегодня несколько и скорость работы там может существенно отличаться.

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

Но в Linux указанную информацию получить не просто, а очень просто, достаточно выполнить команду:

lsusb -t

Которая покажет номинальные скорости концентраторов и режимы работы подключенных к ним устройств.

Расшифровать значения также не сложно, они соответствуют значениям скорости в МБ/с, а именно:

▫️12М - USB 1.0
▫️480M – USB 2.0
▫️5000M - USB 3.2 Gen 1 (USB 3.0)
▫️10000M - USB 3.2 Gen 2 (USB 3.1)
▫️20000M/x2 - USB 3.2 Gen 2x2

Реальный вывод команды показан на скриншоте из которого четко видны режимы работы концентраторов и портов.

Визуальный калькулятор подсетей

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

Обычно это решается графическими построениями на бумаге или в Excel, но есть способ лучше – использовать Visual Subnet Calculator, открытый продукт, распространяющийся под лицензией MIT.

Проще и быстрее всего запустить его в Docker:

docker run -d -p 8081:8080 --name visualsubnetcalc ckabalan/visualsubnetcalc:latest

Теперь открываем http://myhost:8081 и начинаем работать. Сначала задаем желаемую сеть верхнего уровня и начинаем делить ее мышкой. Нажатие на сеть нижнего уровня делит ее на две равных подсети, нажатие на сеть верхнего уровня сворачивает все подсети под ней.

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

Утилита имеет четыре режима работы: стандартный и специализированный расчет для AWS, Azure и Oracle Cloud.

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

Как обустроить современный корпоративный VPN

Сегодня многие пользователи сталкиваются со сложностями в работе VPN-соединений благодаря заботе о нас одного уважаемого ведомства.

Забота эта достаточно непредсказуема и может коснуться каждого. Поэтому у многих возникает вопрос: а как жить дальше в этом непредсказуемом мире. Причем мы говорим о сугубо законопослушном использовании VPN для корпоративных нужд.

Поэтому мы с коллегами проанализировали и обобщили практику, на основе которой выработали современную модель удаленного доступа, максимально оптимизированную к текущим условиям.

Как показывает практика, наиболее устойчивы к блокировкам крупные российские датацентры. Поэтому возникает вполне закономерная схема их использования для размещения VPN-серверов.

Тот же Cloud.ru дает неплохую виртуалку бесплатно в рамках free tier, все что вам останется – это купить белый IP-адрес, который обойдется примерно в 150 руб./мес.

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

Таким образом наша схема приобретает законченные очертания. Приобретаем виртуалку в крупном отечественном датацентре и разворачиваем там VPN-сервер для доступа удаленных сотрудников.

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

Задача выполнена. Удаленные клиенты соединяются с доверенным облаком, блокировки которого гораздо менее вероятны, нежели блокировки офисного адреса, а офис общается с удаленной площадкой по туннелю IPsec, который также имеет крайне невысокий риск блокировки.

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

VPN-протоколы, степени риска

Не так давно, в связи с потребностями наших заказчиков мы провели достаточно объемное исследование на тему рисков использования VPN-протоколов для использования их в корпоративных целях и хотим поделиться некоторыми результатами.

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

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

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

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

🔴 L2TP/IPsec – риски крайне высокие, сигнатуры выгружены для блокировки, кроме того, протокол обладает крайне низкой устойчивостью, есть проблемы в сетях мобильных операторов, проблемы нескольких клиентов из-за одного NAT и т.д.

🟠 IKEv2/IPsec – риски высокие, UDP-сигнатуры прекрасно видны, сам протокол также широко использовался в известных целях. Устойчивость высокая, стабильно работает в сетях различных операторов, но также имеет высокую сложность настройки и отладки.

🔴 OpenVPN – классика жанра, риски высокие, устойчивость средняя, без дополнительной настройки может иметь низкую производительность на плохих каналах, самые высокие накладные расходы. Из плюсов – передача настроек с сервера на клиент.

🔴 WireGuard – риски очень высокие, легко детектируется и активно блокируется. Устойчивость высокая, но при этом имеет повышенные накладные расходы на администрирование в корпоративной среде.

🟢 SSTP – риски ниже среднего, это объясняется тем, что протокол проприетарный и в основном применение ограничено экосистемой Windows, ну и, пожалуй, Mikrotik. Для указанных целей практически не используется. Устойчивость высокая, практически не отличим от HTTPS, но при необходимости легко детектируется. Работает даже там, где заблокирован практически весь интернет.

🟢 OpenConnect – риски низкие, устойчивость высокая, внешне представляет реалистичный HTTPS-трафик, для обозначенных целей практически не используется. Привлекателен в корпоративной среде благодаря возможностям передачи настроек с сервера на клиент.

🟠 GRE/IPIP – риски низкие, устойчивость также низкая, имеют проблему прохождения NAT, не работают в сетях мобильных операторов, небезопасны. IPIP архитектурно ограничен только IP-трафиком.

🟢 IPsec – риски низкие, в основном используется для корпоративных и магистральных коммуникаций. Устойчивость выше средней, но также присутствуют требования к сторонам соединения (белые адреса и т.д.). Сложность настройки и отладки – крайне высокая, требует специальных знаний и навыков.

🟢 GRE/IPIP over IPsec – риски низкие, устойчивость выше средней. Внешне это тот же IPsec со всеми плюсами и минусами. Внутри привычные GRE/IPIP туннели. Сложность эксплуатации выше средней из-за присутствия IPsec, но значительно ниже, чем у чистого IPsec.

👉 Исходя из вышесказанного для целей удаленного доступа (Road-Warrior) рекомендуются SSL-VPN решения, такие как SSTP или OpenConnect, последний очень хорошо впишется в корпоративную сеть как полноценная замена OpenVPN с возможностью централизованного управления настройками клиентов.

Для соединения площадок (Site-to-Site) следует предпочитать решения на базе IPsec, наилучшим вариантом здесь будет GRE over IPsec, который сочетает сильные стороны IPsec с понятной сетевой моделью туннелей GRE, основанной на классической маршрутизации, а не на политиках.

‼️ Решений с высоким риском следует во всех сценариях избегать, даже если они еще работают, потому что в любой момент все может неожиданно измениться.

Защищаем сетевые службы при помощи stunnel

Говоря о защите сетевых служб, многие администраторы сразу вспоминают о VPN, нередко забывая об иных, не менее эффективных способах. Да, VPN позволяет эффективно решить эту задачу, но не всегда бывает удобен и очень часто избыточен.

Особенно если нужно защитить одну - две сетевые службы. Поэтому давайте посмотрим на доступные альтернативы, одна из них - это stunnel, SSL-прокси с широкими возможностями, одна из них - создание защищенного соединения между двумя узлами.

Чтобы понять для каких случаев предпочтительнее stunnel снова вернемся к VPN, при всех ее достоинствах некоторые из них могут обернуться недостатками.

С помощью VPN легко предоставить доступ ко всем ресурсам внутренней сети, но если с той стороны находится неконтролируемый или внештатный сотрудник (скажем бухгалтер на аутсорсинге), то этот плюс моментально превращается в минус. И нам уже надо думать не о том, как доступ к сети предоставить, а о том, как бы его закрыть.

В то же время stunnel предусматривает совершенно иной принцип работы, он работает на уровне TCP-соединений и позволяет просто и эффективно защитить его при помощи современного шифрования.

С его помощью клиент будет иметь доступ к одному единственному порту сетевой службы и никуда более. При необходимости можно настроить несколько таких соединений.

Для примера мы рассмотрим организацию доступа к веб-серверу с опубликованной на нем базой 1С:Предприятия, доступ к которой должен иметь удаленный сотрудник.

Будем считать, что веб-сервер с модулем расширения 1С установлен на машине с Linux (Debian или Ubuntu) расположенной в локальной сети предприятия, веб-сервер принимает подключения по протоколу HTTP без шифрования. Задача - обеспечить доступ к 1С с рабочего места бухгалтера.

✅ Читать далее: https://interface31.ru/post/zashhishhaem-setevye-sluzhby-pri-pomoshhi-stunnel/