История изменений

Для использования Btrfs должны быть причины:

• Тебе нужно сжатие на уровне ФС. Но оно не применимо почти ко всем типам медиафайлов, так как те и так уже сжаты. Поэтому на живой системе добиться экономиии места более 25% сложно
• Дедупликация. При копировании файла через ЦОПЭ мы не создаем его копию, мы лишь ссылаемся на оригинал. И это удобно. Но ес-но файловая система сама не в состоянии отследить наличие дубликатов, созданных иными путями, поэтому для более умной дедупликации есть специальные утилиты.
• Снапшоты. Ближайший аналог коммиты в Git. Сделал снапшот, зафиксировал состояние к которому можешь откатиться в любой момент. Удобнее всего это делать через гуй типа Btrfs Assistant
• Зеркалирование на уровне ФС. Ты можешь создать RAID-1 без сторонних утилит, что повышает шансы сохранить данные в случае смерти контроллера SSD
• Тебе не нужно создавать отдельные разделы для разных точек монтирования. Так как файловая система имеет сабвольюмы, которые в проводнике представлены как обычные папки. Ты можешь в них монтироваться, изменять им способ и уровень сжатия, отключать COW и тд
• Btrfs хороша для Docker, так как позволяет экономить место, если тот заставить использовать Btrfs в качестве файлового «драйвера»

Если тебе из этого ничего не нужно, то используй Ext4, потому как у Btrfs есть минусы:

• Она медленее чем тот же Ext. Без сжатия или со сжатием zstd:1 скорость записи будет высокой, но все равно не позволит тебе использовать весь потанцевал сверхбыстрых SSD. Причем, если используется сжатие, то количество записываемых несжатых данных может быть даже выше чем у некрофильской ФС столь любимой местными гурофагами и ретроградами
• Ее нужно уметь обслуживать. Рядовой рукожоп не в состоянии загуглить решение каких-то детских проблем типа ошибки чексум
• Базы данных работают медленее и требуют установки атрибута NoCoW на каталоги с данными. Правда, некотрые из них могут сами определять использование Btrfs и сами устанавливать нужный атрибут
• В ней нет встроенного шифрования, поэтому нужно использовать LUKS и пр
• Она не подходит для HDD из-за фрагментации и невысокой скорости произвольного чтения в последних

Касательно твоих проблем, то:

• Отдельные разделы для /home и / - это чисто серверный подход. Непривелегированные пользователи сервака могут каким-нибудь мусором занять все место, и если корень не отделен от хомяка, то нельзя будет даже подключиться к серваку чтобы почистить место. Те для рядового мышевоза оно НЕНУЖНО
• В Btrfs ситуация состоит несколько иначе. Если ты используешь автоматическое снятие снапшотов, то желательно иметь отдельные сабвольюмы @ и @home, потому снапшоты корня не представляют какой-либо ценности в отличии от данных в хомяке. Еще можно создать сабвольюм @var_log, так как потеря логов никак не влияет на работоспособность системы. Ну и у разных сабвольюмов может быть разный уровень сжатия, ага

Для использования Btrfs должны быть причины:

• Тебе нужно сжатие на уровне ФС. Но оно не применимо почти ко всем типам медиафайлов, так как те и так уже сжаты. Поэтому на живой системе добиться экономиии места более 25% сложно
• Дедупликация. При копировании файла через ЦОПЭ мы не создаем его копию, мы лишь ссылаемся на оригинал. И это удобно. Но ес-но файловая система сама не в состоянии отследить наличие дубликатов, созданных иными путями, поэтому для более умной дедупликации есть специальные утилиты.
• Снапшоты. Ближайший аналог коммиты в Git. Сделал снапшот, зафиксировал состояние к которому можешь откатиться в любой момент. Удобнее всего это делать через гуй типа Btrfs Assistant
• Зеркалирование на уровне ФС. Ты можешь создать RAID-1 без сторонних утилит, что повышает шансы сохранить данные в случае смерти контроллера SSD
• Тебе не нужно создавать отдельные разделы для разных точек монтирования. Так как файловая система имеет сабвольюмы, которые в проводнике представлены как обычные папки. Ты можешь в них монтироваться, изменять им способ и уровень сжатия, отключать COW и тд
• Btrfs хороша для Docker, так как позволяет экономить место, если тот заставить использовать Btrfs в качестве файлового «драйвера»

