Հրապարակվել է Reiser4 ֆայլային համակարգի մշակող Էդուարդ Շիշկինի հետ երկրորդ հարցազրույցը։
Սկսելու համար խնդրում ենք ընթերցողներին հիշեցնել, թե որտեղ և ում համար եք աշխատում:
Ես աշխատում եմ որպես հիմնական պահեստավորման ճարտարապետ Huawei Technologies-ում, գերմանական հետազոտական կենտրոնում: Վիրտուալացման բաժնում ես զբաղվում եմ տվյալների պահպանման տարբեր ասպեկտներով: Իմ գործունեությունը կապված չէ կոնկրետ օպերացիոն համակարգի հետ։
Դուք ներկայումս հավատարիմ եք մնում միջուկի հիմնական ճյուղին:
Շատ հազվադեպ, և միայն այն դեպքում, եթե իմ գործատուն դա պահանջի: Վերջին անգամ եղել է մոտ երեք տարի առաջ, ես ուղարկել եմ patches՝ ավելացնելու համար հոսթինգների վրա համօգտագործվող պահեստավորման թողունակությունը՝ օգտագործելով 9p արձանագրությունը (այս բիզնեսի մեկ այլ անուն VirtFS է): Այստեղ պետք է մի կարևոր նշում անել. չնայած ես երկար ժամանակ աշխատում եմ Linux-ով, բայց երբեք դրա սիրահար չեմ եղել, այսինքն՝ «հավասարաչափ շնչում եմ», ինչպես մնացած ամեն ինչում։ Մասնավորապես, եթե թերություն եմ նկատում, առավելագույնը մեկ անգամ կարող եմ դա մատնանշել։ Եվ որպեսզի հետո կարողանաք հետևել որևէ մեկին և համոզել նրան, դա տեղի չի ունենա:
Հիշում եմ, նախորդ անգամ, տասը տարի առաջ, դուք բավականին քննադատում էիք միջուկի մշակման ոճը: Ձեր (կամ գուցե կորպորատիվ) տեսանկյունից՝ ինչ-որ բան փոխվե՞լ է, համայնքն ավելի արձագանքո՞ւմ է, թե՞ ոչ: Եթե ոչ, ապա ձեր կարծիքով ո՞վ է մեղավոր։
Ես երբեք փոփոխություններ չեմ տեսել դեպի լավը: Համայնքի հիմնական խնդիրը գիտության փոխարինումն է քաղաքական տեխնոլոգիաներով, անձնական հարաբերություններով, մեծամասնության կարծիքով, պոպուլիզմով, «ներքին ձայների» խորհուրդներով, փտած փոխզիջումներով, գիտությունից բացի որևէ այլ բանով։ Համակարգչային գիտությունը, ինչ էլ ասես, նախ և առաջ ճշգրիտ գիտություն է: Եվ եթե ինչ-որ մեկը սկսում է հայտարարել իր սեփական արժեքը 2x2-ի համար, 4-ից տարբերվող, «Linux way» դրոշի ներքո կամ որևէ այլ դրոշի ներքո, ապա դա դժվար թե այլ բան բերի, քան վնաս:
Բոլոր անախորժությունները առաջին հերթին պայմանավորված են որոշումներ կայացնողների ոչ կոմպետենտության և անկրթության պատճառով։ Եթե ղեկավարն անկարող է, նա ի վիճակի չէ օբյեկտիվ, ադեկվատ որոշում կայացնել։ Եթե նա նույնպես անմշակույթ է, ապա չի կարողանում գտնել իրավասու մասնագետ, ով նրան ճիշտ խորհուրդ կտա։ Մեծ հավանականությամբ ընտրությունը կկատարվի խաբեբաի վրա, ով ասում է «թվացյալ ճիշտ բաներ»: Կոռումպացված միջավայրը միշտ զարգանում է ոչ կոմպետենտ միայնակ առաջնորդների շուրջ։ Ավելին, պատմությունն այս առումով բացառություններ չի ճանաչում, և համայնքը դրա ամենավառ հաստատումն է։
Ինչպե՞ս եք գնահատում Btrfs-ի զարգացման առաջընթացը: Այս FS-ն ազատվե՞լ է մանկական հիվանդություններից: Ինչպե՞ս եք այն դնում ձեզ համար՝ որպես FS «տան համար», թե՞ նաև կորպորատիվ օգտագործման համար:
Ես չազատվեցի դրանից։ Այն ամենը, ինչ ես նշեցի 11 տարի առաջ, այսօր էլ արդիական է։ Btrfs-ի խնդիրներից մեկը, որն այն դարձնում է ոչ պիտանի լուրջ կարիքների համար, ազատ տարածության խնդիրն է: Էլ չեմ խոսում այն մասին, որ օգտատիրոջը խնդրում են վազել խանութ նոր սկավառակի համար այն իրավիճակներում, երբ ցանկացած այլ FS-ը մեծ ազատ տարածություն ցույց կտա բաժանման վրա: Ազատ տարածության բացակայության պատճառով տրամաբանական ծավալով գործողություն ավարտելու անկարողությունը նույնպես ամենավատը չէ: Ամենավատն այն է, որ ոչ արտոնյալ օգտվողը կարող է գրեթե միշտ, շրջանցելով սկավառակի ցանկացած քվոտա, բավականին կարճ ժամանակում բոլորին զրկել ազատ տարածությունից:
Այն կարծես սա է (փորձարկվել է Linux միջուկի 5.12-ի համար): Թարմ տեղադրված համակարգի վրա գործարկվում է սկրիպտ, որը ցիկլով ստեղծում է որոշակի անուններով ֆայլեր հիմնական գրացուցակում, գրում է տվյալներ դրանց վրա որոշակի օֆսեթներով և այնուհետև ջնջում այդ ֆայլերը: Այս սցենարը գործարկելուց մեկ րոպե հետո ոչ մի արտասովոր բան տեղի չի ունենում: Հինգ րոպե անց միջնորմի վրա զբաղեցրած տարածության բաժինը մի փոքր ավելանում է: Երկու-երեք ժամ հետո այն հասնում է 50% -ի (նախնական արժեքով 15%): Եվ հինգ կամ վեց ժամ աշխատելուց հետո սցենարը խափանում է «բաժանման վրա ազատ տարածություն չկա» սխալով: Դրանից հետո դուք այլևս չեք կարող նույնիսկ 4K ֆայլ գրել ձեր բաժանման վրա:
Հետաքրքիր իրավիճակ է առաջանում. վերջում դուք ոչինչ չգրեցիք բաժանման վրա, և ամբողջ ազատ տարածքը (մոտ 85%) ինչ-որ տեղ անհետացավ: Նման հարձակման ենթակա հատվածի վերլուծությունը կբացահայտի բազմաթիվ ծառերի հանգույցներ, որոնք պարունակում են ընդամենը մեկ տարր (բանալինով հագեցած օբյեկտ)՝ մի քանի բայթ մեծությամբ: Այսինքն, բովանդակությունը, որը նախկինում զբաղեցնում էր սկավառակի տարածության 15% -ը, պարզվեց, որ հավասարապես «քսված» է ամբողջ բաժանման վրա, որպեսզի նոր ֆայլ գրելու տեղ չկա, քանի որ դրա բանալին ավելի մեծ է, քան բոլոր գոյություն ունեցողները, իսկ անվճարը: բաժանման բլոկները սպառվել են:
Ավելին, այս ամենն արդեն տեղի է ունենում Btrfs-ի հիմնական կոնֆիգուրացիայի վրա (առանց նկարների, ենթածավալների և այլն), և կարևոր չէ, թե ինչպես եք որոշել ֆայլերի մարմինները պահել այդ FS-ում (որպես «բեկորներ» ծառի վրա կամ որպես չափումներ: չֆորմատավորված բլոկների) - վերջնական արդյունքը կլինի նույնը:
Դուք չեք կարողանա նման հարձակման ենթարկել այլ ֆայլային համակարգերի (անկախ նրանից, թե ինչ են ձեզ ասում): Ես վաղուց բացատրեցի խնդրի պատճառը. սա Btrfs-ում B-tree հայեցակարգի ամբողջական այլասերումն է, ինչը հնարավորություն է տալիս դրա ինքնաբուխ կամ միտումնավոր այլասերումը: Մասնավորապես, որոշակի բեռների դեպքում ձեր ֆայլային համակարգը շարունակաբար «կփլվի» ինքնուրույն աշխատանքի ընթացքում՝ առանց արտաքին օգնության: Հասկանալի է, որ բոլոր տեսակի «սեղմող» ֆոնային գործընթացները կփրկեն օրը միայն առանձին աշխատասեղանների վրա:
Կոլեկտիվ սերվերների վրա հարձակվողը միշտ կկարողանա «առաջ անցնել» նրանցից: Համակարգի ադմինիստրատորն անգամ չի կարողանա որոշել, թե կոնկրետ ով է իրեն ահաբեկել: Btrfs-ում այս խնդիրը շտկելու ամենաարագ ճանապարհը սովորական B-ծառի կառուցվածքի վերականգնումն է, այսինքն. սկավառակի ձևաչափի վերափոխում և Btrfs կոդի զգալի մասերի վերագրանցում: Դա կտևի 8-10 տարի, ներառյալ վրիպազերծումը, պայմանով, որ մշակողները խստորեն հետևեն համապատասխան ալգորիթմների և տվյալների կառուցվածքի բնօրինակ հոդվածներին և չխաղան «կոտրված հեռախոս» խաղը, ինչպես ընդունված է (և խրախուսվում է) «Linux»-ում։ ճանապարհը»:
Այստեղ մենք նույնպես պետք է ավելացնենք այն ժամանակը, որն անհրաժեշտ է ծրագրավորողներին այս ամենը հասկանալու համար։ Այստեղ է, որ ավելի դժվար է դառնում: Ամեն դեպքում, 10 տարին քիչ էր, որ հասկանային։ Դե, մինչ այդ դուք չեք կարող հույս ունենալ հրաշքի վրա: Դա տեղի չի ունենա մոնտաժային տարբերակի տեսքով, «որի մասին դուք և ես չգիտեինք», կամ կարկատանի տեսքով, որը պատրաստելը «ուղղակի բիզնեսի խնդիր է»: Յուրաքանչյուր նման հապճեպ «ֆիքսման» համար ես կներկայացնեմ դեգեներացիայի նոր սցենար։ B-trees-ը իմ ամենասիրած թեմաներից է, և պետք է ասեմ, որ այդ կառույցները չեն հանդուրժում ազատություններն իրենց հետ:
Ինչպե՞ս կարող եմ դիրքավորել Btrfs-ը ինձ համար: Որպես մի բան, որը բացարձակապես չի կարելի անվանել ֆայլային համակարգ, առավել ևս օգտագործված: Քանի որ, ըստ սահմանման, FS-ը ՕՀ ենթահամակարգ է, որը պատասխանատու է «սկավառակի տարածքի» ռեսուրսի արդյունավետ կառավարման համար, ինչը մենք չենք տեսնում Btrfs-ի դեպքում: Դե պատկերացրեք, որ դուք եկել եք խանութ ժամացույց գնելու, որպեսզի չուշանաք աշխատանքից, իսկ ժամացույցի փոխարեն ձեզ վաճառել են առավելագույնը 30 րոպե ժամանակաչափով էլեկտրական գրիլ։ Այսպիսով, Btrfs-ի հետ կապված իրավիճակը ավելի վատ է:
Փոստային ցուցակները նայելով, ես հաճախ հանդիպում եմ այն հայտարարությանը, որ սկավառակի տարածքի արդյունավետ կառավարումն այլևս տեղին չէ սկավառակների էժանության պատճառով: Սա կատարյալ անհեթեթություն է։ Առանց սկավառակի տարածության արդյունավետ կառավարչի, ՕՀ-ն կդառնա խոցելի և անօգտագործելի: Անկախ ձեր մեքենայի սկավառակների հզորությունից:
Ես կցանկանայի մեկնաբանություն խնդրել RHEL-ում Btrfs-ի աջակցության դադարեցման վերաբերյալ:
Այստեղ մեկնաբանելու առանձնահատուկ բան չկա, ամեն ինչ շատ պարզ է։ Նրանք դա ունեին նաև որպես «տեխնոլոգիական նախադիտում»: Այսպիսով, ես չեմ անցել այս «նախադիտումը»: Թույլ մի տվեք, որ այս պիտակը հավերժ մնա: Բայց նրանք չեն կարող թողարկել թերի նախագծային արտադրանք՝ լիարժեք աջակցությամբ: RHEL-ը ձեռնարկություն է, այսինքն՝ սահմանված ապրանքա-դրամական հարաբերություններ։ Red Hat-ը չի կարող ահաբեկել օգտատերերին, ինչպես դա անում են Btrfs փոստային ցուցակում: Պարզապես պատկերացրեք իրավիճակը. հաճախորդը, ով վճարել է իր դժվարությամբ վաստակած գումարը սկավառակի համար, ինչպես նաև դուք՝ աջակցության համար, ցանկանում է հասկանալ, թե որտեղ է մնացել իր սկավառակի տարածքը, երբ ոչինչ չի գրել: Ի՞նչ կպատասխանեք նրան սրան։
Հետագա. Red Hat-ի հաճախորդների թվում են հայտնի խոշոր բանկեր և փոխանակումներ: Պատկերացրեք, թե ինչ կլիներ, եթե նրանք ենթարկվեին DoS հարձակումների՝ հիմնվելով Btrfs-ում նշված խոցելիության վրա։ Ձեր կարծիքով ո՞վ է պատասխանատու սրա համար։ Նրանց, ովքեր պատրաստվում են մատնացույց անել GPL լիցենզիայի գծի վրա, որտեղ գրված է, որ հեղինակը ոչ մի բանի համար պատասխանատու չէ, ես անմիջապես կասեմ՝ «թաքցրե՛ք»: Կարմիր գլխարկը կպատասխանի, և այնպես, որ դա բավարար չթվա: Բայց ես գիտեմ, որ Red Hat-ը նման խնդրի չի բախվում՝ հաշվի առնելով QA-ի ինժեներների նրանց հատկապես ուժեղ թիմը, որոնց հետ ես հնարավորություն ունեցա սերտորեն աշխատել իմ ժամանակ:
Ինչո՞ւ են որոշ ընկերություններ շարունակում աջակցել Btrfs-ին իրենց ձեռնարկության արտադրանքներում:
Խնդրում ենք նկատի ունենալ, որ ապրանքի անվանման մեջ «ձեռնարկություն» նախածանցը շատ բան չի նշանակում: Ձեռնարկությունը պատասխանատվության չափանիշ է, որը ներառված է հաճախորդի հետ պայմանագրային հարաբերություններում: Ես գիտեմ միայն մեկ ձեռնարկության մասին, որը հիմնված է GNU/Linux-ի վրա՝ RHEL: Մնացած ամեն ինչը, իմ տեսանկյունից, ներկայացվում է միայն որպես ձեռնարկություն, բայց մեկը չէ։ Եվ վերջապես, եթե ինչ-որ բանի պահանջարկ կա, ապա առաջարկը միշտ կլինի (մեր դեպքում դա նշված «աջակցությունն» է)։ Բացարձակապես ամեն ինչի պահանջարկ կա, այդ թվում. և անօգտագործելի ծրագրեր: Թե ինչպես է ձևավորվում նման պահանջարկը և ով է այն սնուցում, այլ թեմա է։
Այսպիսով, ես չէի շտապի որևէ եզրակացություն անել այն բանից հետո, երբ լուրեր են պտտվում, որ Facebook-ն իր սերվերներում տեղակայել է Btrfs: Ավելին, խորհուրդ կտամ զգուշորեն գաղտնի պահել այդ սերվերների հասցեները վերը նշված պատճառներով։
Ինչո՞ւ են վերջերս այդքան մեծ ջանքեր գործադրվում XFS կոդը մաքրելու համար: Ի վերջո, ի սկզբանե սա երրորդ կողմի ֆայլային համակարգ է, և ext4-ը երկար ժամանակ կայուն է եղել և ունի շարունակականություն նախորդ նույնքան կայուն տարբերակներից: Ի՞նչ հետաքրքրություն ունի Red Hat-ը XFS-ի նկատմամբ: Արդյո՞ք իմաստ ունի ակտիվորեն զարգացնել երկու ֆայլային համակարգեր, որոնք նպատակներով նման են՝ ext4 և XFS:
Ես չեմ հիշում, թե ինչն է դա դրդել: Միանգամայն հնարավոր է, որ նախաձեռնությունը Red Hat-ի հաճախորդներից է եղել: Հիշում եմ, որ նման հետազոտություններ են իրականացվել. վերին հոսանքով որոշ ֆայլային համակարգերի վրա նոր սերնդի բարձրակարգ սկավառակների վրա ստեղծվել են հսկայական թվով օբյեկտներ: Ըստ արդյունքների՝ XFS-ն իրեն ավելի լավ է պահել, քան ext4-ը։ Այսպիսով, նրանք սկսեցին այն գովազդել որպես ամենահեռանկարային: Ամեն դեպքում, ես այստեղ ոչ մի սենսացիոն բան չէի փնտրի։
Ինձ համար ասես օճառը փոխարինել են օճառով։ ext4-ը և XFS-ը զարգացնելու իմաստ չկա: Ե՛վ զուգահեռ, և՛ դրանցից որևէ մեկը ընտրել: Սրանից ոչ մի լավ բան չի ստացվի։ Չնայած բնության մեջ հաճախ լինում են իրավիճակներ, երբ աճի մեծ ներուժ կա, բայց աճելու տեղ չկա։ Այս դեպքում առաջանում են տարաբնույթ տարօրինակ տգեղ նոր գոյացություններ, որոնց վրա բոլորը ցույց են տալիս մատը («Օ՜, տես, ինչ չես տեսնի այս կյանքում»):
Ի՞նչ եք կարծում, շերտի խախտման հարցը լուծվե՞լ է (բացասական իմաստով) ext4, F2FS-ում գաղտնագրման գործառույթների հայտնվելով (չասած Btrfs-ում RAID-ի մասին):
Ընդհանրապես, ցանկացած մակարդակների ներմուծումն ու դրանց չխախտման մասին որոշում կայացնելը սովորաբար քաղաքականության խնդիր է, և ես ստանձնում չեմ որևէ բան մեկնաբանել այստեղ։ Շերտի խախտման օբյեկտիվ ասպեկտները որևէ մեկին քիչ են հետաքրքրում, բայց մենք կարող ենք դրանցից մի քանիսը դիտարկել՝ օգտագործելով «վերևից» խախտման օրինակը, այն է, FS-ում այն ֆունկցիոնալության իրականացումը, որն արդեն գոյություն ունի բլոկի շերտում: Նման «խախտումը» արդարացված է միայն հազվադեպ բացառություններով։ Յուրաքանչյուր նման դեպքի համար նախ պետք է ապացուցել երկու բան՝ որ դա իսկապես անհրաժեշտ է, և որ դա անելով համակարգի դիզայնը չի տուժի։
Օրինակ, mirroring-ը, որն ավանդաբար եղել է բլոկի շերտի գործողություն, իմաստ ունի իրականացնել ֆայլային համակարգի մակարդակում: Տարբեր պատճառներով. Օրինակ, «լուռ» տվյալների կոռուպցիան (bit rot) տեղի է ունենում սկավառակի կրիչներում: Սա այն դեպքում, երբ սարքը ճիշտ է աշխատում, բայց բլոկի տվյալները անսպասելիորեն վնասվում են հեռավոր քվազարի արտանետվող կոշտ գամմա քվանտի ազդեցության տակ և այլն: Ամենավատն այն է, եթե այս բլոկը պարզվի, որ FS համակարգի բլոկ է (superblock, bitmap բլոկ, պահեստավորման ծառի հանգույց և այլն), քանի որ դա, անշուշտ, կհանգեցնի միջուկի խուճապի:
Խնդրում ենք նկատի ունենալ, որ բլոկ շերտի կողմից առաջարկվող հայելիները (այսպես կոչված RAID 1) ձեզ չեն փրկի այս խնդրից: Դե, իսկապե՞ս, ինչ-որ մեկը պետք է ստուգի չեկային գումարները և կարդա կրկնօրինակը ձախողման դեպքում: Բացի այդ, իմաստ ունի արտացոլել ոչ միայն ամեն ինչ, այլ միայն մետատվյալները: Որոշ կարևոր տվյալներ (օրինակ՝ կարևոր հավելվածների գործարկվող ֆայլերը) կարող են պահվել որպես մետատվյալներ։ Այս դեպքում նրանք ստանում են անվտանգության նույն երաշխիքները։ Իմաստ ունի մնացած տվյալների պաշտպանությունը վստահել այլ ենթահամակարգերի (գուցե նույնիսկ օգտագործողի հավելվածներին). մենք դրա համար ապահովել ենք բոլոր անհրաժեշտ պայմանները:
Նման «տնտեսական» հայելիները գոյության իրավունք ունեն, և դրանք կարող են արդյունավետ կազմակերպվել միայն ֆայլային համակարգի մակարդակով: Հակառակ դեպքում, շերտավորման խախտումը ենթահամակարգը խառնում է կրկնօրինակ կոդով՝ հանուն որոշ մանրադիտակային առավելությունների: Դրա վառ օրինակն է RAID-5-ի իրականացումը FS-ի միջոցով: Նման լուծումները (սեփական RAID/LVM ֆայլային համակարգում) սպանում են վերջինիս ճարտարապետական առումով։ Այստեղ պետք է նաև նշել, որ շերտավորման խախտումը «հոսում է» տարբեր տեսակի մարքեթինգային խաբեբաների կողմից: Գաղափարների բացակայության դեպքում ենթահամակարգերին ավելացվում է ֆունկցիոնալությունը, որը վաղուց իրականացվել է հարևան մակարդակներում, սա ներկայացվում է որպես նոր չափազանց օգտակար հատկություն և ակտիվորեն մղվում:
Reiser4-ին մեղադրել են «ներքևից» մակարդակները խախտելու մեջ։ Ելնելով այն հանգամանքից, որ ֆայլային համակարգը մոնոլիտ չէ, ինչպես բոլոր մյուսները, այլ մոդուլային, չհիմնավորված ենթադրություն է արվել, որ այն անում է այն, ինչ պետք է անի վերևի մակարդակը (VFS):
Կարելի՞ է խոսել ReiserFS v3.6-ի և, օրինակ, JFS-ի մահվան մասին։ Վերջին ժամանակներս նրանց հիմնական ուշադրությունը գրեթե չի արժանանում։ Արդյո՞ք դրանք հնացած են:
Այստեղ մենք պետք է սահմանենք, թե ինչ է նշանակում ծրագրային արտադրանքի մահը: Մի կողմից, դրանք հաջողությամբ օգտագործվում են (ի վերջո, հենց դրա համար են ստեղծվել), ինչը նշանակում է, որ նրանք ապրում են: Մյուս կողմից, ես չեմ կարող խոսել JFS-ի փոխարեն (ես շատ բան չգիտեմ), բայց ReiserFS-ը (v3) շատ դժվար է հարմարվել նոր միտումներին (փորձարկվել է գործնականում): Սա նշանակում է, որ ապագայում ծրագրավորողները ուշադրություն կդարձնեն ոչ թե դրա վրա, այլ նրանց, որոնց ավելի հեշտ է հարմարվել։ Այս կողմից պարզվում է, որ, ավաղ, ճարտարապետական առումով մեռած է։ Ես ընդհանրապես չէի շահարկի «բարոյապես հնացած» հասկացությունը։ Դա լավ է վերաբերում, օրինակ, զգեստապահարանին, բայց ոչ ծրագրային արտադրանքներին: Ինչ-որ բանում թերարժեքության և գերազանցության հասկացություն կա: Կարող եմ միանգամայն ասել, որ ReserFS v3-ն այժմ ամեն ինչով զիջում է Reiser4-ին, բայց որոշ տեսակի ծանրաբեռնվածության մեջ այն գերազանցում է բոլոր մյուս հոսանքային FS-ներին։
Գիտե՞ք FS Tux3 և HAMMER/HAMMER2 (FS DragonFly BSD-ի համար) մշակման մասին:
Այո, մենք գիտենք: Tux3-ում ես ժամանակին հետաքրքրված էի նրանց նկարների տեխնոլոգիայով (այսպես կոչված «տարբերակի ցուցիչներ»), բայց Reiser4-ում մենք, ամենայն հավանականությամբ, կգնանք այլ ճանապարհով: Ես երկար ժամանակ մտածում էի snapshot-ների աջակցության մասին և դեռ չեմ որոշել, թե ինչպես դրանք իրականացնել պարզ Reiser4 հատորների համար: Փաստն այն է, որ Օհադ Ռոդեհի կողմից առաջարկված «ծույլ» հղման հաշվիչի նորաստեղծ տեխնիկան գործում է միայն B-ծառերի համար: Մենք դրանք չունենք։ Այն տվյալների կառուցվածքների համար, որոնք օգտագործվում են Reiesr4-ում, «ծույլ» հաշվիչներ սահմանված չեն. դրանք ներկայացնելու համար անհրաժեշտ է լուծել որոշակի ալգորիթմական խնդիրներ, որոնք դեռ ոչ ոք չի ստանձնել:
Ըստ HAMMER-ի՝ ես հոդված եմ կարդացել հեղինակից։ Չի հետաքրքրում. Կրկին B- ծառեր: Այս տվյալների կառուցվածքը անհույս հնացած է: Մենք դա լքել ենք անցյալ դարում։
Ինչպե՞ս եք գնահատում ցանցային կլաստերի FS-ների աճող պահանջարկը, ինչպիսիք են CephFS/GlusterFS/ և այլն: Արդյո՞ք այս պահանջը նշանակում է ծրագրավորողների առաջնահերթությունների տեղափոխում դեպի ցանցային FS և անբավարար ուշադրություն տեղական FS-ի նկատմամբ:
Այո, առաջնահերթությունների նման տեղաշարժ է տեղի ունեցել։ Տեղական ֆայլային համակարգերի զարգացումը լճացել է։ Ավաղ, տեղական ծավալների համար նշանակալի բան անելն այժմ բավականին դժվար է, և ոչ բոլորն են դա կարող անել։ Ոչ ոք չի ցանկանում ներդրումներ կատարել դրանց զարգացման մեջ։ Սա մոտավորապես նույնն է, ինչ առևտրային կազմակերպությանը խնդրեք գումար հատկացնել մաթեմատիկական հետազոտության համար. առանց որևէ ոգևորության նրանք ձեզ կհարցնեն, թե ինչպես կարող եք գումար աշխատել նոր թեորեմի վրա: Այժմ տեղական FS-ն այնպիսի մի բան է, որը կախարդական կերպով հայտնվում է «դուրս արկղից» և «միշտ պետք է աշխատի», և եթե այն չի աշխատում, ապա առաջացնում է անհասցե տրտնջալ, ինչպիսիք են. «Այո, ինչ են նրանք մտածում»:
Այստեղից էլ տեղի FS-ի նկատմամբ ուշադրության պակասը, թեև այդ ոլորտում դեռ շատ աշխատանք կա։ Եվ այո, բոլորը դիմել են բաշխված պահեստին, որը կառուցված է արդեն գոյություն ունեցող տեղական ֆայլային համակարգերի հիման վրա։ Հիմա շատ նորաձեւ է։ «Մեծ տվյալներ» արտահայտությունը շատերի մոտ առաջացնում է ադրենալինի աճ՝ այն կապելով կոնֆերանսների, աշխատաժողովների, մեծ աշխատավարձերի և այլնի հետ։
Սկզբունքորեն որքանո՞վ է խելամիտ ցանցային ֆայլային համակարգը ներդնել միջուկի, այլ ոչ թե օգտագործողի տարածքում:
Շատ ողջամիտ մոտեցում, որը դեռ ոչ մի տեղ չի իրականացվել։ Ընդհանուր առմամբ, այն հարցը, թե ինչ տարածքում պետք է ներդրվի ցանցային ֆայլային համակարգը, դա «երկսայրի սուր է»: Դե, եկեք նայենք մի օրինակ. Հաճախորդը գրանցել է տվյալներ հեռավոր մեքենայի վրա: Նրանք կեղտոտ էջերի տեսքով ընկել են նրա էջի քեշը։ Սա միջուկի տարածքում «բարակ դարպաս» ցանցային ֆայլային համակարգի աշխատանքն է: Հետո օպերացիոն համակարգը վաղ թե ուշ ձեզ կխնդրի գրել այդ էջերը սկավառակի վրա՝ դրանք ազատելու համար։ Այնուհետև գործում է IO-փոխանցող (ուղարկող) ցանցի FS մոդուլը: Այն որոշում է, թե որ սերվերի մեքենան (սերվերի հանգույց) կգնան այս էջերը:
Այնուհետև ցանցային ստեկը ստանձնում է (և, ինչպես գիտենք, այն իրականացվում է միջուկի տարածքում): Այնուհետև, սերվերի հանգույցը ստանում է այդ փաթեթը տվյալների կամ մետատվյալների հետ և հրահանգում է backend պահեստավորման մոդուլին (այսինքն՝ տեղական FS-ին, որը գործում է միջուկի տարածքում) գրանցել այս բոլոր նյութերը: Այսպիսով, մենք կրճատել ենք այն հարցը, թե որտեղ պետք է աշխատեն «ուղարկող» և «ստացող» մոդուլները: Եթե այդ մոդուլներից որևէ մեկը գործարկվի օգտագործողի տարածքում, դա անխուսափելիորեն կհանգեցնի համատեքստի փոխարկմանը (միջուկի ծառայություններից օգտվելու անհրաժեշտության պատճառով): Նման անջատիչների թիվը կախված է իրականացման մանրամասներից:
Եթե կան շատ նման անջատիչներ, ապա պահեստավորման թողունակությունը (I/O կատարումը) կնվազի: Եթե ձեր պահեստային պահեստը բաղկացած է դանդաղ սկավառակներից, ապա դուք զգալի անկում չեք նկատի: Բայց եթե դուք ունեք արագ սկավառակներ (SSD, NVRAM և այլն), ապա համատեքստի փոխարկումն արդեն դառնում է «խոչընդոտ» և, խնայելով համատեքստի անցումը, կատարողականությունը կարող է զգալիորեն աճել: Գումար խնայելու ստանդարտ միջոցը մոդուլները միջուկի տարածություն տեղափոխելն է: Օրինակ, մենք պարզեցինք, որ 9p սերվերի տեղափոխումը QEMU-ից դեպի հյուրընկալող մեքենայի միջուկը հանգեցնում է VirtFS-ի կատարողականի եռակի բարձրացման:
Սա, իհարկե, ցանցային FS չէ, բայց այն լիովին արտացոլում է իրերի էությունը: Այս օպտիմալացման բացասական կողմը տեղափոխելիության խնդիրներն են: Ոմանց համար վերջինս կարող է քննադատական լինել: Օրինակ, GlusterFS-ն ընդհանրապես միջուկում մոդուլներ չունի: Դրա շնորհիվ այն այժմ աշխատում է բազմաթիվ հարթակներում, ներառյալ NetBSD:
Ի՞նչ հասկացություններ կարող են վերցնել տեղական FS-ները ցանցայիններից և հակառակը:
Ներկայումս ցանցային FS-ները, որպես կանոն, ունեն հավելումներ տեղական FS-ների վրա, այնպես որ ես այնքան էլ չեմ հասկանում, թե ինչպես կարելի է որևէ բան վերցնել վերջիններից: Լավ, իսկապես, դիտարկենք 4 աշխատողներից բաղկացած ընկերություն, որտեղ ամեն մեկն իր գործն է անում՝ մեկը բաժանում է, մյուսը՝ ուղարկում, երրորդը՝ ստանում, չորրորդը՝ խանութներ։ Իսկ հարցը, թե ընկերությունն ինչ կարող է պարտք վերցնել այն պահող իր աշխատակցից, ինչ-որ տեղ ոչ կոռեկտ է հնչում (այն արդեն ուներ այն, ինչ վաղուց կարող էր վերցնել նրանից)։
Սակայն տեղական FS-ները շատ բան ունեն սովորելու ցանցայիններից: Առաջին հերթին, դուք պետք է սովորեք նրանցից, թե ինչպես կարելի է բարձր մակարդակով հավաքել տրամաբանական ծավալները: Այժմ այսպես կոչված «Ընդլայնված» տեղական ֆայլային համակարգերը միավորում են տրամաբանական ծավալները բացառապես LVM-ից փոխառված «վիրտուալ սարք» տեխնոլոգիայի միջոցով (այդ նույն վարակիչ շերտավորման խախտումը, որն առաջին անգամ իրականացվել է ZFS-ում): Այլ կերպ ասած, վիրտուալ հասցեների (բլոկի համարների) թարգմանությունը իրականի և հետադարձի տեղի է ունենում ցածր մակարդակում (այսինքն, այն բանից հետո, երբ ֆայլային համակարգը I/O հարցում է թողարկել):
Խնդրում ենք նկատի ունենալ, որ բլոկի շերտի վրա դասավորված տրամաբանական ծավալներին (ոչ հայելիներին) սարքեր ավելացնելն ու հեռացնելը հանգեցնում է խնդիրների, որոնց մասին նման «հատկանիշների» մատակարարները համեստորեն լռում են: Խոսքս իրական սարքերի վրա մասնատման մասին է, որը կարող է հրեշավոր արժեքների հասնել, մինչդեռ վիրտուալ սարքում ամեն ինչ կարգին է։ Այնուամենայնիվ, քչերին են հետաքրքրում վիրտուալ սարքերը. բոլորին հետաքրքրում է, թե ինչ է կատարվում ձեր իրական սարքերում: Սակայն ZFS-ի նման FS-ը (ինչպես նաև ցանկացած FS՝ LVM-ի հետ համատեղ) աշխատում է միայն վիրտուալ սկավառակի սարքերի հետ (հատկացրեք վիրտուալ սկավառակի հասցեները անվճարներից, դեֆրագրում արեք այս վիրտուալ սարքերը և այլն): Եվ նրանք գաղափար չունեն, թե ինչ է կատարվում իրական սարքերում:
Հիմա պատկերացրեք, որ դուք ունեք զրոյական մասնատվածություն վիրտուալ սարքի վրա (այսինքն, դուք ունեք ընդամենը մեկ հսկա տարածություն, որը ապրում է այնտեղ), դուք ավելացնում եք սկավառակ ձեր տրամաբանական ծավալին, ապա հանում եք մեկ այլ պատահական սկավառակ ձեր տրամաբանական ծավալից և այնուհետև հավասարակշռում: Եվ այսքան անգամ: Դժվար չէ պատկերացնել, որ վիրտուալ սարքում դուք դեռ նույն չափով ապրելու եք, բայց իրական սարքերում ոչ մի լավ բան չեք տեսնի:
Ամենավատն այն է, որ դուք նույնիսկ չեք կարողանում շտկել այս իրավիճակը: Միակ բանը, որ դուք կարող եք անել այստեղ, ֆայլային համակարգին խնդրելն է վիրտուալ սարքի ապաֆրագմենտացիա անել: Բայց նա ձեզ կասի, որ այնտեղ ամեն ինչ հիանալի է. կա միայն մեկ աստիճան, մասնատումը զրոյական է, և ավելի լավ չի կարող լինել: Այսպիսով, բլոկի մակարդակում դասավորված տրամաբանական ծավալները նախատեսված չեն սարքերի կրկնակի ավելացման/հեռացման համար: Լավ իմաստով, պետք է միայն մեկ անգամ հավաքել տրամաբանական ծավալը բլոկի մակարդակում, տալ այն ֆայլային համակարգին և հետո այլ բան չանել դրա հետ։
Բացի այդ, անկախ FS+LVM ենթահամակարգերի համակցությունը թույլ չի տալիս հաշվի առնել կրիչների տարբեր բնույթը, որոնցից տրամաբանական ծավալները ագրեգացված են: Իսկապես, ենթադրենք, որ դուք հավաքել եք տրամաբանական ծավալ HDD-ից և պինդ վիճակի սարքերից: Բայց հետո առաջինը կպահանջի դեֆրագրում, իսկ երկրորդը` ոչ: Վերջինիս համար պետք է թողարկեք մերժման հարցումներ, իսկ առաջինի համար՝ ոչ և այլն: Սակայն այս համակցությամբ բավականին դժվար է նման ընտրողականություն դրսևորել։
Նկատի ունեցեք, որ ֆայլային համակարգում ձեր սեփական LVM-ն ստեղծելուց հետո իրավիճակը շատ ավելի լավ չի դառնում: Ավելին, դրանով դուք իրականում վերջ եք դնում ապագայում այն երբևէ բարելավելու հեռանկարին: Սա շատ վատ է։ Տարբեր տեսակի կրիչներ կարող են ապրել նույն մեքենայի վրա: Իսկ եթե ֆայլային համակարգը չի տարբերում դրանք, ապա ո՞վ կանի:
Մեկ այլ խնդիր է սպասել այսպես կոչվածին. «Write-Anywhere» ֆայլային համակարգեր (սա ներառում է նաև Reiser4, եթե տեղադրման ժամանակ նշել եք գործարքի համապատասխան մոդելը): Նման ֆայլային համակարգերը պետք է ապահովեն դեֆրագրման գործիքներ, որոնք աննախադեպ են իրենց հզորությամբ: Իսկ ձայնի ցածր մակարդակի մենեջերը այստեղ չի օգնում, այլ միայն խանգարում է: Փաստն այն է, որ նման մենեջերի հետ ձեր FS-ը կպահի միայն մեկ սարքի անվճար բլոկների քարտեզ՝ վիրտուալ: Համապատասխանաբար, դուք կարող եք միայն վիրտուալ սարքը վերափոխել: Սա նշանակում է, որ ձեր defragmenter-ը երկար, երկար ժամանակ կաշխատի վիրտուալ հասցեների հսկայական տարածության վրա:
Եվ եթե դուք ունեք շատ օգտատերեր, ովքեր պատահական վերագրանցումներ են անում, ապա նման ապաֆրագմենտատորի օգտակար էֆեկտը կզրոյի: Ձեր համակարգն անխուսափելիորեն կսկսի դանդաղել, և ձեզ մնում է միայն ձեռքերը ծալել «կոտրված դիզայնի» հիասթափեցնող ախտորոշման առաջ: Միևնույն հասցեի տարածության վրա աշխատող մի քանի դեֆրագրմաներ միայն կխանգարեն միմյանց: Բոլորովին այլ խնդիր է, եթե դուք պահպանում եք անվճար բլոկների ձեր սեփական քարտեզը յուրաքանչյուր իրական սարքի համար: Սա արդյունավետորեն զուգահեռ կբերի դեֆրագրման գործընթացին:
Բայց դա կարելի է անել միայն այն դեպքում, եթե ունեք բարձր մակարդակի տրամաբանական ծավալի կառավարիչ: Նման կառավարիչներով տեղական ֆայլային համակարգեր նախկինում գոյություն չունեին (համենայն դեպս, ես չգիտեմ դրանց մասին): Նման կառավարիչներ ունեին միայն ցանցային ֆայլային համակարգերը (օրինակ՝ GlusterFS): Մեկ այլ շատ կարևոր օրինակ է ձայնի ամբողջականության ստուգման (fsck) կոմունալ ծրագիրը: Եթե յուրաքանչյուր ենթահատորի համար պահում եք անվճար բլոկների ձեր սեփական անկախ քարտեզը, ապա տրամաբանական ծավալը ստուգելու կարգը կարող է արդյունավետորեն զուգահեռվել: Այլ կերպ ասած, բարձր մակարդակի մենեջերների հետ տրամաբանական ծավալներն ավելի լավ են չափվում:
Բացի այդ, ցածր մակարդակի մենեջերների դեպքում դուք չեք կարողանա կազմակերպել ամբողջական ակնթարթային նկարներ: LVM-ի և ZFS-ի նման ֆայլային համակարգերի միջոցով դուք կարող եք վերցնել միայն տեղական ակնթարթային նկարներ, բայց ոչ գլոբալ պատկերներ: Տեղական լուսանկարները թույլ են տալիս անմիջապես հետ տալ միայն սովորական ֆայլերի գործողությունները: Եվ այնտեղ ոչ ոք հետ չի անի գործողությունները տրամաբանական ծավալներով (սարքեր ավելացնելու/հեռացնելու համար): Սրան նայենք օրինակով։ Ժամանակի ինչ-որ պահի, երբ դուք ունեք երկու A և B սարքերի տրամաբանական ծավալ, որոնք պարունակում են 100 ֆայլ, դուք նկարում եք S համակարգի պատկերը և այնուհետև ստեղծում ևս հարյուր ֆայլ:
Դրանից հետո դուք ավելացնում եք «C» սարքը ձեր ծավալին, և վերջապես ձեր համակարգը վերադարձնում եք Snapshot-ին: Հարց. Քանի՞ ֆայլ և սարք է պարունակում ձեր տրամաբանական ծավալը S-ին հետ վերադարձնելուց հետո: Կլինեն 100 ֆայլեր, ինչպես կռահեցիք, բայց կլինեն 3 սարք՝ սրանք նույն սարքերն են՝ A, B և C, թեև նկարի ստեղծման պահին համակարգում կար ընդամենը երկու սարք (A և B): ) «Add device C» օպերացիան հետ չի շրջվել, և եթե դուք այժմ հեռացնեք C սարքը համակարգչից, այն կփչացնի ձեր տվյալները, ուստի ջնջելուց առաջ նախ պետք է կատարեք թանկարժեք գործողություն՝ սարքը վերաբալանսի տրամաբանական ծավալից հեռացնելու համար, որը: C սարքից բոլոր տվյալները կցրվեն A և B սարքերին: Բայց եթե ձեր FS-ն աջակցում է գլոբալ նկարներ, նման վերաբալանսը չի պահանջվի, և S-ին ակնթարթորեն հետ վերադարձնելուց հետո դուք կարող եք ապահով կերպով հեռացնել C սարքը համակարգչից:
Այսպիսով, գլոբալ նկարները լավ են, քանի որ դրանք թույլ են տալիս խուսափել մեծ քանակությամբ տվյալների տրամաբանական ծավալից (տրամաբանական ծավալից) սարքի ծախսատար հեռացումից (ավելացումից) (իհարկե, եթե հիշում եք ձեր համակարգը «պատկերացնել» ճիշտ ժամանակին): Հիշեցնեմ, որ snapshot-ների ստեղծումը և ֆայլային համակարգը դրանց հետ գլորելը ակնթարթային գործողություններ են: Հարց կարող է առաջանալ. ինչպե՞ս է հնարավոր նույնիսկ ակնթարթորեն հետ գցել վիրահատությունը տրամաբանական ծավալով, որը ձեզ տևեց երեք օր: Բայց դա հնարավոր է! Պայմանով, որ ձեր ֆայլային համակարգը ճիշտ է նախագծված: Նման «3D ակնթարթների» գաղափարը ես հղացա երեք տարի առաջ, իսկ անցյալ տարի ես արտոնագրեցի այս տեխնիկան:
Հաջորդ բանը, որ տեղական FS-ները պետք է սովորեն ցանցայիններից, մետատվյալները առանձին սարքերում պահելն է այնպես, ինչպես ցանցային FS-ները դրանք պահում են առանձին մեքենաներում (այսպես կոչված, մետատվյալների սերվերներ): Կան հավելվածներ, որոնք աշխատում են հիմնականում մետատվյալների հետ, և այդ հավելվածները կարող են մեծապես արագացվել՝ տեղադրելով մետատվյալները թանկարժեք բարձրորակ պահեստավորման սարքերի վրա: FS+LVM համակցությամբ դուք չեք կարողանա նման ընտրողականություն դրսևորել. LVM-ն չգիտի, թե ինչ կա այն բլոկի վրա, որը դուք փոխանցել եք իրեն (տվյալներն այնտեղ կամ մետատվյալներ):
Դուք մեծ օգուտ չեք ստանա FS-ում ձեր սեփական ցածր մակարդակի LVM-ն ներդնելուց՝ համեմատած FS+LVM համադրության հետ, բայց այն, ինչ կարող եք շատ լավ անել, այն է, որ խառնաշփոթեք FS-ը, որպեսզի հետագայում անհնար լինի աշխատել դրա կոդի հետ: ZFS-ը և Btrfs-ը, որոնք շտապում էին վիրտուալ սարքերով, բոլորն էլ հստակ օրինակներ են այն բանի, թե ինչպես է շերտավորման խախտումը ոչնչացնում համակարգը ճարտարապետական առումով: Այսպիսով, ինչու եմ ես այս ամենը: Ավելին, կարիք չկա տեղադրել ձեր սեփական ցածր մակարդակի LVM ֆայլային համակարգում։ Փոխարենը, դուք պետք է ագրեգացնեք սարքերը տրամաբանական ծավալների մեջ բարձր մակարդակով, ինչպես որոշ ցանցային ֆայլային համակարգեր անում են տարբեր մեքենաների (պահեստավորման հանգույցների) հետ: Ճիշտ է, նրանք դա անում են զզվելի կերպով՝ վատ ալգորիթմների կիրառման պատճառով։
Բացարձակապես սարսափելի ալգորիթմների օրինակներ են DHT թարգմանիչը GlusterFS ֆայլային համակարգում և այսպես կոչված CRUSH քարտեզը Ceph ֆայլային համակարգում։ Իմ տեսած ալգորիթմներից ոչ մեկը չբավարարեց ինձ պարզության և լավ մասշտաբայնության առումով: Այսպիսով, ես ստիպված էի հիշել հանրահաշիվը և ինքս հորինել ամեն ինչ: 2015-ին, երբ փորձարկում էի փաթույթների հետ կապված հեշ ֆունկցիաների վրա, ես գտա և արտոնագրեցի մի բան, որը հարմար է ինձ: Հիմա կարող եմ ասել, որ այս ամենը կյանքի կոչելու փորձը հաջողվեց։ Նոր մոտեցման մեջ ես մասշտաբայնության հետ կապված որևէ խնդիր չեմ տեսնում:
Այո, յուրաքանչյուր ենթածավալ կպահանջի առանձին կառուցվածք, ինչպիսին է հիշողության գերբլոկը: Սա շա՞տ վախկոտ է: Ընդհանրապես, ես չգիտեմ, թե ով է պատրաստվում «եռացնել օվկիանոսը» և ստեղծել հարյուր հազարավոր կամ ավելի սարքերի տրամաբանական ծավալներ մեկ տեղական մեքենայի վրա: Եթե որևէ մեկը կարող է ինձ բացատրել սա, ես շատ շնորհակալ կլինեմ: Մինչդեռ ինձ համար սա մարքեթինգային հիմարություն է։
Ինչպե՞ս են միջուկային բլոկի սարքի ենթահամակարգի փոփոխությունները (օրինակ, blk-mq-ի տեսքը) ազդել FS-ի իրականացման պահանջների վրա:
Նրանք ոչ մի ազդեցություն չեն ունեցել։ Ես չգիտեմ, թե ինչ տեղի կունենա բլոկի շերտի վրա, որը կստիպի նոր FS նախագծել: Այս ենթահամակարգերի փոխազդեցության ինտերֆեյսը շատ վատ է: Վարորդի կողմից FS-ի վրա պետք է ազդի միայն նոր տեսակի կրիչների տեսքը, որին նախ կհարմարեցվի բլոկային շերտը, իսկ հետո՝ FS-ը (reiser4-ի համար դա կնշանակի նոր պլագինների հայտնվելը):
Արդյո՞ք նոր տեսակի մեդիաների առաջացումը (օրինակ՝ SMR կամ SSD-ների համատարած լինելը) նշանակում է սկզբունքորեն նոր մարտահրավերներ ֆայլային համակարգի ձևավորման համար:
Այո՛։ Եվ սրանք նորմալ խթաններ են FS-ի զարգացման համար։ Մարտահրավերները կարող են լինել տարբեր և բոլորովին անսպասելի: Օրինակ, ես լսել եմ սկավառակների մասին, որտեղ I/O գործողության արագությունը մեծապես կախված է տվյալների մի հատվածի չափից և դրա օֆսեթից: Linux-ում, որտեղ FS բլոկի չափը չի կարող գերազանցել էջի չափը, նման սկավառակը լռելյայն չի ցուցադրի իր լիարժեք հնարավորությունները։ Այնուամենայնիվ, եթե ձեր ֆայլային համակարգը ճիշտ է նախագծված, ապա դրանից շատ ավելին ստանալու հնարավորություն կա:
Քանի՞ հոգի է ներկայումս աշխատում Reiser4 կոդով, բացի ձեզանից:
Ավելի քիչ, քան ես կցանկանայի, բայց ես նույնպես ռեսուրսների սուր պակաս չեմ զգում: Ես ավելի քան գոհ եմ Reiser4-ի զարգացման տեմպերից։ Ես չեմ պատրաստվում «ձի քշել», սա ճիշտ տարածք չէ: Ահա, «եթե ավելի հանգիստ վարես, կշարունակես»: Ժամանակակից ֆայլային համակարգը միջուկի ամենաբարդ ենթահամակարգն է, որի նախագծման սխալ որոշումները կարող են չեղարկել մարդու հետագա տարիների աշխատանքը:
Կամավորներին առաջարկելով ինչ-որ բան իրականացնել՝ ես միշտ երաշխավորում եմ, որ ջանքերն անշուշտ կհանգեցնեն ճիշտ արդյունքի, որը կարող է պահանջված լինել լուրջ կարիքների համար։ Ինչպես հասկանում եք, նման երաշխիքներ միանգամից շատ չեն կարող լինել։ Միևնույն ժամանակ, ես տանել չեմ կարող այն «գործիչներին», ովքեր անամոթաբար առաջ են քաշում ակնհայտորեն անօգտագործելի ծրագրաշարի «առանձնահատկությունները»՝ խաբելով հարյուրավոր օգտատերերի և մշակողների, և միևնույն ժամանակ նստում ու ժպտում են միջուկի գագաթնաժողովներին:
Արդյո՞ք որևէ ընկերություն պատրաստակամություն է հայտնել աջակցել Reiser4-ի զարգացմանը:
Այո, եղել են նման առաջարկներ, այդ թվում. և խոշոր վաճառողից: Բայց դրա համար ես ստիպված էի տեղափոխվել այլ երկիր։ Ցավոք սրտի, ես այլևս 30 տարեկան չեմ, չեմ կարող պոկվել և այդպես հեռանալ առաջին սուլիչի ժամանակ։
Ի՞նչ հատկանիշներ են ներկայումս բացակայում Reiser4-ից:
Չկա «չափափոխել» ֆունկցիա պարզ հատորների համար, որը նման է ReiserFS(v3)-ում հայտնաբերվածին: Բացի այդ, DIRECT_IO դրոշով ֆայլի գործողությունները չեն վնասի: Հաջորդը, ես կցանկանայի, որ կարողանամ հատորը տարանջատել «իմաստային ենթածավալների», որոնք չունեն ֆիքսված չափեր և որոնք կարող են տեղադրվել որպես անկախ հատորներ: Այս խնդիրները լավ են սկսնակների համար, ովքեր ցանկանում են իրենց ուժերը փորձել «իրական բանում»:
Եվ վերջապես, ես կցանկանայի ունենալ ցանցային տրամաբանական ծավալներ՝ պարզ ներդրմամբ և կառավարմամբ (ժամանակակից ալգորիթմներն արդեն թույլ են տալիս դա): Բայց այն, ինչ Reiser4-ը հաստատ երբեք չի ունենա, դա RAID-Z-ն է, սկրաբները, ազատ տարածության քեշերը, 128-բիթանոց փոփոխականները և այլ մարքեթինգային անհեթեթություններ, որոնք առաջացել են որոշ ֆայլային համակարգերի մշակողների շրջանում գաղափարների պակասի ֆոնին:
Կարո՞ղ է արդյոք այն ամենը, ինչը կարող է անհրաժեշտ լինել, իրականացվել փլագինների կողմից:
Եթե խոսենք միայն դրանք իրականացնող ինտերֆեյսների և պլագինների (մոդուլների) առումով, ապա ոչ ամեն ինչ։ Բայց եթե դուք նաև փոխհարաբերություններ մտցնեք այս ինտերֆեյսների վրա, ապա, ի թիվս այլ բաների, դուք կունենաք ավելի բարձր պոլիմորֆիզմների հասկացություններ, որոնցով դուք արդեն կարող եք հաղթահարել: Պատկերացրեք, որ դուք հիպոթետիկորեն սառեցրել եք օբյեկտի վրա հիմնված գործարկման ժամանակի համակարգը, փոխել հրահանգների ցուցիչի արժեքը՝ մատնանշելով նույն X ինտերֆեյսը կիրառող մեկ այլ պլագին, այնուհետև ապասառեցրել եք համակարգը, որպեսզի այն շարունակի գործել:
Եթե վերջնական օգտագործողը չի նկատում նման «փոխարինում», ապա մենք ասում ենք, որ համակարգը X միջերեսում ունի զրոյական կարգի պոլիմորֆիզմ (կամ համակարգը տարասեռ է X միջերեսում, ինչը նույնն է): Եթե այժմ դուք ոչ միայն ունեք ինտերֆեյսների մի շարք, այլև դրանց վրա ունեք հարաբերություններ (ինտերֆեյսի գրաֆիկ), ապա կարող եք ներմուծել ավելի բարձր կարգի պոլիմորֆիզմներ, որոնք կբնութագրեն համակարգի տարասեռությունը արդեն ցանկացած ինտերֆեյսի «հարևանությամբ»: Նման դասակարգում ես վաղուց եմ ներկայացրել, բայց, ցավոք, այդպես էլ չի եղել։
Այսպիսով, պլագինների և նման ավելի բարձր պոլիմորֆիզմների օգնությամբ դուք կարող եք նկարագրել ցանկացած հայտնի հատկանիշ, ինչպես նաև «կանխատեսել» այն, ինչը երբեք նույնիսկ չի հիշատակվել: Ես չեմ կարողացել դա խստորեն ապացուցել, բայց ես նաև հակաօրինակ դեռ չգիտեմ։ Ընդհանուր առմամբ, այս հարցն ինձ հիշեցրեց Ֆելիքս Քլայնի «Էրլանգեն ծրագիրը»: Ժամանակին նա փորձել է ամբողջ երկրաչափությունը ներկայացնել որպես հանրահաշվի ճյուղ (մասնավորապես՝ խմբի տեսություն)։
Հիմա հիմնական հարցին. ինչպե՞ս են ընթանում գործերը Reiser4-ի հիմնական միջուկ առաջխաղացման հետ կապված: Կա՞ն հրապարակումներ այս ֆայլային համակարգի ճարտարապետության վերաբերյալ, որոնց մասին դուք խոսեցիք վերջին հարցազրույցում: Որքանո՞վ է այս հարցը տեղին ձեր տեսանկյունից:
Ընդհանուր առմամբ, երեք տարի է՝ խնդրում ենք ընդգրկել հիմնական ճյուղում։ Reiser-ի վերջին մեկնաբանությունը հանրային թեմայում, որտեղ արվել էր ձգման հարցումը, մնաց անպատասխան: Այսպիսով, հետագա բոլոր հարցերը մեզ համար չեն: Ես անձամբ չեմ հասկանում, թե ինչու պետք է «միաձուլվենք» կոնկրետ օպերացիոն համակարգի մեջ: Linux-ի վրա լույսը սեպի պես միաձուլվում էր: Այսպիսով, կա առանձին պահեստ, որտեղ կլինեն մի քանի մասնաճյուղ-պորտ տարբեր ՕՀ-ների համար: Ում դա պետք է, կարող է կլոնավորել համապատասխան պորտը և անել այն, ինչ ուզում ես դրանով (իհարկե լիցենզիայի շրջանակներում)։ Դե, եթե ինչ-որ մեկին դա պետք չէ, ապա դա իմ խնդիրը չէ: Այս պահին ես առաջարկում եմ լուծել «Լինուքսի հիմնական միջուկում առաջխաղացման» հարցը:
FS ճարտարապետության վերաբերյալ հրապարակումները տեղին են, բայց մինչ այժմ ես ժամանակ եմ գտել միայն իմ նոր արդյունքների համար, որոնք ավելի առաջնահերթ եմ համարում: Ուրիշ բան, որ ես մաթեմատիկոս եմ, իսկ մաթեմատիկայում ցանկացած հրապարակում թեորեմների և դրանց ապացույցների ամփոփումն է։ Առանց ապացույցների այնտեղ որևէ բան հրապարակելը անճաշակության նշան է։ Եթե ես հիմնովին ապացուցեմ կամ հերքեմ FS-ի ճարտարապետության մասին որևէ հայտարարություն, ապա արդյունքը կլինի այնպիսի կույտեր, որոնց միջով անցնելը բավականին դժվար կլինի: Ո՞ւմ է դա պետք: Հավանաբար սա է պատճառը, որ ամեն ինչ շարունակում է մնալ իր հին տեսքով՝ սկզբնաղբյուրը և դրա մեկնաբանությունները:
Ի՞նչ նորություն կա Reiser4-ում վերջին մի քանի տարիների ընթացքում:
Վերջապես իրականացավ երկար սպասված կայունությունը։ Վերջիններից մեկը, որը հայտնվեց, սխալ էր, որը հանգեցրեց «չջնջվող» գրացուցակների: Դժվարությունը կայանում էր նրանում, որ այն հայտնվում էր միայն անունների հեշի բախումների ֆոնի վրա և ծառի հանգույցում գրացուցակի գրառումների որոշակի տեղակայմամբ: Այնուամենայնիվ, ես դեռ չեմ կարող Reiser4-ին առաջարկել արտադրության համար. դրա համար դուք պետք է որոշակի աշխատանք կատարեք արտադրական համակարգի ադմինիստրատորների հետ ակտիվ փոխազդեցությամբ:
Վերջապես մեզ հաջողվեց կյանքի կոչել մեր վաղեմի գաղափարը՝ գործարքների տարբեր մոդելներ։ Նախկինում Reiser4-ն աշխատում էր միայն մեկ կոշտ կոդավորված Macdonald-Reiser մոդելի վրա: Սա նախագծային խնդիրներ է ստեղծել: Մասնավորապես, ակնթարթային նկարները հնարավոր չեն նման գործարքային մոդելում. դրանք կփչացվեն ատոմային բաղադրիչով, որը կոչվում է «OVERWRITE SET»: Reiser4-ը ներկայումս աջակցում է գործարքների երեք մոդելների: Դրանցից մեկում (Write-Anywhere) ատոմային բաղադրիչը OVERWRITE SET ներառում է միայն համակարգի էջեր (սկավառակի բիթքարտեզների պատկերներ և այլն), որոնք հնարավոր չէ «լուսանկարել» (հավի և ձվի խնդիրը):
Այսպիսով, նկարներն այժմ կարող են իրականացվել լավագույն ձևով: Մեկ այլ գործարքային մոդելում բոլոր փոփոխված էջերը գնում են միայն OVERWRITE SET-ին (այսինքն, ըստ էության, դա մաքուր օրագրում է): Այս մոդելը նրանց համար է, ովքեր դժգոհում էին Reiser4 միջնորմների արագ մասնատումից: Այժմ այս մոդելում ձեր բաժանումը կկոտրվի ոչ ավելի արագ, քան ReiserFS-ի (v3): Բոլոր երեք գոյություն ունեցող մոդելները, որոշ վերապահումներով, երաշխավորում են գործողությունների ատոմականությունը, սակայն ատոմականության կորստով և միայն հատվածի ամբողջականությունը պահպանող մոդելները նույնպես կարող են օգտակար լինել: Նման մոդելները կարող են օգտակար լինել բոլոր տեսակի հավելվածների համար (տվյալների բազաներ և այլն), որոնք արդեն ստանձնել են այս գործառույթներից մի քանիսը։ Այս մոդելները Reiser4-ին ավելացնելը շատ հեշտ է, բայց ես դա չարեցի, քանի որ ոչ ոք ինձ չի հարցրել, և ես անձամբ դրա կարիքը չունեմ:
Հայտնվեցին մետատվյալների ստուգաչափեր, և ես վերջերս դրանք լրացրեցի «տնտեսական» հայելիներով» (դեռևս անկայուն նյութ): Եթե որևէ բլոկի ստուգման գումարը ձախողվի, Reiser4-ը անմիջապես կարդում է համապատասխան բլոկը կրկնօրինակ սարքից: Նկատի ունեցեք, որ ZFS-ը և Btrfs-ը չեն կարող դա անել. դիզայնը դա թույլ չի տալիս: Այնտեղ դուք պետք է գործարկեք հատուկ ֆոնի սկանավորման գործընթաց, որը կոչվում է «մացառ» և սպասեք, որ այն հասնի խնդրահարույց բլոկին: Նման իրադարձությունները ծրագրավորողները պատկերավոր կերպով անվանում են «հենակներ»։
Եվ վերջապես, ի հայտ են եկել տարասեռ տրամաբանական ծավալներ, որոնք առաջարկում են այն ամենը, ինչ ZFS, Btrfs, բլոկ շերտը, ինչպես նաև FS+LVM համակցությունները սկզբունքորեն չեն կարող ապահովել՝ զուգահեռ մասշտաբավորում, O(1) սկավառակի հասցեների հատկացուցիչ, տվյալների թափանցիկ միգրացիա ենթածավալների միջև։ Վերջինս ունի նաև օգտատիրոջ միջերես։ Այժմ դուք կարող եք հեշտությամբ տեղափոխել ամենաթեժ տվյալները ձեր ձայնի ամենաբարձր արդյունավետությամբ սկավառակ:
Բացի այդ, հնարավոր է հրատապ կերպով ողողել ցանկացած կեղտոտ էջ նման սկավառակի վրա՝ դրանով իսկ զգալիորեն արագացնելով հավելվածները, որոնք հաճախ անվանում են fsync(2): Ես նշում եմ, որ բլոկ շերտի ֆունկցիոնալությունը, որը կոչվում է bcache, բացարձակապես չի ապահովում գործողությունների նման ազատություն: Նոր տրամաբանական ծավալները հիմնված են իմ ալգորիթմների վրա (կան համապատասխան արտոնագրեր)։ Ծրագիրը արդեն բավականին կայուն է, միանգամայն հնարավոր է փորձել այն, չափել կատարումը և այլն: Միակ անհարմարությունն այն է, որ առայժմ անհրաժեշտ է ձեռքով թարմացնել ձայնի կոնֆիգուրացիան և պահել այն ինչ-որ տեղ:
Մինչ այժմ ես կարողացել եմ իրականացնել իմ գաղափարները 10 տոկոսով, սակայն ինձ հաջողվել է այն, ինչ ես համարում էի ամենադժվարը՝ տրամաբանական ծավալները միացնելով ֆլեշ պրոցեդուրայով, որը կատարում է բոլոր հետաձգված գործողությունները reiser4-ում: Այս ամենը դեռ փորձնական «format41» մասնաճյուղում է:
Արդյո՞ք Reiser4-ը անցնում է xfstests:
Համենայն դեպս ինձ համար դա արվեց, երբ պատրաստում էի վերջին թողարկումը:
Հնարավո՞ր է սկզբունքորեն Reiser4-ը դարձնել ցանցային (կլաստեր) FS՝ օգտագործելով պլագիններ:
Դա հնարավոր է, և նույնիսկ անհրաժեշտ է: Եթե ստեղծեք ցանցային ֆայլ՝ հիմնված պատշաճ ձևավորված տեղական ֆայլային համակարգի վրա, արդյունքը շատ տպավորիչ կլինի: Ժամանակակից ցանցային FS-ներում ինձ չի բավարարում backend պահեստավորման մակարդակի առկայությունը, որն իրականացվում է ցանկացած տեղական FS-ի միջոցով: Այս մակարդակի գոյությունը միանգամայն չարդարացված է։ Ցանցի FS-ը պետք է ուղղակիորեն փոխազդի բլոկ շերտի հետ և չխնդրի տեղական FS-ին ստեղծել որևէ այլ սպասարկման ֆայլ:
Ընդհանրապես, ֆայլային համակարգերը տեղական և ցանցային բաժանելը չարից է: Այն առաջացել է երեսուն տարի առաջ օգտագործված ալգորիթմների անկատարությունից, և որոնց փոխարեն դեռ ոչինչ չի առաջարկվել։ Դրանով է պայմանավորված նաև ավելորդ ծրագրային բաղադրիչների զանգվածի առաջացումը (տարբեր ծառայություններ և այլն)։ Լավ իմաստով, պետք է լինի միայն մեկ FS միջուկի մոդուլի տեսքով և յուրաքանչյուր մեքենայի վրա տեղադրված օգտատերերի կոմունալ ծառայություններ՝ կլաստերային հանգույց: Այս FS-ը և՛ տեղային է, և՛ ցանցային: Եվ ոչ ավելին։
Եթե Reiser4-ի հետ ոչինչ չստացվի Linux-ում, ես կցանկանայի առաջարկել FS FreeBSD-ի համար (մեջբերում նախորդ հարցազրույցից. «...FreeBSD... ունի ակադեմիական արմատներ... Եվ սա նշանակում է, որ մենք մեծ հավանականությամբ ընդհանուր լեզու կգտնի մշակողների հետ»):
Այսպիսով, ինչպես հենց նոր պարզեցինք, Linux-ի հետ ամեն ինչ արդեն հիանալի է ստացվել. դրա համար կա առանձին աշխատող Reiser4 պորտ՝ մեր պահեստի գլխավոր մասնաճյուղի տեսքով: Ես չեմ մոռացել FreeBSD-ի մասին: Առաջարկ. Ես պատրաստ եմ սերտորեն աշխատել նրանց հետ, ովքեր լավ գիտեն FreeBSD-ի ինտերիերը: Ի դեպ, նրանց համայնքում ինձ իսկապես դուր է գալիս այն, որ այնտեղ որոշումները կայացնում է անկախ փորձագետներից կազմված նորացված խորհուրդը, ինչը կապ չունի մեկ մշտական մարդու կառավարության խաբեության հետ։
Ինչպե՞ս եք գնահատում Linux-ի օգտվողների համայնքն այսօր: Արդյո՞ք այն ավելի «փոփ» է դարձել:
Հաշվի առնելով իմ աշխատանքի բնույթը, ինձ համար բավականին դժվար է գնահատել սա։ Հիմնականում օգտատերերն ինձ մոտ են գալիս վրիպակների մասին հաշվետվություններով և բաժինը շտկելու հարցումներով: Օգտագործողները որպես օգտվողներ. Ոմանք ավելի խելացի են, ոմանք ավելի քիչ: Բոլորին նույն կերպ են վերաբերվում։ Դե, եթե օգտատերը անտեսում է իմ հրահանգները, ապա կներեք, անտեսելու կարգը նույնպես կմուտքագրվի իմ կողմից։
Հնարավո՞ր է արդյոք կանխատեսել ֆայլային համակարգերի զարգացումը առաջիկա հինգից տասը տարիների ընթացքում: Ի՞նչ եք կարծում, որո՞նք են այն հիմնական մարտահրավերները, որոնց կարող են հանդիպել FS մշակողները:
Այո, դժվար չէ նման կանխատեսում անել։ Վերին հոսքում վաղուց ֆայլային համակարգերի զարգացում չկա: Այդպիսիների միայն արտաքին տեսքն է ստեղծվում։ Տեղական ֆայլային համակարգերի մշակողները բախվեցին վատ դիզայնի հետ կապված խնդիրների: Այստեղ անհրաժեշտ է նախազգուշացում անել. Կոդի այսպես կոչված «պահեստավորումը», «լիզելը» և տեղափոխելը զարգացում և զարգացում չեմ համարում։ Իսկ «Բտրֆս» կոչվող թյուրիմացությունը զարգացում չեմ դասում արդեն բացատրածս պատճառներով։
Յուրաքանչյուր կարկատել միայն ավելի է վատացնում իր խնդիրները: Դե, և միշտ կան տարբեր տեսակի «ավետարանիչներ», որոնց համար «ամեն ինչ գործում է»: Հիմնականում դրանք դասախոսություններից շրջանցող դպրոցականներն ու ուսանողներն են։ Պատկերացրեք՝ դա աշխատում է նրա մոտ, իսկ պրոֆեսորը՝ ոչ: Ինչպիսի՜ ադրենալին է սա: Իմ տեսանկյունից ամենամեծ վնասը հասցնում են «արհեստավորները», ովքեր շտապեցին խանդավառությամբ «պտտել» Btrfs-ի հրաշալի հատկությունները բոլոր տեսակի շերտերի վրա, ինչպիսիք են systemd-ը, docker-ը և այլն: - սա արդեն մետաստազների է նմանվում:
Հիմա փորձենք հինգից տասը տարվա կանխատեսում անել։ Ես արդեն հակիրճ թվարկել եմ, թե ինչ ենք անելու Reiser4-ում։ Գլխավոր մարտահրավերը տեղական FS-ի ծրագրավորողների համար վերին հոսանքով կլինի (այո, դա արդեն դարձել է) աշխատավարձի դիմաց արժանապատիվ աշխատանք կատարելու անկարողությունը: Առանց տվյալների պահպանման ոլորտում որևէ գաղափարի, նրանք կշարունակեն փորձել կարկատել այս դժբախտ VFS, XFS և ext4: VFS-ի հետ կապված իրավիճակը հատկապես զավեշտական է թվում այս ֆոնին, որը հիշեցնում է ռեստորանի մոլեգնած արդիականացումը, որտեղ խոհարարներ չկան և խոհարարներ չեն սպասվում:
Այժմ VFS կոդը, առանց որևէ պայմանի, միաժամանակ կողպում է հիշողության մի քանի էջ և հրավիրում է հիմքում ընկած FS-ին աշխատել դրանք: Սա ներդրվել է Ext4-ի աշխատանքը ջնջելու գործողությունների ժամանակ բարելավելու համար, սակայն, ինչպես հեշտ է հասկանալ, նման միաժամանակյա կողպումը լիովին անհամատեղելի է գործարքների առաջադեմ մոդելների հետ: Այսինքն, դուք չեք կարողանա պարզապես աջակցություն ավելացնել միջուկում որոշ խելացի ֆայլային համակարգի համար: Ես չգիտեմ, թե ինչ իրավիճակ է Linux-ի այլ ոլորտներում, բայց ինչ վերաբերում է ֆայլային համակարգերին, այստեղ որևէ զարգացում դժվար թե համատեղելի լինի Torvalds-ի վարած քաղաքականության հետ գործնականում (ակադեմիական նախագծերը դուրս են մղվում, և խաբեբաները, ովքեր չգիտեմ, թե ինչ B-tree, վստահության անվերջ վարկեր են տրվում): Հետևաբար, դանդաղ քայքայման ուղղություն է սահմանվել։ Իհարկե, նրանք ամբողջ ուժով կփորձեն դա որակել որպես «զարգացում»։
Ավելին, ֆայլային համակարգերի «պահառուները», հասկանալով, որ միայն «պահեստից» չես կարող շատ բան վաստակել, կփորձեն իրենց ուժերը ավելի շահավետ բիզնեսում: Սրանք, որպես կանոն, բաշխված ֆայլային համակարգեր և վիրտուալացում են։ Միգուցե նրանք տեղափոխեն նորաձև ZFS-ը մեկ այլ տեղ, որտեղ այն դեռ գոյություն չունի: Բայց այն, ինչպես բոլոր FS-ները վերևից, նման է Ամանորի ծառի. եթե դուք կարող եք մի քանի այլ մանր իրեր կախել վերևից, ապա չեք կարող ավելի խորանալ: Ես ընդունում եմ, որ ZFS-ի հիման վրա կարելի է կառուցել ձեռնարկատիրական լուրջ համակարգ, բայց քանի որ մենք հիմա քննարկում ենք ապագան, ցավով կարող եմ միայն փաստել, որ ZFS-ն այս հարցում անհույս է. տղերքը իրենց վիրտուալ սարքերով կտրել են թթվածինը։ իրենց և ապագա սերունդների համար՝ հետագա զարգացման համար։ ZFS-ն անցյալում է: Իսկ ext4-ն ու XFS-ը նույնիսկ նախօրեին չեն։
Առանձին-առանձին հարկ է նշել «հաջորդ սերնդի Linux ֆայլային համակարգի» սենսացիոն հայեցակարգի մասին։ Սա լիովին քաղաքական և մարքեթինգային նախագիծ է, որը ստեղծվել է, այսպես ասած, Linux-ում «ֆայլային համակարգերի ապագան» հատուկ նիշերի հետևում ամրացնելու հնարավորության համար: Փաստն այն է, որ Linux-ը նախկինում եղել է «միայն զվարճանքի համար»: Բայց հիմա դա առաջին հերթին փող աշխատելու մեքենա է։ Դրանք պատրաստված են հնարավոր ամեն ինչի վրա։ Օրինակ, լավ ծրագրային արտադրանք ստեղծելը շատ դժվար է, բայց խելացի «մշակողները» վաղուց հասկացել են, որ ամենևին էլ լարվելու կարիք չկա. դուք կարող եք հաջողությամբ վաճառել գոյություն չունեցող ծրագրակազմ, որը հայտարարվել և գովազդվել է բոլոր տեսակի հանրության շրջանում: իրադարձություններ - գլխավորն այն է, որ ներկայացման սլայդները պետք է պարունակեն ավելի շատ «հատկություններ»:
Ֆայլային համակարգերը կատարյալ են դրա համար, քանի որ դուք կարող եք ապահով կերպով սակարկել տասը տարի արդյունքի վրա: Դե, եթե ինչ-որ մեկը հետագայում բողոքում է հենց այս արդյունքի բացակայությունից, ապա նա պարզապես ոչինչ չի հասկանում ֆայլային համակարգերից: Սա ֆինանսական բուրգ է հիշեցնում. վերևում արկածախնդիրներն են, ովքեր սկսել են այս խառնաշփոթը, և այն քչերը, ովքեր «բախտավոր» են եղել. նրանք «դիվիդենտներ են հանել», այսինքն. գումար է ստացել զարգացման համար, լավ վարձատրվող աշխատանք ստացել որպես մենեջեր, «ներկայացել» կոնֆերանսներին և այլն։
Հաջորդը գալիս են նրանք, ովքեր «անհաջողակ» են. նրանք կհաշվեն կորուստները, կզբաղվեն արտադրության մեջ անօգտագործելի ծրագրային արտադրանքի տեղակայման հետևանքներով և այլն: Դրանք շատ ավելին են։ Դե, բուրգի հիմքում կա ծրագրավորողների հսկայական զանգված, որոնք «սղում են» անպետք ծածկագիրը։ Նրանք ամենամեծ պարտվողներն են, քանի որ կորցրած ժամանակը չի կարող վերադարձվել։ Նման բուրգերը չափազանց ձեռնտու են Տորվալդսին և նրա համախոհներին։ Եվ որքան շատ լինեն այս բուրգերը, այնքան լավ նրանց համար: Նման բուրգերը կերակրելու համար ամեն ինչ կարելի է վերցնել միջուկ: Իհարկե, հանրության մեջ հակառակն են ասում. Բայց ես դատում եմ ոչ թե խոսքերով, այլ գործերով։
Այսպիսով, «Լինուքսում ֆայլային համակարգերի ապագան» ևս մեկ բարձր խթանված, բայց դժվար օգտագործելի ծրագիր է: Btrfs-ից հետո, մեծ հավանականությամբ, նման «ապագայի» տեղը կզբաղեցնի Bcachefs-ը, որը Linux բլոկ շերտը ֆայլային համակարգով հատելու հերթական փորձն է (վատ օրինակը վարակիչ է)։ Իսկ ինչն է բնորոշ՝ կան նույն խնդիրները, ինչ Btrfs-ում։ Ես դա երկար ժամանակ կասկածում էի, և հետո ինչ-որ կերպ չկարողացա դիմադրել և նայեցի ծածկագիրը. դա ճիշտ է:
Bcachefs-ի և Btrfs-ի հեղինակները, երբ ստեղծում էին իրենց FS-ն, ակտիվորեն օգտագործում էին այլ մարդկանց աղբյուրները՝ քիչ բան հասկանալով դրանց մասին։ Իրավիճակը շատ է հիշեցնում մանկական «փչացած հեռախոս» խաղը։ Եվ ես մոտավորապես պատկերացնում եմ, թե ինչպես է այս կոդը ներառվելու միջուկում։ Փաստորեն, ոչ ոք չի տեսնի «ռեկերը» (հետո բոլորը ոտք կդնեն): Կոդի ոճի մասին բազմաթիվ վիճաբանություններից հետո, գոյություն չունեցող խախտումների մեղադրանքներից և այլն, եզրակացություն կարվի հեղինակի «հավատարմության» մասին, թե որքանով է նա «շփվում» այլ մշակողների հետ, և որքանով է հաջողությամբ կարող այս ամենը։ այնուհետև վաճառվել կորպորացիաներին:
Վերջնական արդյունքը ոչ մեկին չի հետաքրքրի։ Քսան տարի առաջ, երևի, ինձ կհետաքրքրեր, բայց հիմա հարցն այլ կերպ է դրվում՝ հնարավո՞ր է դա նպաստել, որ առաջիկա տասը տարիների ընթացքում որոշակի մարդիկ աշխատանքի ընդունվեն։ Եվ, ավաղ, ընդունված չէ զարմանալ վերջնական արդյունքի վրա։
Ընդհանրապես, ես կտրականապես խորհուրդ կտայի չսկսել զրոյից վերահայտնագործել ձեր ֆայլային համակարգը: Որովհետև նույնիսկ զգալի ֆինանսական ներդրումները չեն բավականացնի տասը տարում ինչ-որ մրցունակ բան ստանալու համար։ Խոսքս, իհարկե, լուրջ նախագծերի մասին է, այլ ոչ թե նրանց, որոնք նախատեսված են միջուկ «մղելու»։ Այսպիսով, արտահայտվելու ավելի արդյունավետ միջոցը մեզ նման իրական զարգացումներին միանալն է։ Դա, իհարկե, հեշտ չէ անել, բայց դա այդպես է ցանկացած բարձր մակարդակի նախագծի դեպքում:
Նախ, դուք պետք է ինքնուրույն հաղթահարեք այն խնդիրը, որը ես կառաջարկեմ: Որից հետո, համոզվելով ձեր մտադրությունների լրջության մեջ, ես կսկսեմ օգնել։ Ավանդաբար մենք օգտագործում ենք միայն մեր սեփական մշակումները: Բացառություն են կազմում սեղմման ալգորիթմները և որոշ հեշ ֆունկցիաներ: Մենք ծրագրավորողներին չենք ուղարկում կոնֆերանսների ճանապարհորդելու, այնուհետև չենք նստում և չենք համատեղում այլ մարդկանց գաղափարները («գուցե ինչ կլինի»), ինչպես ընդունված է ստարտափների մեծ մասում:
Մենք ինքներս ենք մշակում բոլոր ալգորիթմները: Ներկայումս ինձ հետաքրքրում է տվյալների պահպանման գիտության հանրահաշվական և կոմբինատորական ասպեկտները: Մասնավորապես՝ վերջավոր դաշտեր, ասիմպտոտիկա, անհավասարությունների ապացույց։ Աշխատանք կա նաև սովորական ծրագրավորողների համար, բայց ես պետք է անմիջապես զգուշացնեմ. «այլ FS-ին նայելու և նույնն անելու» բոլոր առաջարկներն անտեսվում են: Այնտեղ կգնան նաև Linux-ի հետ VFS-ի միջոցով ավելի սերտ ինտեգրմանն ուղղված patches:
Այսպիսով, մենք փոցխ չունենք, բայց մենք հասկանում ենք, թե ուր պետք է շարժվենք, և մենք վստահ ենք, որ այս ուղղությունը ճիշտ է: Այս հասկացողությունը չի եկել երկնքից մանանայի տեսքով: Հիշեցնեմ, որ մենք մեր հետևում ունենք 29 տարվա զարգացման փորձ, երկու ֆայլային համակարգ՝ գրված զրոյից։ Եվ նույն քանակությամբ տվյալների վերականգնման կոմունալ ծառայություններ: Եվ սա շատ է!
Source: opennet.ru