Чому JFS настільки незрозумілий?

Коли я вперше почав користуватися Slackware років тому, я швидко навчився любити JFS через ext3 або reiserfs, враховуючи, що це надійно, і якщо було нечисте відключення, перевірка його диска була дуже швидкою. Лише нещодавно я дізнався, що JFS незрозумілий до того, що хтось майже повністю не підтримує.

Я не мав уявлення, що я в такій меншості. Чому так сталося? Це технологія файлової системи з тих пір просунулася до того, що JFS тепер не має порівняльних переваг? Хіба що ext3 був більш сумісним з іншими операційними системами? Чи була благословлена ​​певна інша файлова система певним постачальником або розробниками ядра?

Не стільки технічне питання, скільки історичне.

Перше, що вам доведеться вийти з шляху, - це порівняння з ext [234] . Заміна будь-якого з них буде подібно до заміни NTFS у Windows. Можливо, звичайно, але це вимагатиме рішення зверху про перехід.

Я знаю, що ви питаєте про збереження існуючих альтернатив, а не про усунення інших альтернатив, але ця привілейована конкуренція висмоктує більшу частину кисню в кімнаті. Поки ви не позбудетесь від конкуренції, маргінальним альтернативам буде надзвичайно важко отримати будь-яку увагу.

Оскільки ext [234] не піде, JFS та його ілк з самого початку знаходяться в серйозному неблагополучному стані.

(Це явище називається тиранією за замовчуванням.)

Друга річ - те, що і JFS, і XFS були внесені в Linux приблизно в один і той же час, і вони в значній мірі вирішують одні і ті ж проблеми. Гір ядер може сперечатися про точні точки між ними, але факт полягає в тому, що ті, хто зіткнувся з одним із обмежень ext [234] , мали два приблизно рішучі рішення у XFS та JFS.

То чому XFS виграв? Я не впевнений, але ось деякі спостереження:

• Red Hat та SuSE схвалили його.

  RHEL 7 використовує XFS як свою файлову систему за замовчуванням, і це був варіант встановлення часу в RHEL 6. Після виходу RHEL 6 Red Hat підтримував офіційну підтримку XFS до RHEL 5. XFS був доступний для RHEL 5 до цього через напівофіційну Канал EPEL .

  SuSE включив XFS як опцію встановлення набагато раніше, ніж Red Hat, повернувшись до SLES 8 , випущеного в 2002 році. Це не поточний дефолт, але він офіційно підтримується весь цей час.

  Є багато інших дистрибутивів Linux, і RHEL і SuSE не є найбільш популярними збірками по всій Linux простору, але вони є як великі залізними збірками вибору. Вони грають там, де переваги JFS та XFS мають найбільше значення. Ці компанії не завжди можуть зависати собакою, але в питаннях, пов'язаних з великим залізом, вони іноді можуть.

• XFS походить від SGI - компанії, яка по суті вже не працює. Перед тим, як вони померли, вони офіційно передали будь-які права на XFS, тому людям Linux було комфортно, включивши його в ядро.

  IBM також наділила достатньо прав на JFS, щоб зробити зручними сервісні сервіси Linux, але ми не можемо забути, що вони є активною багатомільярдовою компанією з тисячами патентів. Якщо IBM коли-небудь вирішив, що їх підтримка Linux більше не відповідає її інтересам, то це може стати некрасивим.

  Звичайно, хтось, мабуть, володіє правами інтелектуальної власності SGI зараз і міг би суєту, але це, мабуть, не виявиться гірше, ніж дебакл ШОС . IBM може навіть важити і допомогти сквошу такого троля, оскільки їх інтереси роблять в даний час включає в себе підтримку Linux.

  Справа в тому, що XFS просто відчуває себе більш "вільним" для багатьох людей. Менш ймовірно, що виникне якась майбутня проблема з IP. Одна з проблем нашої нинішньої системи ІР полягає в тому, що авторські права пов'язані з життям компанії, а компанії зазвичай не гинуть. Ну, SGI зробив. Це змушує людей почувати себе краще ставитися до внеску SGFS від SGI, як до внеску будь-якої людини.

• У будь-якій системі, що стосується мережевих ефектів, де у вас є дві приблизно еквівалентні альтернативи - JFS та XFS в цьому випадку - ви майже ніколи не ділите 50/50 ринкової частки.

  Тут мережеві ефекти - це навчання, сумісність, доступність функцій ... Ці ефекти підштовхують рівновагу все далі і далі до варіанту, який здобув таку ранню перемогу. Свідки Windows проти OS X, Linux проти всіх інших-* ix, Ethernet проти Token Ring ...

Як хтось, хто широко працював з JFS в Linux і занурився у вихідний код, щоб виправити проблеми, я можу припустити кілька причин:

1. JFS - це порт файлової системи, створений для AIX, потім перенесений в OS / 2, а потім відкритий ресурс. У ньому ніхто з розробників AIX не працює, оскільки існує ризик зараження кодом, а OS / 2 не розроблявся досить довго.
2. З моменту читання коду та після розробки JFS я побачив безліч проблем у коді (одна з них - невдало зміни розміру FS на машинах big-endian, тобто тих, які були зроблені IBM), які були виправлені проектом і не були об'єдналися в основне ядро ​​навіть через місяці після виправлення, ймовірно, через те, що розробники IBM офіційно не були обслуговуючими цієї частини дерева.
3. У коду є чимало проблем з читабельністю, що, ймовірно, сприяло відсутності офіційної підтримки дистрибутивів, оскільки важко прочитати код, який важко відладкувати.
4. Я припускаю, що одним з головних застосувань на початку JFS для Linux було міграція інформації та обмін інформацією з системами AIX, але в AIX5L не було (підтримується) варіанту використання файлової системи на простому диску без власного LVM, використовуваного AIX, який не був доступний для Linux, і JFS був розширений без перенесення цих розширень до Linux (див. Номер 1).

Пояснення: Незважаючи на те, що працював у IBM в минулому, я ніколи не був членом команди розробників IBM AIX або команди розробників JFS, і ці припущення засновані на моїй логічній дедукції та знайомстві з історією файлової системи та Linux.