The OpenNET Project / Index page

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



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

Оглавление

Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..., opennews (??), 10-Янв-20, (0) [смотреть все] +1

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


5. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +3 +/
Сообщение от Аноним (16), 10-Янв-20, 10:03 
Имхо, в очередной раз, хороший продукт ZFS медленно умирает без поддержки, из-за недальновидного руководства.

Непонятная ситуация с невключением в ядро отталкивает многих пользователей от использования этой фс. Меньше пользователей — меньше разработчиков, проект малоподдерживаемый, фигово интегрированный в линуксовое ядро (сколько времени с кешами разобраться не могут).

Открытая соляра умерла, популярность джавы падает, все наследство сана превращается в труху.

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

33. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +6 +/
Сообщение от пох. (?), 10-Янв-20, 10:53 
> Имхо, в очередной раз, хороший продукт ZFS медленно умирает без поддержки

вообще-то он не без поддержки умирает, он умирает от того, что его старательно портят разработчики, оставшиеся без руководителей с длинным кнутом и большим засохшим пряником, которым тоже можно грамотно уе6...

Причем не спас даже тот факт, что часть из них когда-то работали в sun и именно над zfs.

> Непонятная ситуация с невключением в ядро отталкивает многих пользователей от использования

пользователям, которых это отталкивает - лучше просто платить денег за техподдержку какому-нибудь netapp (которых, кстати, совершенно не смущает использование клона zfs в своих полках) и не выпендриваться.

Для применения zfs по месту - нужна техническая грамотность, превышающая вызывающую глупые "отталкивания".

> этой фс. Меньше пользователей — меньше разработчиков, проект малоподдерживаемый,

пользователи, сюрприз, не платят разработчикам. Им платят продавцы насов, санов и прочих радостей подорого.

> фигово интегрированный в линуксовое ядро (сколько времени с кешами разобраться не
> могут).

вы как всегда не владея темой пересказываете urban legends. Ни с чем там не надо разбираться, все уже разобрано до вас двадцать лет назад. Половина смысла применения zfs - в использовании кэша более разумного устройства, чем тот что придуман для линуха в 92м году, когда восемь мегабайт памяти казалось очень много.

Там надо разобраться с фатальным неумением линуха выделять большие блоки памяти эффективным образом, уходящим в тот же 92й год, и выбросить костылинг вокруг этого места, ведущий к жору памяти и потере производительности на больших массивах. И что-то сделать с вредителями, запрещающими использовать in-kernel api "неправильному" коду просто чтобы напакостить. Даже проигранный вмвари иск их ничему не научил (еще бы, денежки-то были - дядины).

> Открытая соляра умерла, популярность джавы падает, все наследство сана превращается в труху.

вот этим бы хлебальничком - того энтер-прайсного г-неца зачерпнуть, которое я каждый раз вынужден вычерпывать.

К сожалению, популярность жабы так "падает", что уже непонятно вообще куда от нее бечь.

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

53. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  –1 +/
Сообщение от Аноним (-), 10-Янв-20, 11:15 
> Причем не спас даже тот факт, что часть из них когда-то работали
> в sun и именно над zfs.

Кговавый энтегпгайз как он есть. Сам себя пожрал с хвоста, оказывается.

> пользователям, которых это отталкивает - лучше просто платить денег за техподдержку какому-нибудь netapp

А нафига? Можно btrfs взять забесплатно.

> (которых, кстати, совершенно не смущает использование клона zfs в своих
> полках) и не выпендриваться.

А троянцев^W забытые инженерные логины там как обычно "случайно" забудут? :)

> Для применения zfs по месту - нужна техническая грамотность, превышающая вызывающую глупые
> "отталкивания".

Ну а вот у btrfs'а дурных "технических особенностей" заметно меньше. Он вполне нормально себя ведет даже с дефолтовыми настройками. По крайней мере, RAM гигами не жрет и не тормозит. И вообще, на вид так сходу от ext4 и не отличишь особо. Ну разве что тормозят они немного по разному в силу разных принципов работы.

> пользователи, сюрприз, не платят разработчикам.

Если эксплуатанты чем-то пользуются - они, наверное, тоже ползователи? :)

> Им платят продавцы насов, санов и прочих радостей подорого.

Что-то не помогло это сану...

