Mae'r ail gyfweliad ag Eduard Shishkin, datblygwr system ffeiliau Reiser4, wedi'i gyhoeddi.
I ddechrau, atgoffwch y darllenwyr ble ac i bwy rydych chi'n gweithio.
Rwy'n gweithio fel Prif Bensaer Storio yn Huawei Technologies, Canolfan Ymchwil yr Almaen. Yn yr adran rhithwiroli rwy'n delio â gwahanol agweddau ar storio data. Nid yw fy ngweithgareddau'n gysylltiedig â system weithredu benodol.
A ydych chi'n ymrwymo i'r brif gangen gnewyllyn ar hyn o bryd?
Yn anaml iawn, a dim ond os yw fy nghyflogwr ei angen. Y tro diwethaf oedd tua thair blynedd yn ôl, anfonais glytiau i gynyddu'r trwygyrch ar gyfer storio a rennir ar westeion gan ddefnyddio'r protocol 9c (enw arall ar y busnes hwn yw VirtFS). Rhaid gwneud un nodyn pwysig yma: er fy mod wedi bod yn gweithio gyda Linux ers amser maith, nid wyf erioed wedi bod yn gefnogwr ohono, hynny yw, rwy'n “anadlu'n gyfartal,” fel gyda phopeth arall. Yn benodol, os byddaf yn sylwi ar ddiffyg, gallaf ei nodi ar y mwyaf unwaith. Ac fel y gallwch wedyn ddilyn rhywun a'u perswadio - ni fydd hyn yn digwydd.
Rwy'n cofio y tro diwethaf, ddeng mlynedd yn ôl, roeddech yn eithaf beirniadol o'r arddull datblygu cnewyllyn. O'ch safbwynt chi (neu gorfforaethol efallai), a oes unrhyw beth wedi newid, a yw'r gymuned wedi dod yn fwy ymatebol ai peidio? Os na, pwy sydd ar fai yn eich barn chi?
Welais i erioed unrhyw newidiadau er gwell. Prif broblem y gymuned yw disodli gwyddoniaeth â thechnolegau gwleidyddol, perthnasoedd personol, barn y mwyafrif, poblyddiaeth, cyngor gan “leisiau mewnol,” cyfaddawdu pwdr, unrhyw beth heblaw gwyddoniaeth. Mae cyfrifiadureg, beth bynnag a ddywed rhywun, yn wyddor fanwl yn bennaf oll. Ac os bydd rhywun yn dechrau cyhoeddi eu gwerth eu hunain ar gyfer 2x2, yn wahanol i 4, o dan y faner “Linux way”, neu o dan ryw faner arall, yna mae hyn yn annhebygol o ddod ag unrhyw beth heblaw niwed.
Mae'r holl drafferthion yn bennaf oherwydd anghymhwysedd a diffyg addysg y rhai sy'n gwneud penderfyniadau. Os yw rheolwr yn anghymwys, ni all wneud penderfyniad gwrthrychol, digonol. Os yw hefyd yn ddiddiwylliant, ni all ddod o hyd i arbenigwr cymwys a fydd yn rhoi'r cyngor cywir iddo. Gyda thebygolrwydd uchel, bydd y dewis yn disgyn ar sgamiwr sy'n dweud "pethau sy'n ymddangos yn gywir." Mae amgylchedd llwgr bob amser yn datblygu o amgylch arweinwyr unigol anghymwys. Ar ben hynny, nid yw hanes yn gwybod unrhyw eithriadau yn hyn o beth, a'r gymuned yw'r cadarnhad cliriaf o hyn.
Sut ydych chi'n asesu'r cynnydd yn natblygiad Btrfs? A gafodd yr FS hwn wared ar afiechydon plentyndod? Sut ydych chi'n ei leoli i chi'ch hun - fel FS “ar gyfer cartref” neu at ddefnydd corfforaethol hefyd?
Wnes i ddim cael gwared ohono. Mae popeth y soniais amdano 11 mlynedd yn ôl yn dal yn berthnasol heddiw. Un o'r problemau gyda Btrfs sy'n ei gwneud yn anaddas ar gyfer anghenion difrifol yw'r broblem o le am ddim. Dydw i ddim hyd yn oed yn sôn am y ffaith y gofynnir i'r defnyddiwr redeg i'r siop am ddisg newydd mewn sefyllfaoedd lle byddai unrhyw FS arall yn dangos llawer o le am ddim ar y rhaniad. Nid yw'r anallu i gwblhau gweithrediad ar gyfaint rhesymegol oherwydd diffyg lle rhydd hefyd y peth gwaethaf. Y peth gwaethaf yw y gall defnyddiwr di-freintiedig bron bob amser, osgoi unrhyw gwotâu disg, amddifadu pawb o le rhydd mewn cyfnod gweddol fyr.
Mae'n edrych fel hyn (wedi'i brofi ar gyfer cnewyllyn Linux 5.12). Mae sgript yn cael ei lansio ar system newydd ei gosod, sydd mewn dolen yn creu ffeiliau ag enwau penodol yn y cyfeiriadur cartref, yn ysgrifennu data iddynt ar wrthbwyso penodol, ac yna'n dileu'r ffeiliau hyn. Ar ôl munud o redeg y sgript hon, nid oes dim byd anarferol yn digwydd. Ar ôl pum munud, mae cyfran y gofod a feddiannir ar y rhaniad yn cynyddu ychydig. Ar ôl dwy i dair awr mae'n cyrraedd 50% (gyda gwerth cychwynnol o 15%). Ac ar ôl pump neu chwe awr o waith, mae'r sgript yn chwalu gyda'r gwall “does dim lle rhydd ar y rhaniad.” Ar ôl hyn, ni fyddwch bellach yn gallu ysgrifennu hyd yn oed ffeil 4K i'ch rhaniad.
Mae sefyllfa ddiddorol yn digwydd: ni wnaethoch chi ysgrifennu unrhyw beth i'r rhaniad yn y diwedd, a diflannodd yr holl ofod rhydd (tua 85%) yn rhywle. Bydd dadansoddiad o adran sy'n destun ymosodiad o'r fath yn datgelu llawer o nodau coed sy'n cynnwys un eitem yn unig (gwrthrych sydd ag allwedd), sawl beit o faint. Hynny yw, roedd y cynnwys a arferai feddiannu 15% o'r gofod disg wedi'i “gwasgu” yn gyfartal dros y rhaniad cyfan fel nad oes unrhyw le i ysgrifennu ffeil newydd, oherwydd bod ei allwedd yn fwy na'r holl rai presennol, ac yn rhad ac am ddim blociau ar y pared wedi rhedeg allan.
Ar ben hynny, mae hyn i gyd yn digwydd eisoes ar ffurfweddiad sylfaenol Btrfs (heb unrhyw gipluniau, is-gyfrolau, ac ati), ac nid oes ots sut rydych chi'n penderfynu storio cyrff ffeiliau yn yr FS hwnnw (fel “darnau” mewn coeden, neu fel meintiau o flociau heb eu fformatio) - bydd y canlyniad terfynol yr un peth.
Ni fyddwch yn gallu peri ymosodiad o'r fath ar systemau ffeiliau eraill i fyny'r afon (ni waeth beth maent yn ei ddweud wrthych). Esboniais achos y broblem amser maith yn ôl: mae hwn yn wyrdroad llwyr o'r cysyniad B-coed yn Btrfs, sy'n ei gwneud hi'n bosibl iddo ddirywio'n ddigymell neu'n fwriadol. Yn benodol, o dan lwythi penodol, bydd eich system ffeiliau yn “syrthio” yn barhaus yn ystod gweithrediad ar ei phen ei hun, heb gymorth allanol. Mae’n amlwg y bydd pob math o brosesau cefndir “pwyso” yn arbed y dydd ar benbyrddau unigol yn unig.
Ar weinyddion ar y cyd, bydd ymosodwr bob amser yn gallu “mynd ar y blaen” ohonynt. Ni fydd gweinyddwr y system hyd yn oed yn gallu pennu pwy yn union a'i bu'n ei fwlio. Y ffordd gyflymaf o ddatrys y broblem hon mewn Btrfs yw adfer strwythur coeden B arferol, h.y. ailgynllunio fformat y ddisg ac ailysgrifennu rhannau sylweddol o god Btrfs. Bydd hyn yn cymryd 8-10 mlynedd, gan gynnwys dadfygio, ar yr amod bod y datblygwyr yn dilyn yr erthyglau gwreiddiol ar yr algorithmau a'r strwythurau data perthnasol yn llym, ac nad oeddent wedi chwarae'r gêm “ffôn wedi torri”, fel sy'n arferol (ac yn cael ei annog) yn y “Linux ffordd”.
Yma mae angen i ni hefyd ychwanegu'r amser sydd ei angen i ddatblygwyr ddeall hyn i gyd. Dyma lle mae'n mynd yn fwy anodd. Beth bynnag, nid oedd 10 mlynedd yn ddigon iddynt ei ddeall. Wel, tan hynny ni allwch obeithio am wyrth. Ni fydd yn digwydd ar ffurf opsiwn mowntio “nad oeddech chi a minnau yn gwybod amdano,” neu ar ffurf darn sy'n “fater o fusnes yn unig” i'w baratoi. Ar gyfer pob “atgyweiriad” brysiog, byddaf yn cyflwyno senario newydd o ddirywiad. Mae coed-B yn un o fy hoff bynciau, a rhaid i mi ddweud nad yw'r strwythurau hyn yn goddef rhyddid â nhw eu hunain!
Sut mae lleoli Btrfs i mi fy hun? Fel rhywbeth na ellir ei alw'n system ffeiliau o gwbl, heb sôn am ei ddefnyddio. Oherwydd, trwy ddiffiniad, mae'r FS yn is-system OS sy'n gyfrifol am reoli'r adnodd “gofod disg” yn effeithiol, nad ydym yn ei weld yn achos Btrfs. Wel, dychmygwch eich bod wedi dod i'r siop i brynu oriawr er mwyn peidio â bod yn hwyr i'r gwaith, ac yn lle oriawr fe wnaethant werthu gril trydan i chi gydag amserydd am uchafswm o 30 munud. Felly, mae'r sefyllfa gyda Btrfs hyd yn oed yn waeth.
Wrth edrych trwy restrau postio, rwy'n aml yn dod ar draws y datganiad nad yw rheoli gofod disg yn effeithiol bellach yn berthnasol oherwydd rhad y gyriannau. Mae hyn yn nonsens llwyr. Heb reolwr gofod disg effeithiol, bydd yr OS yn dod yn agored i niwed ac yn annefnyddiadwy. Waeth beth yw cynhwysedd y disgiau ar eich peiriant.
Hoffwn ofyn am sylw ar derfynu cefnogaeth Btrfs yn RHEL.
Does dim byd arbennig i wneud sylw arno yma, mae popeth yn glir iawn. Roedd ganddyn nhw hefyd fel “rhagolwg technoleg”. Felly, es i ddim trwy'r “rhagolwg” iawn hwn. Peidiwch â gadael i'r label hwn hongian am byth! Ond ni allant lansio cynnyrch sgil-gynllunio diffygiol gyda chefnogaeth lawn. Mae RHEL yn fenter, hynny yw, cysylltiadau nwyddau-arian rhagnodedig. Ni all Red Hat fwlio defnyddwyr fel y maent ar restr bostio Btrfs. Dychmygwch y sefyllfa: mae cleient a dalodd ei arian caled am y ddisg a chithau hefyd am gefnogaeth, eisiau deall i ble yr aeth ei le ar y ddisg ar ôl iddo beidio ag ysgrifennu unrhyw beth i lawr. Beth fyddwch chi'n ei ateb i hyn?
Ymhellach. Mae cleientiaid Red Hat yn cynnwys banciau a chyfnewidfeydd mawr adnabyddus. Dychmygwch beth fyddai'n digwydd pe baent yn destun ymosodiadau DoS yn seiliedig ar y bregusrwydd a grybwyllwyd yn Btrfs. Pwy ydych chi'n meddwl sy'n gyfrifol am hyn? I’r rhai sydd ar fin pwyntio bys at linell y drwydded GPL, lle mae’n ysgrifenedig nad yw’r awdur yn gyfrifol am unrhyw beth, dywedaf ar unwaith: “cuddiwch hi!” Bydd Red Hat yn ateb, ac yn y fath fodd fel na fydd yn ymddangos yn ddigon! Ond gwn nad yw Red Hat yn wynebu’r math hwn o broblem, o ystyried eu tîm arbennig o gryf o beirianwyr SA y cefais gyfle i weithio’n agos gyda nhw yn fy amser.
Pam mae rhai cwmnïau'n parhau i gefnogi Btrfs yn eu cynhyrchion menter?
Sylwch nad yw'r rhagddodiad “menter” yn enw'r cynnyrch yn golygu llawer. Mae menter yn fesur o gyfrifoldeb sydd wedi'i ymgorffori yn y berthynas gytundebol â'r cleient. Gwn am un fenter yn unig sy'n seiliedig ar GNU/Linux - RHEL. Dim ond fel menter y cyflwynir popeth arall, o’m safbwynt i, ond nid yw’n un. Ac yn olaf, os oes galw am rywbeth, yna bydd cyflenwad bob amser (yn ein hachos ni, dyma'r "cymorth" a grybwyllir). Mae galw am bopeth, gan gynnwys. a meddalwedd na ellir ei ddefnyddio. Mae sut mae galw o'r fath yn cael ei ffurfio a phwy sy'n ei danio yn bwnc arall.
Felly, ni fyddwn yn neidio i unrhyw gasgliadau ar ôl sôn bod Facebook wedi defnyddio Btrfs ar ei weinyddion. Ar ben hynny, byddwn yn argymell cadw cyfeiriadau'r gweinyddwyr hynny'n gyfrinachol yn ofalus am y rhesymau uchod.
Pam mae cymaint o ymdrech wedi'i wneud i lanhau'r cod XFS yn ddiweddar? Wedi'r cyfan, i ddechrau mae hon yn system ffeiliau trydydd parti, ac mae ext4 wedi bod yn sefydlog ers amser maith ac mae ganddo barhad o fersiynau blaenorol yr un mor sefydlog. Pa ddiddordeb sydd gan Red Hat yn XFS? A yw'n gwneud synnwyr mynd ati i ddatblygu dwy system ffeil sy'n debyg o ran pwrpas - ext4 a XFS?
Nid wyf yn cofio beth oedd wedi ysgogi hyn. Mae'n eithaf posibl bod y fenter wedi dod gan gleientiaid Red Hat. Rwy'n cofio bod ymchwil o'r math hwn wedi'i wneud: ar rai systemau ffeil o i fyny'r afon, crëwyd nifer enfawr o wrthrychau ar yriannau pen uchel y genhedlaeth newydd. Yn ôl y canlyniadau, roedd XFS yn ymddwyn yn well nag ext4. Felly dechreuon nhw ei hyrwyddo fel y mwyaf addawol. Beth bynnag, ni fyddwn yn edrych am unrhyw beth cyffrous yma.
I mi, mae fel eu bod wedi disodli awl gyda sebon. Nid oes diben datblygu ext4 a XFS. Y ddau yn gyfochrog ac unrhyw un ohonynt i ddewis ohonynt. Ni ddaw dim da o hyn. Er, o ran natur, yn aml mae sefyllfaoedd pan fo llawer o botensial ar gyfer twf, ond nid oes lle i dyfu. Yn yr achos hwn, mae tyfiannau newydd rhyfedd o hyll yn codi, y mae pawb yn pwyntio bys ato ("O, edrychwch, yr hyn na welwch yn y bywyd hwn!").
Ydych chi'n meddwl bod y mater o dorri haen wedi'i setlo (mewn ystyr negyddol) gyda dyfodiad swyddogaethau amgryptio yn ext4, F2FS (heb sôn am RAID yn Btrfs)?
Yn gyffredinol, mater o bolisi fel arfer yw cyflwyno unrhyw lefelau a gwneud penderfyniad ynghylch peidio â thorri rheolau, ac nid wyf yn ymrwymo i wneud sylwadau ar unrhyw beth yma. Nid yw'r agweddau gwrthrychol ar dorri haen o ddiddordeb mawr i unrhyw un, ond gallwn ystyried rhai ohonynt gan ddefnyddio'r enghraifft o dorri "o'r uchod," sef, gweithredu ymarferoldeb yn yr FS sydd eisoes yn bodoli ar yr haen bloc. Mae “trosedd” o’r fath wedi’i gyfiawnhau gyda dim ond eithriadau prin. Ar gyfer pob achos o'r fath, rhaid i chi brofi dau beth yn gyntaf: bod ei wir angen, ac na fydd dyluniad y system yn cael ei niweidio trwy wneud hynny.
Er enghraifft, mae adlewyrchu, sydd yn draddodiadol wedi bod yn weithgaredd ar gyfer yr haen bloc, yn gwneud synnwyr i'w weithredu ar lefel y system ffeiliau. Am wahanol resymau. Er enghraifft, mae llygredd data “tawel” (pydredd did) yn digwydd ar yriannau disg. Dyma pan fydd y ddyfais yn gweithio'n iawn, ond mae'r data bloc yn cael ei niweidio'n annisgwyl o dan ddylanwad cwantwm gama caled a allyrrir gan gwasar pell, ac ati. Y peth gwaethaf yw os yw'r bloc hwn yn troi allan i fod yn bloc system FS (superblock, bloc didfap, nod coeden storio, ac ati), oherwydd bydd hyn yn sicr yn arwain at banig cnewyllyn.
Sylwch na fydd y drychau a gynigir gan yr haen bloc (yr hyn a elwir yn RAID 1) yn eich arbed rhag y broblem hon. Wel, mewn gwirionedd: dylai rhywun wirio'r sieciau a darllen y replica rhag ofn y bydd yn methu? Yn ogystal, mae'n gwneud synnwyr i adlewyrchu nid yn unig popeth, ond dim ond y metadata. Gellir storio rhywfaint o ddata pwysig (er enghraifft, ffeiliau gweithredadwy o gymwysiadau hanfodol) fel metadata. Yn yr achos hwn, maent yn derbyn yr un gwarantau diogelwch. Mae'n gwneud synnwyr i ymddiried amddiffyniad y data sy'n weddill i is-systemau eraill (efallai hyd yn oed ceisiadau defnyddwyr) - rydym wedi darparu'r holl amodau angenrheidiol ar gyfer hyn.
Mae gan ddrychau “economaidd” o'r fath yr hawl i fodoli, a dim ond ar lefel y system ffeiliau y gellir eu trefnu'n effeithiol. Fel arall, mae torri haenu yn annibendod is-system gyda chod dyblyg er mwyn rhai buddion microsgopig. Enghraifft drawiadol o hyn yw gweithredu RAID-5 gan ddefnyddio FS. Mae datrysiadau o'r fath (RAID / LVM eich hun yn y system ffeiliau) yn lladd yr olaf mewn termau pensaernïol. Dylid nodi yma hefyd bod gwahanol fathau o sgamwyr marchnata yn rhoi'r groes haenu ar waith. Yn absenoldeb unrhyw syniadau, mae ymarferoldeb sydd wedi'i weithredu ers amser maith ar lefelau cyfagos yn cael ei ychwanegu at yr is-systemau, mae hyn yn cael ei gyflwyno fel nodwedd hynod ddefnyddiol newydd ac yn cael ei wthio'n weithredol.
Cyhuddwyd Reiser4 o dorri’r lefelau “o is”. Yn seiliedig ar y ffaith nad yw'r system ffeiliau yn fonolithig, fel pob un arall, ond yn fodiwlaidd, gwnaed rhagdybiaeth ddi-sail ei bod yn gwneud yr hyn y dylai'r lefel uchod (VFS) ei wneud.
A yw'n bosibl siarad am farwolaeth ReiserFS v3.6 ac, er enghraifft, JFS? Yn ddiweddar nid ydynt wedi cael bron dim sylw yn y craidd. Ydyn nhw wedi darfod?
Yma mae angen i ni ddiffinio beth mae marwolaeth cynnyrch meddalwedd yn ei olygu. Ar y naill law, maent yn cael eu defnyddio'n llwyddiannus (dyna y cawsant eu creu ar ei gyfer, wedi'r cyfan), sy'n golygu eu bod yn byw. Ar y llaw arall, ni allaf siarad dros JFS (nid wyf yn gwybod llawer), ond mae ReiserFS (v3) yn anodd iawn ei addasu i dueddiadau newydd (wedi'u profi'n ymarferol). Mae hyn yn golygu y bydd datblygwyr yn y dyfodol yn talu sylw nid iddo, ond i'r rhai sy'n haws eu haddasu. O'r ochr hon mae'n troi allan, gwaetha'r modd, ei fod yn farw mewn termau pensaernïol. Ni fyddwn yn trin y cysyniad o “foesol ddarfodedig” o gwbl. Mae'n berthnasol yn dda, er enghraifft, i gwpwrdd dillad, ond nid i gynhyrchion meddalwedd. Mae cysyniad o israddoldeb a rhagoriaeth mewn rhywbeth. Gallaf ddweud yn llwyr fod ReserFS v3 bellach yn israddol i Reiser4 ym mhopeth, ond mewn rhai mathau o lwyth gwaith mae'n well na phob FS arall i fyny'r afon.
Ydych chi'n gwybod am ddatblygiad FS Tux3 a HAMMER/HAMMER2 (FS ar gyfer DragonFly BSD)?
Ydym, rydym yn gwybod. Yn Tux3 roedd gen i ddiddordeb unwaith yn nhechnoleg eu cipluniau (yr hyn a elwir yn “fersiwn pwyntwyr”), ond yn Reiser4 byddwn yn fwy na thebyg yn mynd llwybr gwahanol. Rwyf wedi bod yn meddwl am gefnogi cipluniau ers amser maith ac nid wyf eto wedi penderfynu sut i'w gweithredu ar gyfer cyfrolau Reiser4 syml. Y ffaith amdani yw bod y dechneg rhifydd cyfeirio “diog” newydd a gynigiwyd gan Ohad Rodeh yn gweithio i goed B yn unig. Nid oes gennym ni nhw. Ar gyfer y strwythurau data hynny a ddefnyddir yn Reiesr4, nid yw cownteri “diog” wedi'u diffinio - er mwyn eu cyflwyno, mae angen datrys rhai problemau algorithmig, nad oes neb wedi'u cymryd eto.
Yn ôl HAMMER: Darllenais erthygl gan y crëwr. Dim diddordeb. Eto, B-coed. Mae'r strwythur data hwn yn anobeithiol wedi dyddio. Rydym wedi rhoi'r gorau iddo yn y ganrif ddiwethaf.
Sut ydych chi'n asesu'r galw cynyddol am FSs clwstwr rhwydwaith fel CephFS/GlusterFS/etc? A yw'r galw hwn yn golygu newid ym mlaenoriaethau datblygwyr tuag at FS rhwydwaith a sylw annigonol i FS lleol?
Ydy, mae newid o'r fath mewn blaenoriaethau wedi digwydd. Mae datblygiad systemau ffeiliau lleol wedi marweiddio. Ysywaeth, mae gwneud rhywbeth arwyddocaol ar gyfer cyfrolau lleol bellach yn eithaf anodd ac ni all pawb ei wneud. Nid oes neb eisiau buddsoddi yn eu datblygiad. Mae hyn tua’r un peth â gofyn i sefydliad masnachol ddyrannu arian ar gyfer ymchwil mathemategol – heb unrhyw frwdfrydedd byddant yn gofyn ichi sut y gallwch wneud arian ar theorem newydd. Nawr mae FS lleol yn rhywbeth sy’n ymddangos yn hudol “allan o’r bocs” ac “a ddylai weithio bob amser,” ac os nad yw’n gweithio, mae’n achosi grwgnach heb fynd i’r afael ag ef fel: “Ie, beth maen nhw’n ei feddwl!”
Dyna pam y diffyg sylw i FS lleol, er bod llawer o waith yn parhau yn y maes hwnnw. Ac ydy, mae pawb wedi troi at storfa ddosbarthedig, sydd wedi'i adeiladu ar sail systemau ffeiliau lleol sydd eisoes yn bodoli. Mae'n ffasiynol iawn nawr. Mae’r ymadrodd “Data Mawr” yn achosi rhuthr adrenalin i lawer, gan ei gysylltu â chynadleddau, gweithdai, cyflogau mawr, ac ati.
Pa mor rhesymol yw hi mewn egwyddor i weithredu'r system ffeiliau rhwydwaith yn y gofod cnewyllyn yn hytrach nag yn y gofod defnyddiwr?
Dull rhesymol iawn nad yw wedi’i roi ar waith yn unman eto. Yn gyffredinol, y cwestiwn ym mha le y dylid gweithredu system ffeiliau rhwydwaith yw “cleddyf dwyfin.” Wel, gadewch i ni edrych ar enghraifft. Cofnododd y cleient ddata ar beiriant anghysbell. Maent yn syrthio i mewn i'w cache tudalen ar ffurf tudalennau budr. Dyma'r swydd ar gyfer system ffeiliau rhwydwaith "porth tenau" yn y gofod cnewyllyn. Yna bydd y system weithredu yn hwyr neu'n hwyrach yn gofyn ichi ysgrifennu'r tudalennau hynny ar ddisg i'w rhyddhau. Yna daw'r modiwl rhwydwaith FS sy'n anfon IO ymlaen (anfon) i rym. Mae'n pennu i ba beiriant gweinydd (nôd gweinydd) y bydd y tudalennau hyn yn mynd.
Yna mae'r pentwr rhwydwaith yn cymryd drosodd (ac, fel y gwyddom, fe'i gweithredir yn y gofod cnewyllyn). Nesaf, mae nod y gweinydd yn derbyn y pecyn hwnnw gyda data neu fetadata ac yn cyfarwyddo'r modiwl storio backend (hy, yr FS lleol sy'n gweithredu yn y gofod cnewyllyn) i gofnodi'r holl bethau hyn. Felly, rydym wedi lleihau’r cwestiwn i ble y dylai’r modiwlau “anfon” a “derbyn” weithio. Os bydd unrhyw un o'r modiwlau hynny'n rhedeg yn y gofod defnyddwyr, bydd hyn yn anochel yn arwain at newid cyd-destun (oherwydd yr angen i ddefnyddio gwasanaethau cnewyllyn). Mae nifer y switshis o'r fath yn dibynnu ar y manylion gweithredu.
Os oes llawer o switshis o'r fath, yna bydd trwybwn storio (perfformiad I/O) yn lleihau. Os yw eich storfa backend yn cynnwys disgiau araf, yna ni fyddwch yn sylwi ar ostyngiad sylweddol. Ond os oes gennych ddisgiau cyflym (SSD, NVRAM, ac ati), yna mae newid cyd-destun eisoes yn dod yn “dagfa” a, thrwy arbed ar newid cyd-destun, gellir cynyddu perfformiad yn sylweddol. Y ffordd safonol o arbed arian yw symud modiwlau i ofod cnewyllyn. Er enghraifft, canfuom fod symud y gweinydd 9c o QEMU i'r cnewyllyn ar y peiriant gwesteiwr yn arwain at gynnydd triphlyg ym mherfformiad VirtFS.
Nid yw hyn, wrth gwrs, yn rhwydwaith FS, ond mae'n adlewyrchu hanfod pethau'n llawn. Anfantais yr optimeiddio hwn yw materion hygludedd. I rai, gall yr olaf fod yn hollbwysig. Er enghraifft, nid oes gan GlusterFS unrhyw fodiwlau yn y cnewyllyn o gwbl. Diolch i hyn, mae bellach yn gweithio ar lawer o lwyfannau, gan gynnwys NetBSD.
Pa gysyniadau y gallai FS lleol eu benthyca o rai rhwydwaith ac i'r gwrthwyneb?
Y dyddiau hyn, mae gan FSs rhwydwaith, fel rheol, ychwanegion dros FSs lleol, felly nid wyf yn deall yn iawn sut y gallwch chi fenthyca rhywbeth gan yr olaf. Wel, yn wir, gadewch i ni ystyried cwmni o 4 o weithwyr, lle mae pawb yn gwneud eu peth eu hunain: un yn dosbarthu, un arall yn anfon, y trydydd yn derbyn, y pedwerydd siopau. Ac mae'r cwestiwn, beth all y cwmni ei fenthyg gan ei weithiwr sy'n ei storio, yn swnio'n anghywir rywsut (mae eisoes wedi cael yr hyn y gallai fod wedi'i fenthyg ganddo ers amser maith).
Ond mae gan FSs lleol lawer i'w ddysgu o rai rhwydwaith. Yn gyntaf, dylech ddysgu oddi wrthynt sut i agregu cyfeintiau rhesymegol ar lefel uchel. Nawr yr hyn a elwir Mae systemau ffeiliau lleol “uwch” yn agregu cyfeintiau rhesymegol gan ddefnyddio technoleg “dyfais rithwir” a fenthycwyd gan LVM yn unig (yr un tramgwydd haenu heintus a weithredwyd gyntaf yn ZFS). Mewn geiriau eraill, mae trosi cyfeiriadau rhithwir (rhifau bloc) i rai go iawn ac yn ôl yn digwydd ar lefel isel (h.y., ar ôl i'r system ffeiliau gyhoeddi cais I/O).
Sylwch fod ychwanegu a thynnu dyfeisiau at gyfeintiau rhesymegol (nid drychau) a drefnwyd ar yr haen bloc yn arwain at broblemau y mae cyflenwyr “nodweddion” o'r fath yn weddol dawel yn eu cylch. Rwy'n siarad am ddarnio ar ddyfeisiau go iawn, a all gyrraedd gwerthoedd gwrthun, tra ar ddyfais rithwir mae popeth yn iawn. Fodd bynnag, ychydig o bobl sydd â diddordeb mewn dyfeisiau rhithwir: mae gan bawb ddiddordeb yn yr hyn sy'n digwydd ar eich dyfeisiau go iawn. Ond mae FS tebyg i ZFS (yn ogystal ag unrhyw FS ar y cyd â LVM) yn gweithio gyda dyfeisiau disg rhithwir yn unig (dyrannu cyfeiriadau disg rhithwir o blith y rhai rhad ac am ddim, dad-ddarnio'r dyfeisiau rhithwir hyn, ac ati). A does ganddyn nhw ddim syniad beth sy'n digwydd ar ddyfeisiau go iawn!
Nawr dychmygwch nad oes gennych unrhyw ddarniad sero ar y ddyfais rithwir (hynny yw, dim ond un maint enfawr sydd gennych yn byw yno), rydych chi'n ychwanegu disg at eich cyfaint rhesymegol, ac yna'n tynnu disg hap arall o'ch cyfaint rhesymegol ac yna'n ail-gydbwyso. A chymaint o weithiau. Nid yw'n anodd dychmygu y bydd gennych yr un graddau byw o hyd ar y ddyfais rithwir, ond ar ddyfeisiau go iawn ni welwch unrhyw beth da.
Y peth gwaethaf yw nad ydych chi hyd yn oed yn gallu cywiro'r sefyllfa hon! Yr unig beth y gallwch chi ei wneud yma yw gofyn i'r system ffeiliau ddarnio'r ddyfais rithwir. Ond bydd hi'n dweud wrthych fod popeth yn wych yno - dim ond un graddau sydd, mae darnio yn sero, ac ni all fod yn well! Felly, nid yw cyfeintiau rhesymegol wedi'u trefnu ar lefel bloc wedi'u bwriadu ar gyfer ychwanegu/dileu dyfeisiau dro ar ôl tro. Mewn ffordd dda, dim ond unwaith y mae angen i chi gydosod cyfaint rhesymegol ar y lefel bloc, ei roi i'r system ffeiliau, ac yna gwneud dim byd arall ag ef.
Yn ogystal, nid yw'r cyfuniad o is-systemau FS + LVM annibynnol yn caniatáu ystyried natur wahanol y gyriannau y mae cyfeintiau rhesymegol yn cael eu hagregu ohonynt. Yn wir, mae'n debyg eich bod wedi casglu cyfaint rhesymegol o HDD a dyfeisiau cyflwr solet. Ond yna bydd y cyntaf yn gofyn am ddarnio, ac ni fydd angen darnio'r olaf. Ar gyfer yr olaf, mae angen i chi gyhoeddi ceisiadau taflu, ond ar gyfer y cyntaf, nid, ac ati. Fodd bynnag, yn y cyfuniad hwn mae'n eithaf anodd dangos y fath ddetholusrwydd.
Sylwch, ar ôl creu eich LVM eich hun ar y system ffeiliau, nad yw'r sefyllfa'n gwella llawer. Ar ben hynny, trwy wneud hyn rydych mewn gwirionedd yn rhoi diwedd ar y gobaith o'i wella byth yn y dyfodol. Mae hyn yn ddrwg iawn. Gall gwahanol fathau o yriannau fyw ar yr un peiriant. Ac os nad yw'r system ffeiliau yn gwahaniaethu rhyngddynt, yna pwy fydd?
Mae problem arall yn aros am yr hyn a elwir. Systemau ffeiliau “Write-Anywhere” (mae hyn hefyd yn cynnwys Reiser4, os gwnaethoch nodi'r model trafodion priodol yn ystod y gosodiad). Rhaid i systemau ffeil o'r fath ddarparu offer dad-ddarnio sy'n ddigynsail o ran eu pŵer. Ac nid yw'r rheolwr cyfaint lefel isel yn helpu yma, ond dim ond yn rhwystro. Y ffaith yw, gyda rheolwr o'r fath, y bydd eich FS yn storio map o flociau am ddim o un ddyfais yn unig - un rhithwir. Yn unol â hynny, dim ond dyfais rithwir y gallwch chi ei ddad-ddarnio. Mae hyn yn golygu y bydd eich defragmenter yn gweithio am amser hir, ar un gofod enfawr o gyfeiriadau rhithwir.
Ac os oes gennych chi lawer o ddefnyddwyr yn gwneud trosysgrifiadau ar hap, yna bydd effaith ddefnyddiol dad-ddarniwr o'r fath yn cael ei leihau i sero. Mae'n anochel y bydd eich system yn dechrau arafu, a dim ond o flaen y diagnosis siomedig "dyluniad toredig" y bydd yn rhaid i chi blygu'ch dwylo. Bydd sawl defragmenters sy'n rhedeg ar yr un gofod cyfeiriad yn ymyrryd â'i gilydd yn unig. Mae'n fater hollol wahanol os ydych chi'n cynnal eich map eich hun o flociau am ddim ar gyfer pob dyfais go iawn. Bydd hyn i bob pwrpas yn cyfateb i'r broses ddarnio.
Ond dim ond os oes gennych chi reolwr cyfaint rhesymegol lefel uchel y gellir gwneud hyn. Nid oedd systemau ffeiliau lleol gyda rheolwyr o'r fath yn bodoli o'r blaen (o leiaf, nid wyf yn gwybod amdanynt). Dim ond systemau ffeiliau rhwydwaith (er enghraifft GlusterFS) oedd â rheolwyr o'r fath. Enghraifft bwysig iawn arall yw'r cyfleustodau gwirio cywirdeb cyfaint (fsck). Os ydych chi'n storio'ch map annibynnol eich hun o flociau rhad ac am ddim ar gyfer pob is-gyfrol, yna gellir cyfochri'r weithdrefn ar gyfer gwirio cyfaint rhesymegol yn effeithiol. Mewn geiriau eraill, mae niferoedd rhesymegol gyda rheolwyr lefel uchel yn graddio'n well.
Yn ogystal, gyda rheolwyr cyfaint lefel isel ni fyddwch yn gallu trefnu cipluniau llawn. Gyda systemau ffeiliau tebyg i LVM a ZFS, dim ond cipluniau lleol y gallwch eu cymryd, ond nid cipluniau byd-eang. Mae cipluniau lleol yn caniatáu ichi gyflwyno gweithrediadau ffeil rheolaidd yn ôl ar unwaith. Ac ni fydd unrhyw un yno yn dychwelyd gweithrediadau gyda chyfeintiau rhesymegol (ychwanegu / dileu dyfeisiau). Gadewch i ni edrych ar hyn gydag enghraifft. Ar ryw adeg, pan fydd gennych gyfaint rhesymegol o ddwy ddyfais A a B sy'n cynnwys 100 o ffeiliau, byddwch yn cymryd cipolwg o'r system S ac yna'n creu cant arall o ffeiliau.
Ar ôl hynny, rydych chi'n ychwanegu dyfais C at eich cyfaint, ac yn olaf yn dychwelyd eich system i giplun S. Cwestiwn: Sawl ffeil a dyfais sydd yn eich cyfaint rhesymegol ar ôl dychwelyd i S? Bydd 100 o ffeiliau, fel y gallech fod wedi dyfalu, ond bydd 3 dyfais - dyma'r un dyfeisiau A, B ac C, er ar yr adeg y crëwyd y ciplun dim ond dwy ddyfais oedd yn y system (A a B ). Ni ddaeth gweithrediad dyfais ychwanegu C yn ôl, ac os ydych chi nawr yn tynnu dyfais C o'r cyfrifiadur, bydd yn llygru'ch data, felly cyn ei ddileu bydd angen i chi berfformio gweithrediad drud yn gyntaf i dynnu'r ddyfais o'r ail-gydbwyso cyfaint rhesymegol, sy'n yn gwasgaru'r holl ddata o ddyfais C i ddyfeisiau A a B. Ond pe bai eich FS yn cefnogi cipluniau byd-eang, ni fyddai angen ail-gydbwyso o'r fath, ac ar ôl dychwelyd yn syth i S, gallech dynnu dyfais C o'r cyfrifiadur yn ddiogel.
Felly, mae cipluniau byd-eang yn dda oherwydd eu bod yn caniatáu ichi osgoi tynnu (ychwanegu) dyfais yn gostus o gyfaint rhesymegol (i gyfaint rhesymegol) gyda llawer iawn o ddata (wrth gwrs, os cofiwch “ciplun” eich system ar yr amser iawn). Gadewch imi eich atgoffa mai gweithrediadau ar unwaith yw creu cipluniau a rholio'r system ffeiliau yn ôl iddynt. Efallai y bydd y cwestiwn yn codi: sut mae hyd yn oed yn bosibl rholio llawdriniaeth yn ôl ar unwaith ar gyfaint rhesymegol a gymerodd dri diwrnod i chi? Ond mae'n bosibl! Ar yr amod bod eich system ffeiliau wedi'i dylunio'n gywir. Deuthum i fyny gyda'r syniad o "cipluniau 3D" o'r fath dair blynedd yn ôl, a'r llynedd fe wnes i batentu'r dechneg hon.
Y peth nesaf y dylai FSs lleol ei ddysgu o rai rhwydwaith yw storio metadata ar ddyfeisiau ar wahân yn yr un modd ag y mae FSs rhwydwaith yn eu storio ar beiriannau ar wahân (y gweinyddwyr metadata fel y'u gelwir). Mae yna gymwysiadau sy'n gweithio'n bennaf gyda metadata, a gellir cyflymu'r cymwysiadau hyn yn fawr trwy osod y metadata ar ddyfeisiau storio perfformiad uchel drud. Gyda'r cyfuniad FS + LVM, ni fyddwch yn gallu dangos y fath ddetholusrwydd: nid yw LVM yn gwybod beth sydd ar y bloc y gwnaethoch ei drosglwyddo iddo (data yno neu fetadata).
Ni chewch lawer o fudd o weithredu'ch LVM lefel isel eich hun yn yr FS o'i gymharu â'r cyfuniad FS + LVM, ond yr hyn y gallwch chi ei wneud yn dda iawn yw annibendod yr FS fel ei bod yn dod yn amhosibl yn ddiweddarach gweithio gyda'i god. Mae ZFS a Btrfs, a ruthrodd gyda dyfeisiau rhithwir, i gyd yn enghreifftiau clir o sut mae torri haenau yn lladd y system mewn termau pensaernïol Felly, pam ydw i hyn i gyd? Ar ben hynny, nid oes angen adeiladu eich LVM lefel isel eich hun yn y system ffeiliau. Yn lle hynny, mae angen i chi agregu dyfeisiau yn gyfeintiau rhesymegol ar lefel uchel, fel y mae rhai systemau ffeiliau rhwydwaith yn ei wneud gyda pheiriannau gwahanol (nodau storio). Yn wir, maen nhw'n gwneud hyn yn ffiaidd oherwydd y defnydd o algorithmau gwael.
Enghreifftiau o algorithmau cwbl ofnadwy yw'r cyfieithydd DHT yn system ffeiliau GlusterFS a'r map CRUSH fel y'i gelwir yn system ffeiliau Ceph. Nid oedd yr un o'r algorithmau a welais yn fy modloni o ran symlrwydd a scalability da. Felly roedd yn rhaid i mi gofio algebra a dyfeisio popeth fy hun. Yn 2015, wrth arbrofi gyda bwndeli dros swyddogaethau hash, lluniais a phatent rhywbeth sy'n addas i mi. Nawr gallaf ddweud bod yr ymgais i roi hyn i gyd ar waith wedi bod yn llwyddiannus. Nid wyf yn gweld unrhyw broblemau gyda scalability yn y dull newydd.
Bydd, bydd angen strwythur ar wahân ar gyfer pob is-gyfrol, fel bloc mawr yn y cof. Ydy hyn yn frawychus iawn? Yn gyffredinol, nid wyf yn gwybod pwy sy'n mynd i “ferwi'r cefnfor” a chreu cyfeintiau rhesymegol o gannoedd o filoedd neu fwy o ddyfeisiau ar un peiriant lleol. Os gall unrhyw un esbonio hyn i mi, byddaf yn ddiolchgar iawn. Yn y cyfamser, i mi marchnata bullshit yw hyn.
Sut roedd newidiadau yn yr is-system dyfais bloc cnewyllyn (er enghraifft, ymddangosiad blk-mq) yn effeithio ar y gofynion ar gyfer gweithredu FS?
Ni chawsant unrhyw effaith. Nid wyf yn gwybod beth fyddai'n digwydd ar yr haen bloc a fyddai'n ei gwneud hi'n angenrheidiol dylunio FS newydd. Mae rhyngwyneb rhyngweithio yr is-systemau hyn yn wael iawn. O ochr y gyrrwr, dim ond ymddangosiad mathau newydd o yriannau y dylai'r FS gael eu heffeithio, y bydd yr haen bloc yn cael ei addasu iddynt yn gyntaf, ac yna'r FS (ar gyfer reiser4 bydd hyn yn golygu ymddangosiad ategion newydd).
A yw ymddangosiad mathau newydd o gyfryngau (er enghraifft, SMR, neu hollbresenoldeb SSDs) yn golygu heriau sylfaenol newydd ar gyfer dylunio system ffeiliau?
Oes. Ac mae'r rhain yn gymhellion arferol ar gyfer datblygu FS. Gall heriau fod yn wahanol ac yn gwbl annisgwyl. Er enghraifft, rwyf wedi clywed am yriannau lle mae cyflymder gweithrediad I/O yn dibynnu'n fawr ar faint darn o ddata a'i wrthbwyso. Yn Linux, lle na all maint y bloc FS fod yn fwy na maint y dudalen, ni fydd gyriant o'r fath yn dangos ei alluoedd llawn yn ddiofyn. Fodd bynnag, os yw'ch system ffeiliau wedi'i dylunio'n gywir, yna mae siawns i chi gael llawer mwy allan ohoni.
Faint o bobl sy'n gweithio gyda chod Reiser4 ar wahân i chi ar hyn o bryd?
Llai nag yr hoffwn, ond nid wyf yn profi prinder dybryd o adnoddau ychwaith. Rwy'n fwy na bodlon ar gyflymder datblygiad Reiser4. Dydw i ddim yn mynd i “yrru ceffylau” - nid dyma'r maes cywir. Yma, “os ydych chi'n gyrru'n dawelach, byddwch chi'n dal i fynd!” System ffeiliau fodern yw'r is-system cnewyllyn mwyaf cymhleth, a gall y penderfyniadau dylunio anghywir ddadwneud blynyddoedd dilynol o waith dynol.
Drwy gynnig gwirfoddolwyr i weithredu rhywbeth, rwyf bob amser yn gwarantu y bydd yr ymdrechion yn sicr yn arwain at y canlyniad cywir, y gall fod galw amdano ar gyfer anghenion difrifol. Fel y deallwch, ni all fod llawer o warantau o'r fath ar unwaith. Ar yr un pryd, ni allaf sefyll “ffigurau” sy'n hyrwyddo'n ddigywilydd “nodweddion” meddalwedd sy'n amlwg yn annefnyddiadwy, gan dwyllo cannoedd o ddefnyddwyr a datblygwyr, ac ar yr un pryd eistedd a gwenu ar gopaon cnewyllyn.
A oes unrhyw gwmni wedi mynegi parodrwydd i gefnogi datblygiad Reiser4?
Oedd, roedd cynigion o'r fath, gan gynnwys. a chan werthwr mawr. Ond ar gyfer hyn roedd yn rhaid i mi symud i wlad arall. Yn anffodus, nid wyf yn 30 oed bellach, ni allaf dorri i ffwrdd a gadael fel yna ar y chwiban cyntaf.
Pa nodweddion sydd ar goll o Reiser4 ar hyn o bryd?
Nid oes unrhyw swyddogaeth “newid maint” ar gyfer cyfeintiau syml, yn debyg i'r hyn a geir yn ReiserFS(v3). Yn ogystal, ni fyddai gweithrediadau ffeil gyda'r faner DIRECT_IO yn brifo. Nesaf, hoffwn allu gwahanu cyfrol yn “is-gyfrolau semantig”, nad oes ganddynt faint sefydlog, ac y gellir eu gosod fel cyfrolau annibynnol. Mae'r problemau hyn yn dda i ddechreuwyr sydd am roi cynnig ar y “peth go iawn.”
Ac yn olaf, hoffwn gael cyfrolau rhesymegol rhwydwaith gyda gweithredu a gweinyddu syml (mae algorithmau modern eisoes yn caniatáu hyn). Ond yr hyn na fydd gan Reiser4 byth yn bendant yw RAID-Z, sgrubs, caches gofod am ddim, newidynnau 128-bit a nonsens marchnata eraill a gododd yn erbyn cefndir o brinder syniadau ymhlith datblygwyr rhai systemau ffeiliau.
A all popeth y gallai fod ei angen gael ei weithredu gan ategion?
Os siaradwn yn unig o ran rhyngwynebau ac ategion (modiwlau) sy'n eu gweithredu, yna nid popeth. Ond os ydych chi hefyd yn cyflwyno perthnasoedd ar y rhyngwynebau hyn, yna, ymhlith pethau eraill, bydd gennych chi'r cysyniadau o polymorphisms uwch, y gallwch chi eu profi eisoes. Dychmygwch eich bod yn ddamcaniaethol wedi rhewi system amser rhedeg sy'n canolbwyntio ar wrthrych, wedi newid gwerth y pwyntydd cyfarwyddiadau i bwyntio at ategyn arall sy'n gweithredu'r un rhyngwyneb X, ac yna'n dadrewi'r system fel ei bod yn parhau i weithredu.
Os nad yw'r defnyddiwr terfynol yn sylwi ar "amnewidiad" o'r fath, yna dywedwn fod gan y system amryffurfiaeth trefn sero yn y rhyngwyneb X (neu mae'r system yn heterogenaidd yn y rhyngwyneb X, sef yr un peth). Os yn awr mae gennych nid yn unig set o ryngwynebau, ond hefyd bod gennych berthnasoedd arnynt (graff rhyngwyneb), yna gallwch chi gyflwyno amryffurfedd o orchmynion uwch, a fydd yn nodweddu heterogenedd y system sydd eisoes yn “gymdogaeth” unrhyw ryngwyneb. Cyflwynais ddosbarthiad o’r fath amser maith yn ôl, ond, yn anffodus, ni ddigwyddodd erioed.
Felly, gyda chymorth ategion ac amlffurfiau uwch o'r fath, gallwch ddisgrifio unrhyw nodwedd hysbys, yn ogystal â "rhagweld" y rhai na chrybwyllwyd erioed. Nid wyf wedi gallu profi hyn yn llym, ond nid wyf ychwaith yn gwybod am wrthenghraifft eto. Yn gyffredinol, roedd y cwestiwn hwn yn fy atgoffa o “Rhaglen Erlangen” Felix Klein. Ar un adeg ceisiodd gynrychioli pob geometreg fel cangen o algebra (yn benodol, theori grŵp).
Nawr at y prif gwestiwn - sut mae pethau'n mynd gyda dyrchafiad Reiser4 i'r prif graidd? A oedd unrhyw gyhoeddiadau ar saernïaeth y system ffeiliau hon y bu ichi sôn amdanynt yn y cyfweliad diwethaf? Pa mor berthnasol yw'r cwestiwn hwn o'ch safbwynt chi?
Yn gyffredinol, rydym wedi bod yn gofyn am gael eu cynnwys yn y brif gangen ers tair blynedd. Roedd sylw olaf Reiser yn yr edefyn cyhoeddus lle gwnaed y cais tynnu yn parhau heb ei ateb. Felly nid yw pob cwestiwn pellach ar ein cyfer ni. Yn bersonol, nid wyf yn deall pam mae angen i ni “uno” i mewn i system weithredu benodol. Ar Linux, nid oedd y golau yn cydgyfeirio fel lletem. Felly, mae ystorfa ar wahân lle bydd sawl cangen-borthladd ar gyfer gwahanol OSes. Gall pwy bynnag sydd ei angen glonio'r porthladd cyfatebol a gwneud beth bynnag a fynnoch ag ef (o fewn y drwydded, wrth gwrs). Wel, os nad oes ei angen ar rywun, yna nid fy mhroblem i yw hi. Ar y pwynt hwn, cynigiaf ystyried y cwestiwn o “hyrwyddo i'r prif gnewyllyn Linux” fel y'i setlwyd.
Mae cyhoeddiadau ar bensaernïaeth FS yn berthnasol, ond hyd yn hyn rwyf ond wedi dod o hyd i amser ar gyfer fy nghanlyniadau newydd, yr wyf yn eu hystyried yn flaenoriaeth uwch. Peth arall yw fy mod yn fathemategydd, ac mewn mathemateg mae unrhyw gyhoeddiad yn grynodeb o theoremau a'u proflenni. Mae cyhoeddi unrhyw beth yno heb brawf yn arwydd o chwaeth drwg. Os byddaf yn profi neu'n gwrthbrofi unrhyw ddatganiad am bensaernïaeth yr FS yn drylwyr, yna'r canlyniad fydd pentyrrau o'r fath y bydd yn eithaf anodd eu cyrraedd. Pwy sydd ei angen? Mae'n debyg mai dyma pam mae popeth yn parhau i aros yn ei hen ffurf - y cod ffynhonnell a sylwadau iddo.
Beth sy'n newydd yn Reiser4 dros yr ychydig flynyddoedd diwethaf?
Mae'r sefydlogrwydd hir-ddisgwyliedig wedi dod i'r amlwg o'r diwedd. Un o'r rhai olaf i ymddangos oedd byg a arweiniodd at gyfeiriaduron "annileadwy". Yr anhawster oedd ei fod yn ymddangos yn unig yn erbyn cefndir o wrthdrawiadau hash enw a gyda lleoliad penodol o gofnodion cyfeiriadur mewn nod coeden. Fodd bynnag, ni allaf argymell Reiser4 ar gyfer cynhyrchu o hyd: ar gyfer hyn mae angen i chi wneud rhywfaint o waith gyda rhyngweithio gweithredol â gweinyddwyr systemau cynhyrchu.
Yn olaf, fe wnaethom lwyddo i weithredu ein syniad hirsefydlog - modelau trafodion gwahanol. Yn flaenorol, dim ond un model Macdonald-Reiser â chod caled oedd yn rhedeg Reiser4. Creodd hyn broblemau dylunio. Yn benodol, nid yw cipluniau yn bosibl mewn model trafodion o'r fath - byddant yn cael eu llygru gan gydran atomig o'r enw “OVERWRITE SET”. Ar hyn o bryd mae Reiser4 yn cefnogi tri model trafodiad. Yn un ohonynt (Ysgrifennwch-Anywhere), mae'r gydran atomig TROSSGRIFENNU SET yn cynnwys tudalennau system yn unig (delweddau o fapiau didau disg, ac ati), na ellir eu “ffotograffu” (y broblem cyw iâr ac wy).
Felly gellir gwireddu'r lluniau yn y ffordd orau bosibl nawr. Mewn model trafodaethol arall, mae'r holl dudalennau wedi'u haddasu yn mynd i'r SET OVERWRITE yn unig (hynny yw, cyfnodolyn pur ydyw yn ei hanfod). Mae'r model hwn ar gyfer y rhai a gwynodd am y darnio cyflym o raniadau Reiser4. Nawr yn y model hwn ni fydd eich rhaniad yn darnio'n gyflymach na gyda ReiserFS (v3). Mae'r tri model presennol, gyda rhai amheuon, yn gwarantu atomigedd gweithrediadau, ond gall modelau sy'n colli atomigrwydd a chadw cyfanrwydd yr adran yn unig fod yn ddefnyddiol hefyd. Gall modelau o'r fath fod yn ddefnyddiol ar gyfer pob math o gymwysiadau (cronfeydd data, ac ati), sydd eisoes wedi ymgymryd â rhai o'r swyddogaethau hyn. Mae'n hawdd iawn ychwanegu'r modelau hyn at Reiser4, ond wnes i ddim, oherwydd ni ofynnodd neb i mi, ac yn bersonol nid oes ei angen arnaf.
Ymddangosodd checksums metadata ac fe wnes i ychwanegu drychau “darbodus” iddynt yn ddiweddar (deunydd ansefydlog o hyd). Os bydd siec unrhyw floc yn methu, mae Reiser4 yn darllen y bloc cyfatebol ar unwaith o'r ddyfais replica. Sylwch na all ZFS a Btrfs wneud hyn: nid yw'r dyluniad yn caniatáu hynny. Yno mae'n rhaid i chi redeg proses sganio cefndir arbennig o'r enw “prysgwydd” ac aros iddi gyrraedd y bloc problemus. Mae rhaglenwyr yn ffigurol yn galw digwyddiadau o'r fath yn “faglodion.”
Ac yn olaf, mae cyfeintiau rhesymegol heterogenaidd wedi ymddangos, gan gynnig popeth na all ZFS, Btrfs, haen bloc, yn ogystal â chyfuniadau FS + LVM mewn egwyddor ei ddarparu - graddio cyfochrog, dyraniad cyfeiriad disg O(1), mudo data tryloyw rhwng is-gyfrolau. Mae gan yr olaf ryngwyneb defnyddiwr hefyd. Nawr gallwch chi symud y data poethaf yn hawdd i'r gyriant perfformiad uchaf ar eich cyfaint.
Yn ogystal, mae'n bosibl fflysio unrhyw dudalennau budr i yriant o'r fath ar frys, a thrwy hynny gyflymu'n sylweddol gymwysiadau sy'n aml yn galw fsync(2). Sylwaf nad yw'r swyddogaeth haen bloc, a elwir yn bcache, yn darparu rhyddid gweithredu o'r fath o gwbl. Mae cyfrolau rhesymegol newydd yn seiliedig ar fy algorithmau (mae yna batentau cyfatebol). Mae'r meddalwedd eisoes yn eithaf sefydlog, mae'n eithaf posibl rhoi cynnig arni, mesur perfformiad, ac ati. Yr unig anghyfleustra yw bod angen i chi ddiweddaru'r cyfluniad cyfaint â llaw am y tro a'i storio yn rhywle.
Hyd yn hyn rwyf wedi gallu gweithredu fy syniadau gan 10 y cant Fodd bynnag, rwyf wedi llwyddo yn yr hyn a ystyriais fel y peth anoddaf - cysylltu cyfrolau rhesymegol â gweithdrefn fflach sy'n perfformio'r holl gamau gweithredu gohiriedig yn reiser4. Mae hyn i gyd yn dal yn y gangen arbrofol “format41”.
A yw Reiser4 yn pasio xfstests?
O leiaf fe wnaeth i mi pan oeddwn yn paratoi'r datganiad diwethaf.
A yw'n bosibl mewn egwyddor gwneud Reiser4 yn rhwydwaith (clwstwr) FS gan ddefnyddio ategion?
Mae'n bosibl, a hyd yn oed yn angenrheidiol! Os byddwch chi'n creu ffeil rhwydwaith yn seiliedig ar system ffeiliau leol sydd wedi'i dylunio'n gywir, bydd y canlyniad yn drawiadol iawn! Mewn FSs rhwydwaith modern, nid wyf yn fodlon â phresenoldeb lefel storio backend, a weithredir gan ddefnyddio unrhyw FS lleol. Mae bodolaeth y lefel hon yn gwbl anghyfiawn. Rhaid i'r rhwydwaith FS ryngweithio'n uniongyrchol â'r haen bloc, a pheidio â gofyn i'r FS lleol greu unrhyw ffeiliau gwasanaeth eraill!
Yn gyffredinol, mae rhannu systemau ffeil yn lleol a rhwydwaith yn dod o'r un drwg. Deilliodd o amherffeithrwydd yr algorithmau a ddefnyddiwyd ddeng mlynedd ar hugain yn ôl, ac yn eu lle nid oes dim wedi'i gynnig eto. Dyma hefyd y rheswm dros ymddangosiad màs o gydrannau meddalwedd diangen (gwasanaethau amrywiol, ac ati). Mewn ffordd dda, dim ond un FS ddylai fod ar ffurf modiwl cnewyllyn a set o gyfleustodau defnyddwyr wedi'u gosod ar bob peiriant - nod clwstwr. Mae'r FS hwn yn lleol ac yn rhwydwaith. A dim byd mwy!
Os nad oes unrhyw beth yn gweithio gyda Reiser4 ar Linux, hoffwn gynnig FS ar gyfer FreeBSD (dyfyniad o gyfweliad blaenorol: “...FreeBSD... â gwreiddiau academaidd... Ac mae hyn yn golygu, gyda lefel uchel o debygolrwydd, ein bod ni yn dod o hyd i iaith gyffredin gyda'r datblygwyr”) ?
Felly, fel y gwnaethom ddarganfod, mae popeth eisoes wedi gweithio'n berffaith gyda Linux: mae porthladd Reiser4 sy'n gweithio ar wahân ar ei gyfer ar ffurf prif gangen o'n cadwrfa. Dydw i ddim wedi anghofio am FreeBSD! Cynnig! Rwy'n barod i weithio'n agos gyda'r rhai sy'n gwybod y tu mewn i FreeBSD yn dda. Gyda llaw: yr hyn yr wyf yn ei hoffi’n fawr am eu cymuned yw bod penderfyniadau yno’n cael eu gwneud gan gyngor wedi’i ddiweddaru o arbenigwyr annibynnol, nad oes a wnelo ddim â thwyll y llywodraeth o un person parhaol.
Sut ydych chi'n graddio cymuned defnyddwyr Linux heddiw? Ydy e wedi dod yn fwy “pop”?
O ystyried natur fy ngwaith, mae'n eithaf anodd i mi asesu hyn. Yn bennaf mae defnyddwyr yn dod ataf gydag adroddiadau nam a cheisiadau i drwsio'r adran. Defnyddwyr fel defnyddwyr. Mae rhai yn fwy craff, rhai yn llai. Mae pawb yn cael eu trin yr un fath. Wel, os yw'r defnyddiwr yn anwybyddu fy nghyfarwyddiadau, yna esgusodwch fi: bydd y gorchymyn anwybyddu yn cael ei nodi ar fy rhan i hefyd.
A yw'n bosibl rhagweld datblygiad systemau ffeiliau am y pump i ddeng mlynedd nesaf? Beth ydych chi'n meddwl yw'r prif heriau y gall datblygwyr FS eu hwynebu?
Ydy, nid yw'n anodd gwneud rhagolwg o'r fath. Nid oes unrhyw systemau ffeiliau wedi'u datblygu yn yr afon ers amser maith. Dim ond ymddangosiad o'r fath sy'n cael ei greu. Daeth datblygwyr systemau ffeiliau lleol i broblemau yn gysylltiedig â dylunio gwael. Mae angen gwneud cafeat yma. Nid wyf yn ystyried yr hyn a elwir yn “storio”, “llyfu” a chludo cod yn ddatblygiad a datblygiad. Ac nid wyf yn dosbarthu'r camddealltwriaeth o'r enw “Btrfs” fel datblygiad am y rhesymau yr wyf eisoes wedi'u hesbonio.
Mae pob clwt yn gwaethygu ei broblemau. Wel. ac y mae yna bob amser wahanol fathau o “efengylwyr” y mae “popeth yn gweithio iddynt.” Yn y bôn, plant ysgol a myfyrwyr yn sgipio darlithoedd yw'r rhain. Dychmygwch: mae'n gweithio iddo, ond nid yw'r athro yn gwneud hynny. Am rhuthr adrenalin yw hwn! O’m safbwynt i, mae’r niwed mwyaf yn cael ei achosi gan y “crefftwyr” a ruthrodd i “sgriwio” nodweddion gwych Btrfs yn frwdfrydig ar bob math o haenau fel systemd, docwr, ac ati. - mae hyn eisoes yn debyg i fetastasis.
Gadewch i ni nawr geisio gwneud rhagolwg am bump i ddeng mlynedd. Rwyf eisoes wedi rhestru'n fyr yr hyn y byddwn yn ei wneud yn Reiser4. Y brif her i ddatblygwyr FS lleol o i fyny'r afon fydd (ie, mae eisoes wedi dod) yr anallu i wneud swydd dda am gyflog. Heb unrhyw syniadau ym maes storio data, byddant yn parhau i geisio clytio'r VFS, XFS ac ext4 anffodus hyn. Mae'r sefyllfa gyda VFS yn edrych yn arbennig o ddoniol yn erbyn y cefndir hwn, sy'n atgoffa rhywun o'r moderneiddio gwyllt mewn bwyty lle nad oes cogyddion, ac ni ddisgwylir unrhyw gogyddion.
Nawr mae'r cod VFS, heb unrhyw amodau, yn cloi sawl tudalen cof ar yr un pryd ac yn gwahodd yr FS sylfaenol i weithredu arnynt. Cyflwynwyd hyn i wella perfformiad Ext4 ar weithrediadau dileu, ond fel sy'n hawdd ei ddeall, mae cloi cydamserol o'r fath yn gwbl anghydnaws â modelau trafodion uwch. Hynny yw, ni fyddwch yn gallu ychwanegu cefnogaeth ar gyfer rhywfaint o system ffeiliau smart yn y cnewyllyn. Nid wyf yn gwybod beth yw'r sefyllfa mewn meysydd eraill o Linux, ond cyn belled ag y mae systemau ffeiliau yn y cwestiwn, mae unrhyw ddatblygiad yma yn annhebygol o fod yn gydnaws â'r polisi a ddilynir gan Torvalds yn ymarferol (prosiectau academaidd yn cael eu cicio allan, a sgamwyr sy'n heb unrhyw syniad beth yw coeden B , credydau diddiwedd o ymddiriedaeth yn cael eu cyhoeddi). Felly, gosodwyd cwrs ar gyfer pydredd araf. Wrth gwrs, byddant yn ceisio gyda'u holl nerth i'w drosglwyddo fel “datblygiad.”
Ymhellach, bydd “ceidwaid” systemau ffeiliau, gan sylweddoli na fyddwch chi'n ennill llawer o “storio” yn unig, yn rhoi cynnig ar fusnes mwy proffidiol. Mae'r rhain, fel rheol, yn systemau ffeiliau dosbarthedig a rhithwiroli. Efallai y byddant yn porthi'r ZFS ffasiynol yn rhywle arall lle nad yw'n bodoli eto. Ond fel pob FS i fyny'r afon, mae'n debyg i goeden Blwyddyn Newydd: os gallwch chi hongian rhai pethau bach eraill ar ei phen, yna ni allwch fynd yn ddyfnach. Rwy'n cyfaddef ei bod yn bosibl adeiladu system fenter ddifrifol yn seiliedig ar ZFS, ond gan ein bod yn awr yn trafod y dyfodol, ni allaf ond nodi'n drist bod ZFS yn anobeithiol yn hyn o beth: gyda'u dyfeisiau rhithwir, mae'r dynion wedi torri'r ocsigen i ffwrdd. drostynt eu hunain a chenedlaethau'r dyfodol ar gyfer datblygiad pellach. Mae ZFS yn rhywbeth o'r gorffennol. Ac nid yw ext4 a XFS hyd yn oed y diwrnod cyn ddoe.
Mae'n werth sôn ar wahân am y cysyniad syfrdanol o "system ffeiliau Linux y genhedlaeth nesaf". Mae hwn yn brosiect cwbl wleidyddol a marchnata a grëwyd ar gyfer y cyfle, fel petai, i “binio dyfodol systemau ffeiliau” yn Linux y tu ôl i gymeriadau penodol. Y ffaith yw bod Linux yn arfer bod “dim ond am hwyl”. Ond nawr peiriant gwneud arian ydyw yn bennaf. Maent yn cael eu gwneud ar bopeth posibl. Er enghraifft, mae'n anodd iawn creu cynnyrch meddalwedd da, ond mae "datblygwyr" craff wedi sylweddoli ers amser maith nad oes angen straen o gwbl: gallwch werthu'n llwyddiannus feddalwedd nad yw'n bodoli a gyhoeddwyd ac a hyrwyddwyd ym mhob math o gyhoeddusrwydd. digwyddiadau - y prif beth yw y dylai sleidiau'r cyflwyniad gynnwys mwy o “nodweddion”.
Mae systemau ffeil yn berffaith ar gyfer hyn, oherwydd gallwch chi fargeinio'n ddiogel am ddeng mlynedd ar y canlyniad. Wel, os bydd rhywun yn ddiweddarach yn cwyno am ddiffyg yr union ganlyniad hwn, yna nid yw'n deall dim am systemau ffeiliau! Mae hyn yn ein hatgoffa o byramid ariannol: ar y brig mae’r anturiaethwyr a gychwynnodd y llanast hwn, a’r ychydig hynny a oedd yn “lwcus”: “tynnwyd difidendau,” h.y. derbyn arian ar gyfer datblygu, cael swydd â chyflog da fel rheolwyr, “wedi dangos” mewn cynadleddau, ac ati.
Nesaf daw’r rhai sy’n “anlwcus”: byddant yn cyfrif colledion, yn delio â chanlyniadau defnyddio cynnyrch meddalwedd na ellir ei ddefnyddio i gynhyrchu, “ac ati. Mae yna lawer mwy ohonyn nhw. Wel, ar waelod y pyramid mae màs enfawr o ddatblygwyr yn “llifio” cod diwerth. Hwy yw'r collwyr mwyaf, oherwydd ni ellir dychwelyd amser gwastraffus. Mae pyramidau o'r fath yn hynod fuddiol i Torvalds a'i gymdeithion. A pho fwyaf o'r pyramidau hyn, y gorau iddynt. Er mwyn bwydo pyramidau o'r fath, gellir cymryd unrhyw beth i'r craidd. Wrth gwrs, yn gyhoeddus maent yn dweud y gwrthwyneb. Ond nid trwy eiriau yr wyf yn barnu, ond trwy weithredoedd.
Felly, mae “dyfodol systemau ffeiliau yn Linux” yn feddalwedd arall sydd wedi'i hyrwyddo'n fawr, ond prin y gellir ei defnyddio. Ar ôl Btrfs, gyda thebygolrwydd uchel, bydd lle “dyfodol” o'r fath yn cael ei gymryd gan Bcachefs, sef ymgais arall i groesi haen bloc Linux gyda system ffeiliau (mae enghraifft wael yn heintus). A beth sy'n nodweddiadol: mae'r un problemau ag yn Btrfs. Roeddwn yn amau hyn am amser hir, ac yna rhywsut ni allwn wrthsefyll ac edrych i mewn i'r cod - mae'n wir!
Defnyddiodd awduron Bcachefs a Btrfs, wrth greu eu FS, ffynonellau pobl eraill yn weithredol, gan ddeall ychydig amdanynt. Mae'r sefyllfa'n atgoffa rhywun o'r gêm i blant “ffôn wedi torri.” A gallaf ddychmygu'n fras sut y bydd y cod hwn yn cael ei gynnwys yn y cnewyllyn. A dweud y gwir, ni fydd unrhyw un yn gweld y “cribiniau” (bydd pawb yn camu arnynt yn nes ymlaen). Ar ôl nifer o gwerylon am arddull y cod, cyhuddiadau o droseddau nad ydynt yn bodoli, ac ati, deuir i gasgliad ynghylch “teyrngarwch” yr awdur, pa mor dda y mae'n “rhyngweithio” â datblygwyr eraill, a pha mor llwyddiannus y gall hyn i gyd. yna cael ei werthu i gorfforaethau.
Ni fydd y canlyniad terfynol o ddiddordeb i unrhyw un. Ugain mlynedd yn ôl, efallai, byddai gennyf ddiddordeb, ond yn awr mae’r cwestiynau’n cael eu gofyn yn wahanol: a fydd yn bosibl hyrwyddo hyn fel bod pobl benodol yn cael eu cyflogi o fewn y deng mlynedd nesaf. Ac, gwaetha'r modd, nid yw'n arferol pendroni am y canlyniad terfynol.
Yn gyffredinol, byddwn yn eich cynghori'n gryf i beidio â dechrau ailddyfeisio'ch system ffeiliau o'r dechrau. Oherwydd ni fydd hyd yn oed buddsoddiadau ariannol sylweddol yn ddigon i gael rhywbeth cystadleuol mewn deng mlynedd. Wrth gwrs, rwy'n siarad am brosiectau difrifol, ac nid am y rhai y bwriedir eu “gwthio” i'r cnewyllyn. Felly, ffordd fwy effeithiol o fynegi eich hun yw ymuno â datblygiadau go iawn, fel ni. Nid yw hyn, wrth gwrs, yn hawdd i'w wneud - ond mae hyn yn wir am unrhyw brosiect lefel uchel.
Yn gyntaf, bydd angen i chi oresgyn y broblem y byddaf yn ei chynnig yn annibynnol. Ar ôl hynny, yn argyhoeddedig o ddifrifoldeb eich bwriadau, byddaf yn dechrau helpu. Yn draddodiadol, dim ond ein datblygiadau ein hunain yr ydym yn eu defnyddio. Yr eithriadau yw algorithmau cywasgu a rhai swyddogaethau hash. Nid ydym yn anfon datblygwyr i deithio i gynadleddau, ac yna nid ydym yn eistedd ac yn cyfuno syniadau pobl eraill (“efallai beth fydd yn digwydd”), fel sy'n arferol yn y mwyafrif o fusnesau newydd.
Rydym yn datblygu pob algorithm ein hunain. Mae gennyf ddiddordeb ar hyn o bryd yn yr agweddau algebraidd a chyfunol ar wyddor storio data. Yn benodol, meysydd cyfyngedig, asymptotigau, prawf o anghydraddoldebau. Mae yna waith i raglenwyr cyffredin hefyd, ond rhaid i mi eich rhybuddio ar unwaith: anwybyddir pob awgrym i “edrych ar FS arall a gwneud yr un peth”. Bydd clytiau sydd wedi'u hanelu at integreiddio agosach â Linux trwy VFS hefyd yn mynd yno.
Felly, nid oes gennym gribin, ond mae gennym ddealltwriaeth o ble y mae angen inni symud, ac rydym yn hyderus mai’r cyfeiriad hwn yw’r un cywir. Ni ddaeth y deall hwn ar ffurf manna o'r nef. Gadewch imi eich atgoffa bod gennym 29 mlynedd o brofiad datblygu y tu ôl i ni, dwy system ffeil wedi'u hysgrifennu o'r dechrau. A'r un nifer o gyfleustodau adfer data. Ac mae hyn yn llawer!
Ffynhonnell: opennet.ru