The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

В ядро Linux 6.2 войдут улучшения RAID5/6 в Btrfs, opennews (??), 18-Дек-22, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


9. "В ядро Linux 6.2 войдут улучшения RAID5/6 в Btrfs"  –1 +/
Сообщение от Аноним (9), 18-Дек-22, 20:54 
Я использую btrfs на системном ссд с данными, всё норм. Мне нужны сжатие текстовых данных и дедупликация, что в ext4 не удобно так это необходимость регулярно прогонять hardlink и отсутствие сжатия. Зачем тебе btrfs, mdadm не хватит?
Ответить | Правка | Наверх | Cообщить модератору

11. "В ядро Linux 6.2 войдут улучшения RAID5/6 в Btrfs"  +1 +/
Сообщение от Аноним (11), 18-Дек-22, 20:58 
хватит конечно! вы бы еще бекапы не компашки предложили
Ответить | Правка | Наверх | Cообщить модератору

75. "В ядро Linux 6.2 войдут улучшения RAID5/6 в Btrfs"  +1 +/
Сообщение от V1 (ok), 19-Дек-22, 03:26 
Используешь btrfs, а не удобна ext4?
Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

86. "В ядро Linux 6.2 войдут улучшения RAID5/6 в Btrfs"  +/
Сообщение от Аноним (9), 19-Дек-22, 06:47 
И?
Ответить | Правка | Наверх | Cообщить модератору

81. "В ядро Linux 6.2 войдут улучшения RAID5/6 в Btrfs"  +/
Сообщение от EULA (?), 19-Дек-22, 05:27 
mdadm снапшоты не умеет.
mdadm сжатие не умеет.
Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

88. "В ядро Linux 6.2 войдут улучшения RAID5/6 в Btrfs"  –1 +/
Сообщение от Аноним (9), 19-Дек-22, 07:00 
Сжатие умеет tar. Снапшоты тоже. Именно так бэкапятся изменения за неделю и в конце недели полноценный бэкап. Рейд это не бэкап, ему не нужны снапшоты или сжатие.
Ответить | Правка | Наверх | Cообщить модератору

97. "В ядро Linux 6.2 войдут улучшения RAID5/6 в Btrfs"  +/
Сообщение от i_use_btrfs (ok), 19-Дек-22, 08:52 
> Сжатие умеет tar. Снапшоты тоже.

Отлично конечно но в файловой системе недоступно и скорость доступа совсем другая.

Ответить | Правка | Наверх | Cообщить модератору

109. "В ядро Linux 6.2 войдут улучшения RAID5/6 в Btrfs"  –1 +/
Сообщение от EULA (?), 19-Дек-22, 10:23 
> Сжатие умеет tar.

Это когда tar стал уметь сжатие? То, что утилита tar может вызывать внешние утилиты для для сжатия, не означает, что tar умеет сжатие. Не зря многие виндовые ФМ архивов видят вначале архив gzip/bz2/xz/lz/zstd с одним файлом, а потом архив tar.

> Именно так бэкапятся изменения за неделю и в конце недели полноценный бэкап.

Да? А если данные в момент бэкапа активно изменяются, как будете бэкапить без остановки процесса, изменения данных?

> Рейд это не бэкап, ему не нужны снапшоты или сжатие.

Рейд, снапшоты и сжатие - это три вещи, как билет на поезд, сидение и скорость.
И на рейде можно держать раздел с сжатием, на котором можно использовать снапшоты.
Copy-on-Write позволяет избежать случайного повреждения нужных данных.
А сжатие позволит на одном разделе разместить


И как я могу архив tar смонтировать как раздел ФС?

Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

132. "В ядро Linux 6.2 войдут улучшения RAID5/6 в Btrfs"  +/
Сообщение от Аноним (9), 19-Дек-22, 15:23 
GNU tar имеет встроенную поддержку для компрессоров и может напрямую их вызывать (даже zstd добавили, хоть и ограничено -- было например не перечислить дополнительные параметры в переменной, как с xz). Ни одна программа на свете не реализует эти алгоритмы сама, это не мешает им уметь в поддержку различных форматов сжатия. И да, твоё "один файл" не проблема, тарбол можно проиндексировать для получения произвольного доступа. Я использовал индексированные gz и есть даже для тарболов сжатых zstd. Что до "смонтировать", то ratarmount это видимо позволяет. Архиватора лучше и универсальнее tar ещё не придумали, зачем могу понадобиться снапшоты я до сих пор не понимаю. Некоторые безграмотные товарищи применяют их как альтернативу бэкапам, но это абсолютно некорректное использование.

Зы
>если данные в момент бэкапа активно изменяются

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

Ответить | Правка | Наверх | Cообщить модератору

146. "В ядро Linux 6.2 войдут улучшения RAID5/6 в Btrfs"  +/
Сообщение от Анончик (?), 20-Дек-22, 00:22 
>Я использовал индексированные gz и есть даже для тарболов сжатых zstd.

можно по подробно

Ответить | Правка | Наверх | Cообщить модератору