> Половина смысла применения zfs - в использовании кэша более разумного
> устройства, чем тот что придуман для линуха в 92м году, когда восемь мегабайт
> памяти казалось очень много.

С тех пор утекло много воды. В Linux с 92 года много чего переделали, btrfs придумали, и вообще.

> Там надо разобраться с фатальным неумением линуха выделять большие блоки памяти эффективным образом,

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

И если фэйсбук гордо репортит как btrfs им помогает ловить битые диски и контроллеры, то с zfs у них такой номер врядли хорошо получился бы.

> И что-то сделать с вредителями, запрещающими использовать in-kernel api "неправильному"
> коду просто чтобы напакостить. Даже проигранный вмвари иск их ничему не
> научил (еще бы, денежки-то были - дядины).

Они просто считают ядро своей епархией и меняют апи и проч как им удобнее. Проекты внутри ядра неизбежно адаптируются к этому. Без этого ядро не релизнется просто. А внеядерные выкидыши порой страдают. Если какому-нибудь "udp server в ядре" (да, такой прикол есть) много не надо, то файлухи в этом значительно хуже и используют море услуг ядра по разным поводам. И конечно же что-нибудь да отъезжает.

> К сожалению, популярность жабы так "падает", что уже непонятно вообще куда от
> нее бечь.

Ну как куда, на go, очевидно.

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

69. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +1 +/
Сообщение от пох. (?), 10-Янв-20, 11:42 
> Кговавый энтегпгайз как он есть. Сам себя пожрал с хвоста, оказывается.

причем тут - энтерпрайс? Энтер-прайс он у орацла, у того в соляре с zfs все нормально, она развивается - все последние серьезные улучшизмы в zol - cleanroom имплементации того, что уже было сделано орацлом (правда, изменять на ходу конфигурацию vdev так и ниасилили). Разьве что судьба самой соляры печальна.

Как только разработчиков из того ентер-прайса выпустили по подвальным лавочкам типа iX - оно и пошло вразнос.

> А нафига? Можно btrfs взять забесплатно.

только ссыкотно. Теперь - еще и потому, что возможно через год при вынужденной замене дистрибутива придется от него вообще отказаться, и мучаться с переносом данных. А ваш божок точно так же заявит что "don't use btrfs", и "по данным, высосанным из моего пальца, я не вижу высокой производительности".
Тут у zfs как 3d-party громадное преимущество, потому что ее я в любом случае смогу собрать отдельно, что бы там не нарешали разработчики дистрибутивов и вредители из lkml.

> А троянцев^W забытые инженерные логины там как обычно "случайно" забудут? :)

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

> Ну а вот у btrfs'а дурных "технических особенностей" заметно меньше.

с чего вы взяли? Я бы сказал, что у него их заметно больше. Проблемы вида "нет свободного места для метаданных", это ж надо такое удумать было. А пользоваться им не поверх аппаратной хранилки или рейда - вообще чур меня.

> По крайней мере, RAM гигами не жрет и не тормозит.

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

> С тех пор утекло много воды. В Linux с 92 года много чего переделали

а проблема с управлением памятью - здрасьте, вот она. Помню, еще в далеком 96м вокруг zoran плясали с бубном на те же темы (ему не годился "порежьте по 4k" подход). Но ему хотя бы не надо было уметь ее освобождать, поэтому проблема решилась совсем тривиальным костылем.

> Они просто считают ядро своей епархией и меняют апи и проч как им удобнее.

вы не владеете темой и опять пересказываете бабок у подъезда. Или лжете.

Они намеренно внесли изменение, ломающее сборку не gpl-кода с avx оптимизациями - ничего не меняющее в самом коде, просто метку для компилятора.
Это не "как им удобнее", а именно чтоб нагадить и более ни для чего.

И пытались судиться с теми, кто легко и просто обошел аналогичную проблему, добавив свою обертку с нужной меткой. Прocpaли, что характерно, но продолжают угрожать другим.


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

107. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +/
Сообщение от Anonymoustus (ok), 10-Янв-20, 13:18 
>> По крайней мере, RAM гигами не жрет и не тормозит.
> опять эти сказки. Молодой человек - либо вы заканчиваете бубнить эту мантру,
> либо я заканчиваю с вами общаться.
> Если файловая система не занимает ВСЮ свободную ram под кэш - это
> значит, что она неэффективна и даром насилует диск, ради чтения данных,
> которые только что уже один раз читала.
> Каким надо быть феерическим идиотом чтобы этого не понимать?

Так ты это про ынтерпрайз пишешь, а благожелательные и добропорядочные онлайновые прихожане церкви св. Линуса никакого ынтерпрайза отродясь в глаза не видели, им до таких проблем и задач попросту нет дела. А давайте, говорят, запилим что-то новое, а завтра ещё одно, а послезавтра третье — будет у нас модно, молодёжно и прогресс инноваций. Что с этим дальше делать — про это курятник, как показала жизнь за прошедшие четверть века, задумываться принципиально неспособен.

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

112. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +1 +/
Сообщение от пох. (?), 10-Янв-20, 13:55 
ынтырпрайс как раз переживет - выкинув половину рам в статике под кэш, и не задействуя оставшуюся ни для чего вообще. Даже и не заметит.

А вот на такой помойке -
Mem: 6028K Active, 29M Inact, 787M Wired, 157M Free
ARC: 375M Total, 79M MFU, 179M MRU, 3104K Anon, 1698K Header, 112M Other
Swap: 1024M Total, 38M Used, 986M Free, 3% Inuse

- попробуй-ка пожить, учитывая что вся ее задача как раз быстро-быстро отдавать с диска в сокет.
(но arc, смотрю, кто-то таки сожрал, он не ограничен, это кто-то отъел сегодня. Впрочем, тут abd не видно, скорее всего еще и в нем мегабайт триста)

> А давайте, говорят, запилим что-то новое

да ну нах, что у них там нового - приставка thin к lvm? lvm - разработка ibm 90х годов, xfs - sgi тех же 90х. Тут попатчено, там перепилено, как-то и работает.

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

164. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +/
Сообщение от Anonymoustus (ok), 10-Янв-20, 19:16 
>> А давайте, говорят, запилим что-то новое
> да ну нах, что у них там нового - приставка thin к
> lvm? lvm - разработка ibm 90х годов, xfs - sgi тех
> же 90х. Тут попатчено, там перепилено, как-то и работает.

«Запилим новое» в том смысле, что «никогда не доводим начатое дело до конца».

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

239. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +/
Сообщение от Аноним (-), 11-Янв-20, 10:03 
> «Запилим новое» в том смысле, что «никогда не доводим начатое дело до конца».

Знаешь такой анекдот, ответ на вопрос "когда же будет хорошо?". Вот тогда же можно сказать что довел дела до конца. И о софте примерно так же можно сказать.

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

220. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  –1 +/
Сообщение от Аноним (220), 11-Янв-20, 08:02 
> про это курятник, как показала жизнь за прошедшие четверть века, задумываться
> принципиально неспособен.

Как-то так оказалось что остальные - еще более не способны. Бсды - даже выкинутую подачку ассимилировать толком не могут. Не говоря о том чтобы самим что-то разработать. Ладно, за исключением NetBSD и hammerfs. Этот куда ни шел - но маргинален просто до жути.

Винды? MS как максимум смог выжать из себя ReFS. С большим отставанием, только для серверов и ... там даже близко не идет речь ни о каком паритете по фичам ни с btrfs ни с zfs, как я понимаю.

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

380. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +/
Сообщение от Anonymoustus (ok), 23-Янв-20, 19:57 
>> про это курятник, как показала жизнь за прошедшие четверть века, задумываться
>> принципиально неспособен.
> Как-то так оказалось что остальные - еще более не способны. Бсды -
> даже выкинутую подачку ассимилировать толком не могут. Не говоря о том
> чтобы самим что-то разработать. Ладно, за исключением NetBSD и hammerfs. Этот
> куда ни шел - но маргинален просто до жути.

Движение ради движения — это мастурбация. У движения должна быть цель, станция назначения. Все основные проекты семейства BSD движутся в направлении целей, обозначенных в их философских основаниях.


> Винды? MS как максимум смог выжать из себя ReFS. С большим отставанием,
> только для серверов и ... там даже близко не идет речь
> ни о каком паритете по фичам ни с btrfs ни с
> zfs, как я понимаю.

Каких тебе не хватает фич? Свистелок и перделок? Есть. Запускать винду на суперкомпьютерах? Но зачем?

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

198. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  –2 +/
Сообщение от VINRARUS (ok), 11-Янв-20, 01:23 
>Тут у zfs как 3d-party громадное преимущество, потому что ее я в любом случае смогу собрать отдельно, что бы там не нарешали разработчики дистрибутивов и вредители из lkml.

Шо, компилить ядро с нужными параметрами уже не модно в 2020 году?
>А пользоваться им не поверх аппаратной хранилки или рейда - вообще чур меня.

Ну и чем корова ZFS принцыпиально отличается от коровы btrfs?
>Если файловая система не занимает ВСЮ свободную ram под кэш - это значит, что она неэффективна и даром насилует диск, ради чтения данных, которые только что уже один раз читала.
>Каким надо быть феерическим идиотом чтобы этого не понимать?

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

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

363. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +/
Сообщение от Аноним (-), 14-Янв-20, 13:24 
> Это ФС-паразит, а не эфективность.

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

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

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

199. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +2 +/
Сообщение от Аноним (-), 11-Янв-20, 01:34 
> причем тут - энтерпрайс? Энтер-прайс он у орацла,

У орацла - база. Остальное их интересовало клиентурой.

> у того в соляре с zfs все нормально, она развивается - все последние серьезные улучшизмы
> в zol - cleanroom имплементации того, что уже было сделано орацлом

Орацл на zfs клал - разработчики разбежались. На соляру и подавно. В unbreakable за них вообще другие пашут. Дешево и сердито.

> (правда, изменять на ходу конфигурацию vdev так и ниасилили).

zfs в линухе внеядерный выкидыш, нормально он там не будет если чуда не произойдет, а оракл такие чудилы... с ОО учудили уже :)

> Разьве что судьба самой соляры печальна.

Стандартная судьба проприетарного энтерпрайза и такихприборов.

> - оно и пошло вразнос.

Ожидалось чего-то еще? Откуда в проприетарном проекте инфраструктура и взаимодействия после того как корпоративное из-под ног ушло? Там сообщества _кодеров_ и _майнтайнеров_ никогда не было. Это не появляется только потому что какая-то компания решила, наконец, с лопаты.

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

Чисто технически - ссыкотного не больше чем в других ФС. А если брать шляпу под нечто файлопомойное - это наверное сыкотно само по себе. У шляпы вообще кто-то видный остался по ФС и блочным делам? Они XFS то ухватили лишь потому что остальное разобрали до них, а этот валялся всеми брошеный. В нем ничего интересного не было. Ну не JFS же было брать?! И таки они врядли что-то смогут сделать с проблемами нижнего уровня нагнав пихтонрасов. В btrfs низкоуровневая структура ФС сильно подыгрывает вещам типа device remove или смене уровня raid на лету, нагоном пихтонрасов такие вещи не фиксятся.

> А ваш божок точно так же заявит что "don't use btrfs",

Да чего б ему? В btrfs ядерщики вменяемые, проблем не создают, facilities ядра юзают, вплоть до алгоритмов raid/хэшей/...  из ядерных модулей, изменения апи трекают вовремя, все дела. Свой менеджмент кэша не городят. Так что если он сам и не станет юзать, то уж договориться с _этими_ всегда сможет. И оно будет жить долго и счастливо, до тех пор пока это хоть кому-то надо. А когда станет никому не надо - ну значит время технологии уже вышло, к этому моменту обычно есть толпа вариантов лучше. Ну как с удалением поддержки 80386, кто ж им всерьез пользуется то ща с линухом? :)

> и "по данным, высосанным из моего пальца, я не вижу высокой производительности".

Торвальдсу на это, пока оно не трансформируется в его проблемы... А оно не трансформируется - майнтайнеры этой штуки в курсе dos и donts, в отличие от шишкиных и zfslol'ов, фигарящих на своей волне и плюющих на инфраструктуру кернела.

А вот когда какие-то zfslol'ы начинают верещать потому что видите ли не в курсе изменений в новом ядре и их ВНЕЗАПНО снес с переезда экспресс (хотя красный мигал полчаса специально для таких) - вот тут они получают предсказуемую порцию лулзов и коментов.

> Тут у zfs как 3d-party громадное преимущество, потому что ее я в
> любом случае смогу собрать отдельно, что бы там не нарешали разработчики
> дистрибутивов и вредители из lkml.

