> причем тут - энтерпрайс? Энтер-прайс он у орацла, У орацла - база. Остальное их интересовало клиентурой.
> у того в соляре с 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ли, что характерно, но продолжают
> угрожать другим.
Ну как бы кроме судов есть и чисто технические методы показать фак. Так что у нвидии юзеры уже полгода наверное ноют с непонятными дедлоками, теперь вот эти еще... а всеж мысль о том что добро должно быть с кулаками имеет некий пойнт.
