The OpenNET Project / Index page

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



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

Оглавление

Утверждён переход Fedora Desktop на Btrfs и замена редактора vi на nano, opennews (??), 16-Июл-20, (0) [смотреть все]

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


72. "Утверждён переход Fedora Desktop на Btrfs и замена редактора..."  +/
Сообщение от Аноним (27), 16-Июл-20, 15:16 
Угу, единственная в линукс-мирке fs, неспособная использовать увеличившийся диск без перезагрузки (не смотря на автомагическую константу, якобы предназначенную для полной автоматизации этого архисложного действия).
С педальным приводом, то ись.

А shrink у нас и по сей день вообще суперсекретная технология, доступная только немодной немолодежной ext4.

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

124. "Утверждён переход Fedora Desktop на Btrfs и замена редактора..."  +/
Сообщение от Аноним (124), 16-Июл-20, 17:10 
ext4 вообще-то тоже модная-молодежная, это ж не ext2/3.
Ответить | Правка | Наверх | Cообщить модератору

210. "Утверждён переход Fedora Desktop на Btrfs и замена редактора..."  +/
Сообщение от Аноним (-), 16-Июл-20, 22:19 
> А shrink у нас и по сей день вообще суперсекретная технология, доступная
> только немодной немолодежной ext4.

Btrfs все это тоже умеет. Вплоть до целенаправленного быстрого удвигания данных с вон того диска и его изъяьтя из пула после этого. Я так делал даже с изменением схемы хранения попутно. Даже прокатило. А кто еще так вообще может? :)

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

272. "Утверждён переход Fedora Desktop на Btrfs и замена редактора..."  +/
Сообщение от Аноним (272), 17-Июл-20, 12:45 
> Btrfs все это тоже умеет. Вплоть до целенаправленного быстрого удвигания данных с вон того диска

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

А диски целиком (vdev'ы но это чаще и есть диски) zfs освобождать и та через пень-колоду научилась.

lvm умел, по-моему, всегда (то есть вообще все стандартные на последние пятнадцать лет энтерпрайзные решения - умеют, поскольку стандартом давно стали lvm+*fs, а не голый диск)

А вот ужать отросшую xfs - невозможно, только жрать умеет.

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

293. "Утверждён переход Fedora Desktop на Btrfs и замена редактора..."  +/
Сообщение от Аноним (-), 17-Июл-20, 20:37 
> это не shrink.

Это еще один вид shrink - в том плане что места на ФС будет меньше, данные с указанного места убрали и стало возможно этот девайс отключить.

> shrink нужен когда диск один (и он виртуальный), и
> надо освободить временно перерасходованное место.

Гамно вопрос, btrfs filesystem resize - умеет и в плюс и в минус! А какая ему разница, удвигать по backref'ам данные с другого девайса, или с хвоста вот этого? Там механика крутая и гибкая :)

> А диски целиком (vdev'ы но это чаще и есть диски) zfs освобождать
> и та через пень-колоду научилась.

Ну а btrfs вот не через пень колоду а как раз прозрачно, удобно и гибко все это. И достаточно универсально. Он гуляет по backref и чистит запрошенное место. Это относительно быстро - потому что заранее предусмотрено, и есть описатель "кому барахло в этих блоках принадлежит?". Поэтому барахло можно просто и быстро убрать - что с того девайса, что с хвоста этого девайса.

Черт, btrfs настолько гибок в аллокации что умудряется оформить конверсию EXT -> Btrfs как нечто типа снапшота, ассимилировав все что было до него. С возможностью вернуть все взад, что самое угарное - ведь начальное состояние не портится, сам btrfs аллокации для себя в других регионах оформляет.

> lvm умел, по-моему, всегда (то есть вообще все стандартные на последние пятнадцать
> лет энтерпрайзные решения - умеют, поскольку стандартом давно стали lvm+*fs, а не голый диск)

И черт бы с ним, пусть он там умеет где-нибудь подальше от меня. После btrfs'а я уже не хочу рулить всем этим через него.

> А вот ужать отросшую xfs - невозможно, только жрать умеет.

Да и фиг с ним. Он и данные нулями до сих пор умеет профигачивать. Возможно юзерам фидоры это не понравилось :)

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

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

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




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

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