Ну во первых, "вредители" из lkml не просили их ядро юзать. Ты сам приперся, их не спросил.
Во вторых, ежели они что-то поменяют, не факт что соберется и не факт что будет работать и тем более - корректно.
В третьих, это - не проблемы чуваков из lkml. Они как ты уже понял себе не враги и таким не пользуются. И никогда никому не обещали что левые модули будут работать и тем более хорошо. Так что вон там фаны нвидии рядом с zfs'никами с дедлоками маются. А саппорт у них в сполтлото, в lkml не будет в проблемах tainted kernel'ов копаться. Скажут contact your supplier и правильно сделают.

По поводу чего - если кто фигарит в unsupported конфиге, он и майнтайнит ее сам, не жалуясь в lkml. Кто-то размером с шапку так даже немного может. С кучей особенностей и ограничений. Так что белое не надевать и обтягивающее не носить.

> это проблемы васянов, непонятно откуда укравших полку. У нормальных людей забытый инженерный
> логин постороннему просто некуда вводить.

На этом глобусе нормальных людей немного. Так что даже у кондовых энтерпрайзов хватает забавной лажи.

> Отдельный вопрос - а что может сделать инженер, имеющий этот логин (ну кроме как
> неудачно обрушить хранилку).

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

> А то мы их при необходимости техподдержки спокойно раздаем.

Да просто всякие мутные проприетарные железки народ уже основательно достали, если кто не заметил. Те кто покрупнее на этой почве уже себе стали сами запиливать роутеры, серваки, ... блин да тут даже россияне уже что-то такое пиндели про то что закупки только отечественных хранилок. Правда судя по сайтику с интеграсерами это "как обычно", но дотикало даже до этих уже.

>> Ну а вот у btrfs'а дурных "технических особенностей" заметно меньше.
> с чего вы взяли? Я бы сказал, что у него их заметно больше.

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

> Проблемы вида "нет свободного места для метаданных", это ж надо такое удумать было.

Эти проблемы устранили много лет назад. Вплоть до того что сделали небольшой неприкосновенный "золотой резерв" на совсем уж пиковые случаи.

Если уж так ерничать, шапкин XFS в лохматых ядрах данные нулями при крахе протирал, убивая файлы наповал. Более того - ему до сих пор пофиг на то что с данными при крахе будет. Если btrfs просто забудет о неудавшихся записях, откинув проблемные изменения данных и метаданных и файл по крайней мере будет в логически консистентном виде, то в XFS он может быть наполовину старым и наполовину новым и тогда ему вообще крышка - такое может вообще не прочитаться программой юзавшей этот файл. Особо прошареные типа баз конечно сами журналят на такой случай, но вот какой-нибудь офисный/кадовский документик, сорц, фоточка там какая - уже упсь!

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

А смысл такой конфигурации?! При этом уже не получится легко и ненапряжно менеджить стораж btrfs'ными тулсами, половина пойнта btrfs теряется. Конечно остается сжатие, рефлинки, снапшоты и прочее, но вот при нужде переконфигурить стораж гимора уже стандартный объем. По сравнению с просто прицепить/отцепить и сказать btrfs device add/remove и как максимум ребаланс пнуть (это опционально, делается на лету и можно в период минимальной нагрузки например неспешно запустить) - такое уже не возбуждает.

> Если файловая система не занимает ВСЮ свободную ram под кэш - это
> значит, что она неэффективна и даром насилует диск, ради чтения данных,
> которые только что уже один раз читала.

Есть некая разница между "ядро займет всю память под кэш" и "файловая система займет память под кэш". Когда ФС это через facilities ядра делает, ядро с собой может договориться по быстрому и при нужде резко отобрать это под нужды программ.

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

> Каким надо быть феерическим идиотом чтобы этого не понимать?

Дьявол как всегда в деталях. У btrfs'а ядро может дисковый кэш по необходимости конфисковать в темпе вальса не хуже чем у ext'ов, xfs или кого там еще - через те же самые facilities. Поэтому оно годится не только для файлопомоек, но и любых иных систем. А zfs как я понимаю не хочет интегряться с ядерными facilities нормально.

> далеком 96м вокруг zoran плясали с бубном на те же темы
> (ему не годился "порежьте по 4k" подход). Но ему хотя бы
> не надо было уметь ее освобождать, поэтому проблема решилась совсем тривиальным костылем.