Если тебе из этого ничего не нужно, то используй Ext4, потому как у Btrfs есть минусы:

• Она медленее чем тот же Ext. Без сжатия или со сжатием zstd:1 скорость записи будет высокой, но все равно не позволит тебе использовать весь потанцевал сверхбыстрых SSD. Причем, если используется сжатие, то количество записываемых несжатых данных может быть даже выше чем у некрофильской ФС столь любимой местными гурофагами и ретроградами
• Ее нужно уметь обслуживать. Рядовой рукожоп не в состоянии загуглить решение каких-то детских проблем типа ошибки чексум
• Базы данных работают медленее и требуют установки атрибута NoCoW на каталоги с данными. Правда, некотрые из них могут сами определять использование Btrfs и сами устанавливать нужный атрибут
• В ней нет встроенного шифрования, поэтому нужно использовать LUKS и пр

Касательно твоих проблем, то:

• Отдельные разделы для /home и / - это чисто серверный подход. Непривелегированные пользователи сервака могут каким-нибудь мусором занять все место, и если корень не отделен от хомяка, то нельзя будет даже подключиться к серваку чтобы почистить место. Те для рядового мышевоза оно НЕНУЖНО
• В Btrfs ситуация состоит несколько иначе. Если ты используешь автоматическое снятие снапшотов, то желательно иметь отдельные сабвольюмы @ и @home, потому снапшоты корня не представляют какой-либо ценности в отличии от данных в хомяке. Еще можно создать сабвольюм @var_log, так как потеря логов никак не влияет на работоспособность системы. Ну и у разных сабвольюмов может быть разный уровень сжатия, ага

Для использования Btrfs должны быть причины:

• Тебе нужно сжатие на уровне ФС. Но оно не применимо почти ко всем типам медиафайлов, так как те и так уже сжаты. Поэтому на живой системе добиться экономиии места более 25% сложно
• Дедупликация. При копировании файла через ЦОПЭ мы не создаем его копию, мы лишь ссылаемся на оригинал. И это удобно. Но ес-но файловая система сама не в состоянии отследить наличие дубликатов, созданных иными путями, поэтому для более умной дедупликации есть специальные утилиты.
• Снапшоты. Ближайший аналог коммиты в Git. Сделал снапшот, зафиксировал состояние к которому можешь откатиться в любой момент. Удобнее всего это делать через гуй типа Btrfs Assistant
• Зеркалирование на уровне ФС. Ты можешь создать RAID-1 без сторонних утилит, что повышает шансы сохранить данные в случае смерти контроллера SSD
• Тебе не нужно создавать отдельные разделы для разных точек монтирования. Так как файловая система имеет сабвольюмы, которые в проводнике представлены как обычные папки. Ты можешь в них монтироваться, изменять им способ и уровень сжатия, отключать COW и тд
• Btrfs хороша для Docker, так как позволяет экономить место, если тот заставить использовать Btrfs в качестве файлового «драйвера»

Если тебе из этого ничего не нужно, то используй Ext4, потому как у Btrfs есть минусы:

• Она медленее чем тот же Ext. Без сжатия или со сжатием zstd:1 скорость записи будет высокой, но все равно не позволит тебе использовать весь потанцевал сверхбыстрых SSD. Причем, если используется сжатие, то количество записываемых несжатых данных может быть даже выше чем у некрофильской ФС столь любимой местными гурофагами и ретроградами
• Ее нужно уметь обслуживать. Рядовой рукожоп не в состоянии загуглить решение каких-то детских проблем типа ошибки чексум
• Базы данных работают медленее и требуют установки атрибута NoCoW на каталоги с данными. Правда, некотрые из них могут сами определять использование Btrfs и сами устанавливать нужный атрибут

Касательно твоих проблем, то:

