The OpenNET Project / Index page

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



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

Оглавление

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

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


61. "Утверждён переход Fedora Desktop на Btrfs и замена редактора..."  +7 +/
Сообщение от Аноним (61), 16-Июл-20, 14:55 
накину, zfs рулит и педалит =)
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

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ообщить модератору

134. "Утверждён переход Fedora Desktop на Btrfs и замена редактора..."  –1 +/
Сообщение от Аноним (-), 16-Июл-20, 17:22 
> накину, zfs рулит и педалит =)

Но педалит она где-то там. Не в майнлайне. Хотя если вам нравится отпадение ФС после апгрейда кернела, гражданин известный как пох&нах с удовольствием подскажет вам как всего этого добиться без лишних усилий :)

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

149. "Утверждён переход Fedora Desktop на Btrfs и замена редактора..."  +1 +/
Сообщение от Аноним (27), 16-Июл-20, 17:53 
> Хотя если вам нравится отпадение ФС после апгрейда кернела

Во-первых, там проблема была не в fs, а в дистрибутиве и его косоруких макаках (при апгрейде кернела ломался только апгрейженный, но был более занятный способ сломать сразу все, и невосстановимо - и так совпало, что он тогда как раз слуцился) - там все шедеврально, от самого источника проблемы, до их подхода к ее исправлению.
(То есть что у них нет ни ограничений по изменениями в "шта6ильном" lts, ни автоматического тестирования, которое немедленно бы поймало проблему, ни (самое замечательное) - возможности просто откатить неудачный апгрейд тут же, а не через две недели кое-как, в обход существующих (бесполезных) процедур залатать поверх заплатки)
Во-вторых сломали один из двух вариантов (там есть вариант установки без dkms, готовым модулем - в нем ничего не ломалось).
В-третьих нефатально - грамотный админ спохватился и починил, без особых проблем, поскольку очевидно что поломалось и где чинить. Причем с zfs были цветочки, а владельцам невидии достались ягодки, в виде чорного экрана, там посложнее наощупь-то чинить было, наверное. Владельцы немодных сетевух вообще поехали во внезапную командировку в караганду, попутно читая заковыристые доки про apt-offline или как там его.

То есть та история была не про zfs вообще, это про бубунточку и ее "разработчиков". Завтра они что-нибудь другое так же тебе обновят.

У zfs совсем другие проблемы. Частично общие с btrfs, включая и 32x write amp (некоторые и 64 намеряли).

Превращаться в тыкву необратимым образом - тоже умеет.

В общем, на одном стуле пики точены, а на другом и того хуже... Лет пять назад можно было бы порадоваться, что раз за btrfs взялась fedora, читай redhat, возможно, в ближайшее время ее доведут до приличного состояния, но сегодня - больше верится в то, что и ту не доделают, опечатки в CoC только поправят, и другим станет доставаться еще меньше ресурсов и внимания.

Вот если Линусу его комп разнести - тогда могут быть полезные для нас результаты.

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

200. "Утверждён переход Fedora Desktop на Btrfs и замена редактора..."  –1 +/
Сообщение от Аноним (200), 16-Июл-20, 21:21 
> Во-первых, там проблема была не в fs, а в дистрибутиве и его косоруких макаках

Имхо, root cause = внеядерный модуль. А дистры не бог весть какие ядерщики. Крутые, видите ли, в майнлайне обитают прежде всего.

> что он тогда как раз слуцился) - там все шедеврально, от
> самого источника проблемы, до их подхода к ее исправлению.

Это пох чтоли? Или кто-то другой за него умничает? :)

[blabla skip]
> В-третьих нефатально - грамотный админ спохватился и починил, без особых проблем

...а еще более грамотный подумает что
1) Предпосылки к повтору такого счастья никуда не делись.
2) ФС, особенно под системой, которая может стать тыквой - все же грабли.
3) ИМХО тупо юзать ФС такого плана и не наслаждаться этим для, блин, отмотки состояния ОС на своем десктопе в более живой вид после какого-то неудачного системного эксперимента, допустим. ZFS для такого явно не айс - сам может отвалиться, ну и радости с такой фичи в таком сценарии?

> То есть та история была не про zfs вообще, это про бубунточку
> и ее "разработчиков". Завтра они что-нибудь другое так же тебе обновят.

Это была история про общее взаимодействие и о том что внеядерный модуль - ведет к не самому удачному комбо.

> У zfs совсем другие проблемы. Частично общие с btrfs, включая и 32x
> write amp (некоторые и 64 намеряли).

CoW не очень хорошо стыкуется с некоторыми ворклоадами. В btrfs по этому поводу CoW сделан отключаемым.

> Превращаться в тыкву необратимым образом - тоже умеет.

У btrfs для совсем тыквенных случаев офлайн чтец есть. Самое интересное что я им только в синтетических случаях пользовался - в реальных он пока ни разу не потребовался пока :D

> до приличного состояния, но сегодня - больше верится в то, что
> и ту не доделают, опечатки в CoC только поправят, и другим
> станет доставаться еще меньше ресурсов и внимания.

В федоре вообще остались какие-то видные имена от ФС и блочного уровня? А то все вроде по гуглофэйсбукам или накрайнях зюзям разбежались.

> Вот если Линусу его комп разнести - тогда могут быть полезные для нас результаты.

Оно уже потестировано на миллиарде хомяков мордокниги - и поэтому основная лажа и так вытряхнута несколько лет назад. Да, после внедрения был всплеск странных багов вида "на 20Тб файле случается неведома фигня". Но и это починили. Теперь там поток багов и фиксов плюс-минус как в остальных ФС. Т.е. вполне продакшново, не лучше и не хуже остальных ФС в лине.

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

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

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




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

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