DevOps Portal | Linux
Присоединяйтесь к нашему каналу и погрузитесь в мир DevOps Сотрудничество, реклама: @devmangx Менеджер: @Spiral_Yuri РКН: https://clck.ru/3P8kFH
Показати більше📈 Аналітичний огляд Telegram-каналу DevOps Portal | Linux
Канал DevOps Portal | Linux (@loose_code) у мовному сегменті Російська є активним учасником. На даний момент спільнота об'єднує 13 158 підписників, посідаючи 9 707 місце в категорії Технології та додатки та 50 486 місце у регіоні Росія.
📊 Показники аудиторії та динаміка
З моменту свого створення невідомо, проект продемонстрував стрімке зростання, зібравши аудиторію у 13 158 підписників.
За останніми даними від 11 червня, 2026, канал демонструє стабільну активність. Хоча за останні 30 днів спостерігається зміна кількості учасників на -70, а за останні 24 години на -2, загальне охоплення залишається високим.
- Статус верифікації: Не верифікований
- Рівень залученості (ER): Середній показник залученості аудиторії становить 17.20%. Протягом перших 24 годин після публікації контент зазвичай збирає 9.17% реакцій від загальної кількості підписників.
- Охоплення публікацій: В середньому кожен допис отримує 2 264 переглядів. Протягом першої доби публікація в середньому набирає 1 207 переглядів.
- Реакції та взаємодія: Аудиторія активно підтримує контент: середня кількість реакцій на один пост – 8.
- Тематичні інтереси: Контент зосереджений навколо ключових тем, таких як devops, kubernetes, docker, linux, ebpf.
📝 Опис та контентна політика
Автор описує ресурс як майданчик для висловлення суб'єктивної думки:
“Присоединяйтесь к нашему каналу и погрузитесь в мир DevOps
Сотрудничество, реклама: @devmangx
Менеджер: @Spiral_Yuri
РКН: https://clck.ru/3P8kFH”
Завдяки високій частоті оновлень (останні дані отримано 12 червня, 2026), канал підтримує актуальність та високий рівень охоплення публікацій. Аналітика показує, що аудиторія активно взаємодіє з контентом, що робить його важливою точкою впливу в категорії Технології та додатки.
df -h, ожидая увидеть, что использование диска уменьшилось. Не снизилось. Всё ещё показывало 100% заполнения.
Ни ошибок, ни варнингов. Просто та же картинка, как будто я ничего не удалял.
Тогда я и понял, что удаление файла не всегда сразу освобождает место.
В Linux то, что мы считаем «файлом», на самом деле состоит из двух сущностей: имени файла (это всего лишь указатель) и inode (в нём хранятся данные и метаданные). Когда вы удаляете имя файла, вы всего лишь убираете указатель. Inode и его данные остаются на диске до тех пор, пока какой-то процесс держит файл открытым.
В моём случае веб-сервер всё ещё писал в этот лог. Хотя я уже снёс имя файла, процесс сервера продолжал держать файловый дескриптор. Inode оставался «живым», невидимым в обычных списках файлов, но продолжал занимать место.
Диск освободился только после того, как я перезапустил веб-сервер, и он закрыл все свои файловые дескрипторы.
Вот почему нужны разные команды, чтобы видеть реальную картину:
# Проверить использование ФС
df -h
# Проверить реальные размеры директорий
du -sh /var/log/*
# Найти удалённые файлы, которые всё ещё держат процессы
lsof +L1
du показывает, что реально занимает место в директориях, а df - использование на уровне файловой системы.
Если цифры не сходятся, скорее всего, у тебя есть удалённые файлы, которые всё ещё держат процессы.
По этой же причине корректная ротация логов не просто удаляет файлы. Инструменты вроде logrotate переименовывают файлы и шлют сигнал процессам, чтобы те закрыли и заново открыли дескрипторы.
Три ключевых вывода:
1. Имена файлов — это всего лишь указатели на inode
2. Удаление действительно происходит, только когда ни один процесс не ссылается на inode
3. При разборе проблем с местом на диске всегда смотрите и df, и du
Мелочь, но понимание этого может спасти от очень запутанных инцидентов в продакшене.
👉 DevOps Portal
Вже доступно! Дослідження Telegram за 2025 — головні інсайти року 