• Отдельные разделы для /home и / - это чисто серверный подход. Непривелегированные пользователи сервака могут каким-нибудь мусором занять все место, и если корень не отделен от хомяка, то нельзя будет даже подключиться к серваку чтобы почистить место. Те для рядового мышевоза оно НЕНУЖНО
• В Btrfs ситуация состояит несколько иначе. Если ты используешь автоматическое снятие снапшотов, то желательно иметь отдельные сабвольюмы @ и @home, потому снапшоты корня не представляют какой-либо ценности в отличии от данных в хомяке. Еще можно создать сабвольюм @var_log, так как потеря логов никак не влияет на работоспособность системы

Для использования Btrfs должны быть причины:

• Тебе нужно сжатие на уровне ФС. Но оно не применимо почти ко всем типам медиафайлов, так как те и так уже сжаты. Поэтому на живой системе добиться экономиии места более 25% сложно
• Дедупликация. При копировании файла через ЦОПЭ мы не создаем его копию, мы лишь ссылаемся на оригинал. И это удобно. Но ес-но файловая система сама не в состоянии отследить наличие дубликатов, созданных иными путями, поэтому для более умной дедупликации есть специальные утилиты.
• Снапшоты. Ближайший аналог коммиты в Git. Сделал снапшот, зафиксировал состояние к которому можешь откатиться в любой момент. Удобнее всего это делать через гуй типа Btrfs Assistant
• Зеркалирование на уровне ФС. Ты можешь создать RAID-1 без сторонних утилит, что повышает шансы сохранить данные в случае смерти контроллера SSD
• Тебе не нужно создавать отдельные разделы для разных точек монтирования. Так как файловая система имеет сабвольюмы, которые в проводнике представлены как обычные папки. Ты можешь в них монтироваться, изменять им способ и уровень сжатия, отключать COW и тд
• Btrfs хороша для Docker, так как позволяет экономить место, если тот заставить использовать Btrfs в качестве файлового «драйвера»

Если тебе из этого ничего не нужно, то используй Ext4, потому как у Btrfs есть минусы:

• Она медленее чем тот же Ext. Без сжатия или со сжатием zstd:1 скорость записи будет высокой, но все равно не позволит тебе использовать весь потанцевал сверхбыстрых SSD. Причем, если используется сжатие, то количество записываемых несжатых данных может быть даже выше чем у некрофильской ФС столь любимой местными гурофагами и ретроградами
• Ее нужно уметь обслуживать. Рядовой рукожоп не в состоянии загуглить решение каких-то детских проблем типа ошибки чексум
• Базы данных работают медленее и требуют установки атрибута NoCoW на каталоги с данными

Касательно твоих проблем, то:

• Отдельные разделы для /home и / - это чисто серверный подход. Непривелегированные пользователи сервака могут каким-нибудь мусором занять все место, и если корень не отделен от хомяка, то нельзя будет даже подключиться к серваку чтобы почистить место. Те для рядового мышевоза оно НЕНУЖНО
• В Btrfs ситуация состояит несколько иначе. Если ты используешь автоматическое снятие снапшотов, то желательно иметь отдельные сабвольюмы @ и @home, потому снапшоты корня не представляют какой-либо ценности в отличии от данных в хомяке. Еще можно создать сабвольюм @var_log, так как потеря логов никак не влияет на работоспособность системы

Для использования Btrfs должны быть причины:

• Тебе нужно сжатие на уровне ФС. Но оно не применимо почти ко всем типам медиафайлов, так как те и так уже сжаты. Поэтому на живой системе добиться экономиии места более 25% сложно
• Дедупликация. При копировании файла через ЦОПЭ мы не создаем его копию, мы лишь ссылаемся на оригинал. И это удобно. Но ес-но файловая система сама не в состоянии отследить наличие дубликатов, созданных иными путями, поэтому для более умной дедупликации есть специальные утилиты.
• Снапшоты. Ближайший аналог коммиты в Git. Сделал снапшот, зафиксировал состояние к которому можешь откатиться в любой момент. Удобнее всего это делать через гуй типа Btrfs Assistant
• Зеркалирование на уровне ФС. Ты можешь создать RAID-1 без сторонних утилит, что повышает шансы сохранить данные в случае смерти контроллера SSD
• Тебе не нужно создавать отдельные разделы для разных точек монтирования. Так как файловая система имеет сабвольюмы, которые в проводнике представлены как обычные папки. Ты можешь в них монтироваться, изменять им способ и уровень сжатия, отключать COW и тд
• Btrfs хороша для Docker, так как позволяет экономить место, если тот заставить использовать Btrfs в качестве файлового «драйвера»

Если тебе из этого ничего не нужно, то используй Ext4, потому как у Btrfs есть минусы:

• Она медленее чем тот же Ext. Без сжатия или со сжатием zstd:1 скорость записи высокой, но все равно не позволит тебе использовать весь потанцевал сверхбыстрых SSD. Причем, если используется сжатие, то количество записываемых несжатых данных может быть даже выше чем у некрофильской ФС
• Ее нужно уметь обслуживать. Рядовой рукожоп не в состоянии загуглить решение каких-то детских проблем типа ошибки чексум
• Базы данных работают медленее и требуют установки атрибута NoCoW на каталоги с данными

Касательно твоих проблем, то:

• Отдельные разделы для /home и / - это чисто серверный подход. Непривелегированные пользователи сервака могут каким-нибудь мусором занять все место, и если корень не отделен от хомяка, то нельзя будет даже подключиться к серваку чтобы почистить место. Те для рядового мышевоза оно НЕНУЖНО
• В Btrfs ситуация состояит несколько иначе. Если ты используешь автоматическое снятие снапшотов, то желательно иметь отдельные сабвольюмы @ и @home, потому снапшоты корня не представляют какой-либо ценности в отличии от данных в хомяке. Еще можно создать сабвольюм @var_log, так как потеря логов никак не влияет на работоспособность системы

Для использования Btrfs должны быть причины:

• Тебе нужно сжатие на уровне ФС. Но оно не применимо почти ко всем типам медиафайлов, так как те и так уже сжаты. Поэтому на живой системе добиться экономиии места более 25% сложно
• Дедупликация. При копировании файла через ЦОПЭ мы не создаем его копию, мы лишь ссылаемся на оригинал. И это удобно. Но ес-но файловая система сама не в состоянии отследить наличие дубликатов, созданных иными путями, поэтому для более умной дедупликации есть специальные утилиты.
• Снапшоты. Ближайший аналог коммиты в Git. Сделал снапшот, зафиксировал состояние к которому можешь откатиться в любой момент. Удобнее всего это делать через гуй типа Btrfs Assistant
• Зеркалирование на уровне ФС. Ты можешь создать RAID-1 без сторонних утилит, что повышает шансы сохранить данные в случае смерти контроллера SSD
• Тебе не нужно создавать отдельные разделы для разных точек монтирования. Так как файловая система имеет сабвольюмы, которые в проводнике представлены как обычные папки. Ты можешь в них монтироваться, изменять им способ и уровень сжатия, отключать COW и тд
• Btrfs хороша для Docker, так как позволяет экономить место, если тот заставить использовать Btrfs в качестве файлового «драйвера»

Если тебе из этого ничего не нужно, то используй Ext4, потому как у Btrfs есть минусы:

• Она медленее чем тот же Ext. Без сжатия или со сжатием zstd:1 скорость записи высокой, но все равно не позволит тебе использовать весь потанцевал сверхбыстрых SSD. Причем, если используется сжатие, то количество записываемых несжатых данных может быть даже выше чем у некрофильской ФС
• Ее нужно уметь обслуживать. Рядовой рукожоп не в состоянии загуглить решение каких-то детских проблем типа ошибки чексум
• Базы данных работают медленее и требуют установки атрибута NoCoW на каталоги с данными

Касательно твоих проблем, то:

• Отдельные разделы для /home и / - это чисто серверный подход. Непривелегированные пользователи сервака мог каким-нибудь мусором занять все место, и если корень не отделен от хомяка, то нельзя будет даже подключиться к серваку чтобы почистить место. Те для рядового мышевоза оно НЕНУЖНО
• В Btrfs ситуация состояит несколько иначе. Если ты используешь автоматическое снятие снапшотов, то желательно иметь отдельные сабвольюмы @ и @home, потому снапшоты корня не представляют какой-либо ценности в отличии от данных в хомяке. Еще можно создать сабвольюм @var_log, так как потеря логов никак не влияет на работоспособность системы