147. "В ядро Linux 6.2 войдут улучшения RAID5/6 в Btrfs"  +/
Сообщение от Аноним (9), 20-Дек-22, 02:19 
>>Я использовал индексированные gz и есть даже для тарболов сжатых zstd.
> можно по подробно

Такое пойдёт? Что-то вроде того и было https://github.com/devsnd/tarindexer/blob/master/tarindexer.py

Для zstd видимо придётся отказаться от стандартных утилит в пользу https://github.com/martinellimarco/t2sz/ из-за проблем с навигацией.

Упомянутый ratarmount всё это умеет.

Ответить | Правка | Наверх | Cообщить модератору

174. "В ядро Linux 6.2 войдут улучшения RAID5/6 в Btrfs"  +/
Сообщение от EULA (?), 22-Дек-22, 09:38 
> ratarmount это видимо позволяет

1. fusermount. Корень не смонтировать.
2. RO, как и SquashFS.

> зачем могу понадобиться снапшоты я до сих пор не понимаю

1. Загрузка ОС из снапшота, если в основной ветке ОС решила умереть из-за настроек.
2. Тестирование изменений в продакшине, дабы не тратить время на даунтайм при создании бэкапа и восстановлении из бэкапа. Регулярно используется в гипервизиорах от MS и VMWare только на уровне ВМ или их дисков.

> Конечно, остановить и сделать снапшот может быть на пару секунд быстрее, чем затарить

Точно. 50 ГБ СУБД тарятся около часа. Снапшот делается 0,3 секунды. 3600 секунд всего на пару секунд быстрее, чем 1/3 секунды.

>  но что если что-то пойдёт не так из-за вмешательства в метаданные фс.

Что может пойти не так, если средствами самой ФС в метаданные вносятся изменения?
Какой будет даунтайм, если на другой ФС из-за вмешательства в метаданные средствами ФС, она навернется?

> Снапшот же изменяющихся данных будет равноценен хардресету и это очень не понравится софту

Какому софту это не нравится, если даже процедура бэкапов штатными средствами софта делает снапшот?

> И что будет, когда прошлые полноценные снапшоты без повреждений окажутся удалены

То же самое, что и при удалении неповрежденных бэкапов. Покажите, как восстановить инкрементный бэкап, если последний полный бэкап удален?

Всего-то полгода назад один крупнейший вендер бэкапов узнал, что создавал битые архивы из-за софтовых воин. Кто-то в системные либы внес правки, которые ломали бэкапы. А ФС работает не с либами, а чисто в пространстве ядра.

Ответить | Правка | К родителю #132 | Наверх | Cообщить модератору

183. "В ядро Linux 6.2 войдут улучшения RAID5/6 в Btrfs"  +1 +/
Сообщение от Аноним (-), 24-Дек-22, 20:09 
> 1. fusermount. Корень не смонтировать.
> 2. RO, как и SquashFS.

3. Времена операций сильно более другие. Одно дело вернуть систему в вид как было за 2 минуты после кривого апдейта, откатив как виртуалку. Совсем другое - с таром вон тем заниматься.

А еще - с таром можно промахнуться да не тот бэкап раскатать. И вот это бывает очень весело. В общем монтирование снапшотов и файловые операции с ними - сильно более другой уровень.

> бэкапы. А ФС работает не с либами, а чисто в пространстве ядра.

Ну да. Меньше всего по пути. А какой-нибудь send еще может быть достаточно эффективным дифференциальным бэкапом, если понимать как это делать правильно.

Ответить | Правка | Наверх | Cообщить модератору

194. "В ядро Linux 6.2 войдут улучшения RAID5/6 в Btrfs"  +/
Сообщение от EULA (?), 16-Янв-23, 14:04 
>[оверквотинг удален]
>> 2. RO, как и SquashFS.
> 3. Времена операций сильно более другие. Одно дело вернуть систему в вид
> как было за 2 минуты после кривого апдейта, откатив как виртуалку.
> Совсем другое - с таром вон тем заниматься.
> А еще - с таром можно промахнуться да не тот бэкап раскатать.
> И вот это бывает очень весело. В общем монтирование снапшотов и
> файловые операции с ними - сильно более другой уровень.
>> бэкапы. А ФС работает не с либами, а чисто в пространстве ядра.
> Ну да. Меньше всего по пути. А какой-нибудь send еще может быть
> достаточно эффективным дифференциальным бэкапом, если понимать как это делать правильно.

Точно.

Ответить | Правка | Наверх | Cообщить модератору

165. "В ядро Linux 6.2 войдут улучшения RAID5/6 в Btrfs"  +/
Сообщение от Аноним (-), 21-Дек-22, 14:39 
> Сжатие умеет tar.

Это все отлично конечно, но по времени операций и удобству рядом не стояло.

> Снапшоты тоже. Именно так бэкапятся изменения за неделю и в конце недели полноценный бэкап.

Сделать снапшот терабайтной ФС в сабже моментально. А таром так можно? То-то и оно :). Снапшот не бэкап но откатить систему после неудачного обновления или смены настроек удобно.

Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру