Верно. df - сколько блоков занято на устройстве с точки зрения файловой системы, включая всё что du никогда не увидит (метаданные ФС, зарезервированные блоки, удалённые но открытые файлы) du - сколько блоков числится за файлами которые он обошёл
Когда процесс открывает файл ядро делает три вещи:
1. Находит inode - для существующего файла идёт по пути через directory entries. Для нового (O_CREAT) - сначала создаёт inode, потом directory entry на него.
2. Создаёт struct file - это объект в памяти ядра: указатель на inode, текущая позиция в файле (offset), флаги (O_RDONLY и т.д.). Это и есть "ссылка на inode".
3. Кладёт fd в таблицу процесса - файловый дескриптор (число 3, 4, 5...) это просто индекс в таблице который указывает на struct file.
journald - да, хороший вариант, приложение может просто писать в поток и не знать вообще ни про какой файл = не держать fd, вся ротация и прочее будет разруливаться на уровне journald. btrfs - да, есть такой момент у btrfs, поэтому лучше отдельной тулзой для btrfs - вы правы.
Верно.
df - сколько блоков занято на устройстве с точки зрения файловой системы, включая всё что du никогда не увидит (метаданные ФС, зарезервированные блоки, удалённые но открытые файлы)
du - сколько блоков числится за файлами которые он обошёл
Абсолютно верное и важное уточнение, спасибо.
Когда процесс открывает файл ядро делает три вещи:
1. Находит inode - для существующего файла идёт по пути через directory entries. Для нового (O_CREAT) - сначала создаёт inode, потом directory entry на него.
2. Создаёт struct file - это объект в памяти ядра: указатель на inode, текущая позиция в файле (offset), флаги (O_RDONLY и т.д.). Это и есть "ссылка на inode".
3. Кладёт fd в таблицу процесса - файловый дескриптор (число 3, 4, 5...) это просто индекс в таблице который указывает на struct file.
верное замечание, access.log действительно лучше не держать в journald, как раз таки из за оверхеда, сам journald добавляет еще кучу полей к записи.
journald - да, хороший вариант, приложение может просто писать в поток и не знать вообще ни про какой файл = не держать fd, вся ротация и прочее будет разруливаться на уровне journald.
btrfs - да, есть такой момент у btrfs, поэтому лучше отдельной тулзой для btrfs - вы правы.