Линуксоиды с 96 года по части памяти наворотили хоть там что. Но вообще, если какая-то штука типа ФС хочет именно большой, именно непрерывный кус физической памяти - ее место в утиле, за то что не смогли в фичи ядра.

И если для файлопомойки это не проблема, то вот в произвольно взятой системе бывают и другие желающие на большой непрерывный кус памяти. Железки там всякие, например. И если софт можно и подвинуть, припахав делать scatter-gather, при том даже не самому а через facilities ядра, то вот в железках это уже данность. И оно либо получит что хотело, либо не сможет работать. Файлохранилке это может и пофиг, а вот остальным...

Нисколько не сомневаюсь что ядерщики бы с удовольствием отправили в биореактор ВСЕХ кто выдвигает такие требования. Но уже выпущенные железки это не уберет, так что смысл?

> вы не владеете темой и опять пересказываете бабок у подъезда.

У меня правильные бабки у правильного подъезда, git log -p которые. Даже и не знаю где более правильные бабки водятся.

> Или лжете.

В каком месте? Линуксные ядерщики всегда говорили прямым текстом что их гарантии касаются только внешних интерфейсов для юзермода. А унутрях они по границам подсистем могут перепахать полядра к ряду между версиями.

Как конкретный пример, они на xarray перетряхнули вообще тупо все ядро, по всей площади. Вот тупо ВСЕХ юзеров заменяемого апи. Ах да, если какие-то внешние модули это юзали и отвалились - ядерщики про это вообще не узнали в этом процессе.

> Они намеренно внесли изменение, ломающее сборку не gpl-кода с avx оптимизациями -
> ничего не меняющее в самом коде, просто метку для компилятора.

Упомянутое является довольно деликатным взаимодейтсвием. И если оно отъезжает - так, по чесноку, жаловаться надо вообще в спортлото. Те кто на такие вещи закладывается - знал на что шел. И если он внеядерный выкидыш - ему вообще грех на что-то жаловаться.

> Это не "как им удобнее", а именно чтоб нагадить и более ни для чего.

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

> И пытались судиться с теми, кто легко и просто обошел аналогичную проблему,
> добавив свою обертку с нужной меткой. Прocpaли, что характерно, но продолжают
> угрожать другим.

Ну как бы кроме судов есть и чисто технические методы показать фак. Так что у нвидии юзеры уже полгода наверное ноют с непонятными дедлоками, теперь вот эти еще... а всеж мысль о том что добро должно быть с кулаками имеет некий пойнт.

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

286. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  –2 +/
Сообщение от пох. (?), 11-Янв-20, 23:47 
> Ну как бы кроме судов есть и чисто технические методы показать фак.

после этого всю предыдущую писанину могли бы и стереть - потому что она очевидное вранье.
Продолжайте оправдывать намеренно гадящих окружающим.

И да, у вашего "добра", если вы не в курсе, есть хозяева.

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

299. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +2 +/
Сообщение от Аноним (-), 12-Янв-20, 06:48 
Давай я тебе просто процитирую немного Шекспира в подлиннике? Из соседнего сообщения в том треде? :)


The fact is, the whole point of the GPL is that you're being "paid" in terms of tit-for-tat: we give source code to you for free, but we want source code improvements back. If you don't do that but instead say "I think this is _legal_, but I'm not going to help you" you certainly don't get any help from us.

So things that are outside the kernel tree simply do not matter to us. They get absolutely zero attention. We simply don't care. It's that simple.

Мне по-моему кажется что тут все просто и понятно как железобетонный блок, не? Заметь, это - точка зрения менеджера проекта. Если ты с этим не согласен, тебе, очевидно, не следует пользоваться таким проектом. Потому что врядли ты сможешь переспорить руководителя проекта на чисто техническом уровне. Теоретически, ты еще форкануться можешь и показать мастер-класс, но на хотя-бы жалкое подобие Торвальдса ты не похож. У тебя decision making какой-то глючный, иррациональный и вообще не нацелен на достижение результата. Поэтому за перспективы прожЭкта который будешь манеджить ты - я не дам ни цента.

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

289. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  –1 +/
Сообщение от pansa2email (?), 12-Янв-20, 01:01 
>правда, изменять на ходу конфигурацию vdev так и ниасилили

Фига, в соляре можно менять конфигурацию vdev? Да еще и на лету? Чой-то не совсем представляю, как это вообще возможно, вроде как vdev невозможно менять после создания. Что именно подразумевается про конфигурацию?
Или если перепутали с pool/dataset, то в ZoL это тоже можно, лично игрался в рхел7 с параметрами компрессии, recordsize ,etc.

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

321. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +/
Сообщение от pansa2email (?), 12-Янв-20, 15:12 
>правда, изменять на ходу конфигурацию vdev так и ниасилили

Фига, в соляре можно менять конфигурацию vdev? Да еще и на лету? Чой-то не совсем представляю, как это вообще возможно, вроде как vdev невозможно менять после создания. Что именно подразумевается про конфигурацию?
Или если перепутали с pool/dataset, то в ZoL это тоже можно, лично игрался в рхел7 с параметрами компрессии, recordsize ,etc.

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

143. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +1 +/
Сообщение от имя (ok), 10-Янв-20, 16:14 
> Там надо разобраться с фатальным неумением линуха выделять большие блоки памяти эффективным образом, уходящим в тот же 92й год

Я всё ещё жду рассказов от знатоков солярок о том, чем их реализация SLAB отличается от линуксовой.

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

208. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +/
Сообщение от Аноним (208), 11-Янв-20, 04:51 
> Я всё ещё жду рассказов от знатоков солярок о том, чем их реализация SLAB отличается от линуксовой.

SLAB-ы они как раз для мелких аллокаций, до страницы размером придуманы. А у линуха проблемы именно с большими. Для того костыль под названием abd и был прикручен к zfs, чтобы лезть непосредственно в SLAB а не в общесистемный malloc

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

191. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +/
Сообщение от Аноним (191), 10-Янв-20, 22:45 
<trollmode>В эрланг же!</trollmode>
Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

71. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +/
Сообщение от Наме (?), 10-Янв-20, 11:47 
Что в ней такого хорошего? Не вижу вообще никаких причин для восторгов. Есть старый XFS, которого более чем достаточно для самых заковыристых случаев.
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

118. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +/
Сообщение от имя (ok), 10-Янв-20, 14:43 
Заковыристый случай — это когда после резкого ребута из-за внезапного unrecoverable ECC нужно руками сделать хитрую и неочевидную последовательность действий, чтобы не обнулить содержимое файлов? Да, XFS для этого более чем достаточно.
Ответить | Правка | Наверх | Cообщить модератору

211. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +/
Сообщение от Аноним (211), 11-Янв-20, 07:29 
> Заковыристый случай — это когда после резкого ребута из-за внезапного unrecoverable
> ECC нужно руками сделать хитрую и неочевидную последовательность действий, чтобы не
> обнулить содержимое файлов? Да, XFS для этого более чем достаточно.

Это вроде более-менее починили наконец. Впрочем, полный журнал оно все-равно не умеет. Так что теперь при таком вы просто получите файл из старой и новой половинок. СУБД какая в таком случае может даже и откатится из своего журнала. А все остальные...

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

186. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +/
Сообщение от Gannetemail (ok), 10-Янв-20, 22:09 
Старый добрый, который не умеет уменьшаться.
Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

98. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  –2 +/
Сообщение от bOOster (ok), 10-Янв-20, 13:02 
С чего бы ZFS умирает? Умирает с такой политикой Linux как Энтерпрайз хранилка отмирает. В серьезных продуктах Qnap например давно переехал на FreeBSD/ZFS и все там хорошо.
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

176. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +/
Сообщение от Аноним (176), 10-Янв-20, 21:30 
> серьезные продукты Qnap

Cпасибо, поржал.

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

206. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  –1 +/
Сообщение от Lefsha (ok), 11-Янв-20, 04:49 
> с невключением в ядро отталкивает многих пользователей...

Почему у меня оно включено в ядро, а у Вас нет?
Почему меня интересует возможности FS и ее стабильность, а Вас какие-то слухи?

Линус сморозил чушь. И это его право как человека.

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

369. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +/
Сообщение от Аноним (-), 15-Янв-20, 13:45 
Это потому что сама политика 'включать в ядро' порочна. Драйверы под винду прекрасно чувствуют себя и без включения в ядро винды
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

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

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




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

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