રીઝર 4 એફએસના ડેવલપર એડ્યુઅર્ડ શિશ્કિન સાથે બીજી મુલાકાત

રીઝર 4 ફાઇલ સિસ્ટમના ડેવલપર એડ્યુઅર્ડ શિશ્કિન સાથેનો બીજો ઇન્ટરવ્યુ પ્રકાશિત કરવામાં આવ્યો છે.

શરૂ કરવા માટે, કૃપા કરીને વાચકોને યાદ કરાવો કે તમે ક્યાં અને કોના માટે કામ કરો છો.

હું Huawei Technologies, German Research Center ખાતે પ્રિન્સિપાલ સ્ટોરેજ આર્કિટેક્ટ તરીકે કામ કરું છું. વર્ચ્યુઅલાઈઝેશન વિભાગમાં હું ડેટા સ્ટોરેજના વિવિધ પાસાઓ સાથે વ્યવહાર કરું છું. મારી પ્રવૃત્તિઓ ચોક્કસ ઓપરેટિંગ સિસ્ટમ સાથે સંબંધિત નથી.

શું તમે હાલમાં મુખ્ય કર્નલ શાખા માટે પ્રતિબદ્ધ છો?

ખૂબ જ ભાગ્યે જ, અને મારા એમ્પ્લોયરને તેની જરૂર હોય તો જ. છેલ્લી વાર લગભગ ત્રણ વર્ષ પહેલાં હતી, મેં 9p પ્રોટોકોલ (આ વ્યવસાયનું બીજું નામ VirtFS છે) નો ઉપયોગ કરીને હોસ્ટ્સ પર શેર કરેલ સ્ટોરેજ માટે થ્રુપુટ વધારવા માટે પેચ મોકલ્યા હતા. અહીં એક મહત્વની નોંધ લેવી જોઈએ: જો કે હું લિનક્સ સાથે લાંબા સમયથી કામ કરી રહ્યો છું, હું ક્યારેય તેનો ચાહક રહ્યો નથી, એટલે કે, હું "સમાન રીતે શ્વાસ લઉં છું," બાકીની બધી બાબતોની જેમ. ખાસ કરીને, જો મને કોઈ ખામી દેખાય છે, તો હું તેને વધુમાં વધુ એકવાર દર્શાવી શકું છું. અને તેથી તમે પછી કોઈને અનુસરી શકો અને તેમને સમજાવી શકો - આ બનશે નહીં.

મને યાદ છે છેલ્લી વખત, દસ વર્ષ પહેલાં, તમે કર્નલ ડેવલપમેન્ટ શૈલીની ખૂબ ટીકા કરી હતી. તમારા (અથવા કદાચ કોર્પોરેટ) દૃષ્ટિકોણથી, શું કંઈ બદલાયું છે, શું સમુદાય વધુ પ્રતિભાવશીલ બન્યો છે કે નહીં? જો નહીં, તો તમે કોને દોષ આપો છો?

મેં ક્યારેય સારા માટે કોઈ ફેરફાર જોયા નથી. સમુદાયની મુખ્ય સમસ્યા એ છે કે વિજ્ઞાનને રાજકીય તકનીકો, વ્યક્તિગત સંબંધો, બહુમતી અભિપ્રાય, લોકવાદ, "આંતરિક અવાજો" ની સલાહ, સડેલા સમાધાન, વિજ્ઞાન સિવાય બીજું કંઈપણ સાથે બદલવું. કોમ્પ્યુટર વિજ્ઞાન, ગમે તે કહે, પ્રથમ અને અગ્રણી ચોક્કસ વિજ્ઞાન છે. અને જો કોઈ વ્યક્તિ “Linux way” ફ્લેગ હેઠળ અથવા કોઈ અન્ય ફ્લેગ હેઠળ 2 થી અલગ 2x4 માટે પોતાનું મૂલ્ય જાહેર કરવાનું શરૂ કરે છે, તો તે નુકસાન સિવાય બીજું કંઈપણ લાવવાની શક્યતા નથી.

તમામ મુશ્કેલીઓ મુખ્યત્વે નિર્ણય લેનારાઓની અસમર્થતા અને શિક્ષણના અભાવને કારણે છે. જો મેનેજર અસમર્થ હોય, તો તે ઉદ્દેશ્ય, પર્યાપ્ત નિર્ણય લેવામાં સક્ષમ નથી. જો તે અસંસ્કૃત પણ હોય, તો તે કોઈ સક્ષમ નિષ્ણાત શોધી શકતો નથી જે તેને યોગ્ય સલાહ આપે. ઉચ્ચ સંભાવના સાથે, પસંદગી એક સ્કેમર પર પડશે જે કહે છે કે "વસ્તુઓ સાચી લાગે છે." એક ભ્રષ્ટ વાતાવરણ હંમેશા અસમર્થ એકલા નેતાઓની આસપાસ વિકસે છે. તદુપરાંત, ઇતિહાસ આ સંદર્ભમાં કોઈ અપવાદ નથી જાણતો, અને સમુદાય આની સ્પષ્ટ પુષ્ટિ છે.

તમે Btrfs વિકાસમાં પ્રગતિનું મૂલ્યાંકન કેવી રીતે કરશો? શું આ એફએસને બાળપણના રોગોથી છુટકારો મળ્યો? તમે તેને તમારા માટે કેવી રીતે સ્થાન આપો છો - "ઘર માટે" અથવા કોર્પોરેટ ઉપયોગ માટે પણ FS તરીકે?

મને તેમાંથી છૂટકારો મળ્યો નથી. 11 વર્ષ પહેલાં મેં જે ઉલ્લેખ કર્યો હતો તે બધું આજે પણ સુસંગત છે. Btrfs સાથેની એક સમસ્યા જે તેને ગંભીર જરૂરિયાતો માટે અયોગ્ય બનાવે છે તે ખાલી જગ્યાની સમસ્યા છે. હું એ હકીકત વિશે પણ વાત કરી રહ્યો નથી કે વપરાશકર્તાને એવી પરિસ્થિતિઓમાં નવી ડિસ્ક માટે સ્ટોર પર ચલાવવા માટે કહેવામાં આવે છે જ્યાં કોઈપણ અન્ય FS પાર્ટીશન પર ઘણી ખાલી જગ્યા બતાવશે. ખાલી જગ્યાના અભાવને કારણે લોજિકલ વોલ્યુમ પર ઓપરેશન પૂર્ણ કરવામાં અસમર્થતા એ પણ સૌથી ખરાબ વસ્તુ નથી. સૌથી ખરાબ બાબત એ છે કે એક બિનપ્રાપ્તિહીત વપરાશકર્તા લગભગ હંમેશા, કોઈપણ ડિસ્ક ક્વોટાને બાયપાસ કરી શકે છે, એકદમ ટૂંકા સમયમાં દરેકને ખાલી જગ્યાથી વંચિત કરી શકે છે.

તે આના જેવું લાગે છે (લિનક્સ કર્નલ 5.12 માટે પરીક્ષણ કરાયેલ). એક સ્ક્રિપ્ટ તાજી ઇન્સ્ટોલ કરેલી સિસ્ટમ પર લોંચ કરવામાં આવે છે, જે લૂપમાં હોમ ડિરેક્ટરીમાં અમુક નામોવાળી ફાઈલો બનાવે છે, અમુક ઓફસેટ્સ પર તેમને ડેટા લખે છે અને પછી આ ફાઈલો કાઢી નાખે છે. આ સ્ક્રિપ્ટ ચલાવવાના એક મિનિટ પછી, કંઈપણ અસામાન્ય થતું નથી. પાંચ મિનિટ પછી, પાર્ટીશન પર કબજે કરેલી જગ્યાનો ભાગ થોડો વધે છે. બે થી ત્રણ કલાક પછી તે 50% સુધી પહોંચે છે (15% ના પ્રારંભિક મૂલ્ય સાથે). અને પાંચ કે છ કલાક કામ કર્યા પછી, સ્ક્રિપ્ટ ભૂલ સાથે ક્રેશ થાય છે "પાર્ટીશન પર કોઈ ખાલી જગ્યા નથી." આ પછી, તમે તમારા પાર્ટીશનમાં 4K ફાઇલ પણ લખી શકશો નહીં.

એક રસપ્રદ પરિસ્થિતિ ઉદ્ભવે છે: તમે પાર્ટીશન પર કંઈપણ લખ્યા નથી, અને બધી ખાલી જગ્યા (લગભગ 85%) ક્યાંક અદૃશ્ય થઈ ગઈ છે. આવા હુમલાને આધિન વિભાગના વિશ્લેષણથી માત્ર એક વસ્તુ (કીથી સજ્જ ઑબ્જેક્ટ), કદમાં ઘણા બાઇટ્સ ધરાવતા ઘણા વૃક્ષ ગાંઠો જાહેર થશે. એટલે કે, જે સામગ્રી અગાઉ ડિસ્ક સ્પેસના 15% પર કબજો કરે છે તે સમગ્ર પાર્ટીશન પર સમાનરૂપે "સ્મીયર" હોવાનું બહાર આવ્યું છે જેથી નવી ફાઇલ લખવા માટે ક્યાંય ન હોય, કારણ કે તેની કી બધી હાલની ફાઇલો કરતા મોટી છે, અને મફત પાર્ટીશન પરના બ્લોક્સ સમાપ્ત થઈ ગયા છે.

વધુમાં, આ બધું પહેલાથી જ મૂળભૂત Btrfs રૂપરેખાંકન પર થાય છે (કોઈપણ સ્નેપશોટ, સબવોલ્યુમ્સ, વગેરે વગર), અને તમે તે FS માં ફાઇલ બોડીને કેવી રીતે સંગ્રહિત કરવાનું નક્કી કરો છો તેનાથી કોઈ ફરક પડતો નથી (વૃક્ષમાં "ટુકડા" તરીકે, અથવા વિસ્તરણ તરીકે. અનફોર્મેટેડ બ્લોક્સનું) - અંતિમ પરિણામ સમાન હશે.

તમે અન્ય અપસ્ટ્રીમ ફાઇલ સિસ્ટમોને આવા હુમલાને આધીન કરી શકશો નહીં (ભલે તેઓ તમને શું કહેશે). મેં લાંબા સમય પહેલા સમસ્યાનું કારણ સમજાવ્યું હતું: આ Btrfs માં બી-ટ્રી ખ્યાલની સંપૂર્ણ વિકૃતિ છે, જે તેને સ્વયંભૂ અથવા ઇરાદાપૂર્વક અધોગતિ કરવાનું શક્ય બનાવે છે. ખાસ કરીને, અમુક લોડ હેઠળ, તમારી ફાઇલ સિસ્ટમ બહારની મદદ વિના, તેના પોતાના પર ઓપરેશન દરમિયાન સતત "અલગ પડી જશે". તે સ્પષ્ટ છે કે તમામ પ્રકારની "પ્રેસિંગ" પૃષ્ઠભૂમિ પ્રક્રિયાઓ ફક્ત વ્યક્તિગત ડેસ્કટોપ પર જ દિવસ બચાવશે.

સામૂહિક સર્વર્સ પર, હુમલાખોર હંમેશા તેમની "આગળ" કરવામાં સક્ષમ હશે. સિસ્ટમ એડમિનિસ્ટ્રેટર તે નક્કી કરી શકશે નહીં કે કોણે તેને બરાબર ગુંડાગીરી કરી છે. Btrfs માં આ સમસ્યાને ઠીક કરવાની સૌથી ઝડપી રીત એ છે કે નિયમિત બી-ટ્રીનું માળખું પુનઃસ્થાપિત કરવું, એટલે કે. ડિસ્ક ફોર્મેટને ફરીથી ડિઝાઇન કરી રહ્યું છે અને Btrfs કોડના નોંધપાત્ર ભાગોને ફરીથી લખી રહ્યા છે. આમાં ડીબગીંગ સહિત 8-10 વર્ષનો સમય લાગશે, જો કે ડેવલપર્સ સંબંધિત અલ્ગોરિધમ્સ અને ડેટા સ્ટ્રક્ચર્સ પરના મૂળ લેખોનું ચુસ્તપણે પાલન કરે અને "લીનક્સ"માં પ્રચલિત (અને પ્રોત્સાહિત) તરીકે "તૂટેલા ફોન" ગેમ રમ્યા ન હોય. માર્ગ".

અહીં આપણે વિકાસકર્તાઓને આ બધું સમજવા માટે જરૂરી સમય ઉમેરવાની જરૂર છે. આ તે છે જ્યાં તે વધુ મુશ્કેલ બને છે. કોઈ પણ સંજોગોમાં, તેમને સમજવા માટે 10 વર્ષ પૂરતા ન હતા. સારું, ત્યાં સુધી તમે ચમત્કારની આશા રાખી શકતા નથી. તે માઉન્ટ કરવાનું વિકલ્પ "જેના વિશે તમે અને મને ખબર ન હતી" અથવા પેચના સ્વરૂપમાં થશે નહીં કે જે તૈયાર કરવા માટે "માત્ર વ્યવસાયની બાબત છે". આવા દરેક ઉતાવળા "ફિક્સ" માટે હું અધોગતિનું નવું દૃશ્ય રજૂ કરીશ. બી-ટ્રીઝ એ મારા મનપસંદ વિષયોમાંનો એક છે, અને મારે કહેવું જ જોઇએ કે આ રચનાઓ પોતાની સાથે સ્વતંત્રતા સહન કરતી નથી!

હું મારા માટે Btrf ને કેવી રીતે સ્થાન આપી શકું? એવી વસ્તુ તરીકે કે જેને સંપૂર્ણપણે ફાઇલ સિસ્ટમ કહી શકાતી નથી, તેનો ઉપયોગ કરવા દો. કારણ કે, વ્યાખ્યા મુજબ, FS એ "ડિસ્ક સ્પેસ" સંસાધનના અસરકારક સંચાલન માટે જવાબદાર OS સબસિસ્ટમ છે, જે આપણે Btrfs ના કિસ્સામાં જોતા નથી. સારું, કલ્પના કરો કે તમે સ્ટોર પર ઘડિયાળ ખરીદવા આવ્યા છો જેથી કામમાં મોડું ન થાય, અને ઘડિયાળને બદલે તેઓએ તમને વધુમાં વધુ 30 મિનિટ માટે ટાઈમર સાથેની ઇલેક્ટ્રિક ગ્રીલ વેચી. તેથી, Btrfs ની સ્થિતિ વધુ ખરાબ છે.

મેઇલિંગ લિસ્ટ્સ જોતાં, મને વારંવાર એવું નિવેદન આવે છે કે ડ્રાઇવ્સની સસ્તીતાને કારણે ડિસ્ક સ્પેસનું અસરકારક રીતે સંચાલન કરવું હવે સંબંધિત નથી. આ સંપૂર્ણ બકવાસ છે. અસરકારક ડિસ્ક સ્પેસ મેનેજર વિના, OS સંવેદનશીલ અને બિનઉપયોગી બની જશે. તમારા મશીન પરની ડિસ્કની ક્ષમતાને ધ્યાનમાં લીધા વગર.

હું RHEL માં Btrfs સપોર્ટ બંધ કરવા પર ટિપ્પણી કરવા માંગુ છું.

અહીં ટિપ્પણી કરવા માટે કંઈ ખાસ નથી, બધું ખૂબ સ્પષ્ટ છે. તેમની પાસે તે "ટેક્નોલોજી પૂર્વાવલોકન" તરીકે પણ હતું. તેથી, હું આ ખૂબ જ "પૂર્વાવલોકન"માંથી પસાર થયો નથી. આ લેબલને કાયમ માટે અટકી ન દો! પરંતુ તેઓ સંપૂર્ણ સમર્થન સાથે ખામીયુક્ત બાય-ડિઝાઈન પ્રોડક્ટ લોન્ચ કરી શકતા નથી. RHEL એ એક એન્ટરપ્રાઇઝ છે, એટલે કે નિર્ધારિત કોમોડિટી-મની સંબંધો. Red Hat વપરાશકર્તાઓને ધમકાવી શકતા નથી જેમ કે તેઓ Btrfs મેઈલીંગ યાદીમાં કરે છે. ફક્ત પરિસ્થિતિની કલ્પના કરો: એક ક્લાયન્ટ કે જેણે ડિસ્ક માટે અને તમને સપોર્ટ માટે તેની મહેનતના પૈસા ચૂકવ્યા છે, તે સમજવા માંગે છે કે તેણે કંઈપણ ન લખ્યા પછી તેની ડિસ્ક સ્પેસ ક્યાં ગઈ. તમે તેને આનો શું જવાબ આપશો?

આગળ. Red Hat ના ગ્રાહકોમાં જાણીતી મોટી બેંકો અને એક્સચેન્જોનો સમાવેશ થાય છે. કલ્પના કરો કે જો તેઓ Btrfs માં ઉલ્લેખિત નબળાઈના આધારે DoS હુમલાઓને આધિન હોય તો શું થશે. તમને લાગે છે કે આ માટે કોણ જવાબદાર છે? જેઓ જીપીએલ લાયસન્સની લાઇન પર આંગળી ચીંધવાના છે, જ્યાં લખેલું છે કે લેખક કંઈપણ માટે જવાબદાર નથી, હું તરત જ કહીશ: "તેને છુપાવો!" Red Hat જવાબ આપશે, અને એવી રીતે કે તે પર્યાપ્ત લાગશે નહીં! પરંતુ હું જાણું છું કે Red Hat આ પ્રકારની સમસ્યાનો સામનો કરી રહ્યું નથી, QA એન્જિનિયરોની તેમની ખાસ કરીને મજબૂત ટીમને જોતાં, જેમની સાથે મને મારા સમયમાં નજીકથી કામ કરવાની તક મળી.

શા માટે કેટલીક કંપનીઓ તેમના એન્ટરપ્રાઇઝ ઉત્પાદનોમાં Btrf ને સમર્થન આપવાનું ચાલુ રાખે છે?

મહેરબાની કરીને નોંધ કરો કે ઉત્પાદનના નામમાં ઉપસર્ગ "એન્ટરપ્રાઇઝ" નો બહુ અર્થ નથી. એન્ટરપ્રાઇઝ એ ​​ક્લાયન્ટ સાથેના કરાર સંબંધમાં જડિત જવાબદારીનું માપ છે. હું GNU/Linux પર આધારિત માત્ર એક જ એન્ટરપ્રાઇઝ જાણું છું - RHEL. બાકીનું બધું, મારા દૃષ્ટિકોણથી, ફક્ત એક એન્ટરપ્રાઇઝ તરીકે રજૂ કરવામાં આવે છે, પરંતુ એક નથી. અને અંતે, જો કોઈ વસ્તુની માંગ હોય, તો ત્યાં હંમેશા પુરવઠો રહેશે (અમારા કિસ્સામાં, આ ઉલ્લેખિત "સપોર્ટ" છે). સંપૂર્ણપણે દરેક વસ્તુ માટે માંગ છે, સહિત. અને બિનઉપયોગી સોફ્ટવેર. આવી માંગ કેવી રીતે રચાય છે અને તેને કોણ બળ આપે છે તે બીજો વિષય છે.

તેથી, ફેસબુકે તેના સર્વર પર Btrfs જમાવ્યું હોવાની અફવા છે તે પછી હું કોઈ નિષ્કર્ષ પર જઈશ નહીં. તદુપરાંત, હું ઉપરોક્ત કારણોસર તે સર્વરના સરનામાંઓને કાળજીપૂર્વક ગુપ્ત રાખવાની ભલામણ કરીશ.

તાજેતરમાં XFS કોડને સાફ કરવા માટે આટલા પ્રયત્નો શા માટે કરવામાં આવ્યા છે? છેવટે, શરૂઆતમાં આ તૃતીય-પક્ષ ફાઇલ સિસ્ટમ છે, અને ext4 લાંબા સમયથી સ્થિર છે અને અગાઉના સમાન સ્થિર સંસ્કરણોથી સાતત્ય ધરાવે છે. XFS માં Red Hat ને શું રસ છે? શું હેતુમાં સમાન હોય તેવા બે ફાઇલ સિસ્ટમોને સક્રિય રીતે વિકસાવવાનો અર્થ છે - ext4 અને XFS?

મને યાદ નથી કે આ શું પ્રેરિત છે. તે તદ્દન શક્ય છે કે પહેલ Red Hat ક્લાઈન્ટો તરફથી આવી હોય. મને યાદ છે કે આ પ્રકારનું સંશોધન હાથ ધરવામાં આવ્યું હતું: અપસ્ટ્રીમમાંથી કેટલીક ફાઇલ સિસ્ટમ્સ પર, નવી પેઢીની હાઇ-એન્ડ ડ્રાઇવ્સ પર વિશાળ સંખ્યામાં ઑબ્જેક્ટ્સ બનાવવામાં આવ્યા હતા. પરિણામો અનુસાર, XFS એ ext4 કરતાં વધુ સારી રીતે વર્તે છે. તેથી તેઓએ તેને સૌથી આશાસ્પદ તરીકે પ્રમોટ કરવાનું શરૂ કર્યું. કોઈ પણ સંજોગોમાં, હું અહીં સનસનાટીભર્યા કંઈપણ શોધીશ નહીં.

મારા માટે, એવું લાગે છે કે તેઓએ સાબુ સાથે ઘોડો બદલ્યો છે. ext4 અને XFS વિકસાવવાનો કોઈ અર્થ નથી. બંને સમાંતર અને તેમાંથી કોઈપણ પસંદ કરવા માટે. આમાંથી કંઈ સારું નહીં આવે. તેમ છતાં, પ્રકૃતિમાં ઘણી વાર એવી પરિસ્થિતિઓ હોય છે જ્યારે વૃદ્ધિની ઘણી સંભાવના હોય છે, પરંતુ વિકાસ માટે કોઈ જગ્યા હોતી નથી. આ કિસ્સામાં, વિવિધ વિચિત્ર રીતે કદરૂપું નવી વૃદ્ધિ ઊભી થાય છે, જેના તરફ દરેક વ્યક્તિ આંગળી ચીંધે છે ("ઓહ, જુઓ, તમે આ જીવનમાં શું જોશો નહીં!").

શું તમને લાગે છે કે ext4, F2FS (Btrfs માં RAID નો ઉલ્લેખ ન કરવો) માં એન્ક્રિપ્શન ફંક્શનના આગમન સાથે સ્તર ઉલ્લંઘનનો મુદ્દો ઉકેલાઈ ગયો છે (નકારાત્મક અર્થમાં)?

સામાન્ય રીતે, કોઈપણ સ્તરનો પરિચય અને તેમના અ-ભંગ અંગે નિર્ણય લેવો એ સામાન્ય રીતે નીતિની બાબત છે, અને હું અહીં કંઈપણ પર ટિપ્પણી કરવાનું બાંયધરી આપતો નથી. સ્તરના ઉલ્લંઘનના ઉદ્દેશ્ય પાસાઓમાં કોઈને રસ નથી, પરંતુ અમે "ઉપરથી" ઉલ્લંઘનના ઉદાહરણનો ઉપયોગ કરીને તેમાંથી કેટલાકને ધ્યાનમાં લઈ શકીએ છીએ, એટલે કે, બ્લોક લેયર પર પહેલેથી જ અસ્તિત્વમાં છે તે કાર્યક્ષમતાના FS માં અમલીકરણ. આવા "ઉલ્લંઘન" માત્ર દુર્લભ અપવાદો સાથે ન્યાયી છે. આવા દરેક કેસ માટે, તમારે પહેલા બે બાબતો સાબિત કરવી પડશે: તે ખરેખર જરૂરી છે, અને તે કે આમ કરવાથી સિસ્ટમની ડિઝાઇનને નુકસાન થશે નહીં.

ઉદાહરણ તરીકે, મિરરિંગ, જે પરંપરાગત રીતે બ્લોક લેયર માટેની પ્રવૃત્તિ છે, તે ફાઈલ સિસ્ટમ સ્તરે અમલમાં મૂકવા માટે અર્થપૂર્ણ છે. જુદા જુદા કારણોસર. ઉદાહરણ તરીકે, ડિસ્ક ડ્રાઇવ્સ પર "શાંત" ડેટા કરપ્શન (બીટ રોટ) થાય છે. આ ત્યારે થાય છે જ્યારે ઉપકરણ યોગ્ય રીતે કાર્ય કરી રહ્યું હોય, પરંતુ દૂરના ક્વાસર વગેરે દ્વારા ઉત્સર્જિત હાર્ડ ગામા ક્વોન્ટમના પ્રભાવ હેઠળ બ્લોક ડેટાને અણધારી રીતે નુકસાન થાય છે. સૌથી ખરાબ બાબત એ છે કે જો આ બ્લોક FS સિસ્ટમ બ્લોક (સુપરબ્લોક, બીટમેપ બ્લોક, સ્ટોરેજ ટ્રી નોડ, વગેરે) હોવાનું બહાર આવે છે, કારણ કે આ ચોક્કસપણે કર્નલ ગભરાટ તરફ દોરી જશે.

મહેરબાની કરીને નોંધ કરો કે બ્લોક સ્તર (કહેવાતા RAID 1) દ્વારા ઓફર કરવામાં આવતા અરીસાઓ તમને આ સમસ્યામાંથી બચાવશે નહીં. સારું, ખરેખર: કોઈએ ચેકસમ તપાસવું જોઈએ અને નિષ્ફળતાના કિસ્સામાં પ્રતિકૃતિ વાંચવી જોઈએ? વધુમાં, તે માત્ર દરેક વસ્તુને જ નહીં, પરંતુ માત્ર મેટાડેટાને પ્રતિબિંબિત કરવા માટે અર્થપૂર્ણ છે. કેટલાક મહત્વપૂર્ણ ડેટા (ઉદાહરણ તરીકે, જટિલ એપ્લિકેશનોની એક્ઝિક્યુટેબલ ફાઇલો) મેટાડેટા તરીકે સંગ્રહિત કરી શકાય છે. આ કિસ્સામાં, તેઓ સલામતીની સમાન બાંયધરી મેળવે છે. બાકીના ડેટાની સુરક્ષા અન્ય સબસિસ્ટમ (કદાચ વપરાશકર્તા એપ્લિકેશનો પણ) ને સોંપવામાં તે અર્થપૂર્ણ છે - અમે આ માટે તમામ જરૂરી શરતો પ્રદાન કરી છે.

આવા "આર્થિક" અરીસાઓને અસ્તિત્વમાં રહેવાનો અધિકાર છે, અને તે ફક્ત ફાઇલ સિસ્ટમ સ્તરે અસરકારક રીતે ગોઠવી શકાય છે. નહિંતર, લેયરિંગ ઉલ્લંઘન કેટલાક માઇક્રોસ્કોપિક લાભો ખાતર ડુપ્લિકેટ કોડ સાથે સબસિસ્ટમને ક્લટર કરે છે. FS નો ઉપયોગ કરીને RAID-5 નું અમલીકરણ આનું આકર્ષક ઉદાહરણ છે. આવા સોલ્યુશન્સ (ફાઇલ સિસ્ટમમાં પોતાના RAID/LVM) આર્કિટેક્ચરલ દ્રષ્ટિએ બાદમાંને મારી નાખે છે. અહીં એ પણ નોંધવું જોઈએ કે વિવિધ પ્રકારના માર્કેટિંગ સ્કેમર્સ દ્વારા લેયરિંગ ઉલ્લંઘનને "પ્રવાહમાં મૂકવામાં આવે છે". કોઈપણ વિચારોની ગેરહાજરીમાં, પડોશી સ્તરો પર લાંબા સમયથી અમલમાં મૂકાયેલ કાર્યક્ષમતા સબસિસ્ટમ્સમાં ઉમેરવામાં આવે છે, આ એક નવી અત્યંત ઉપયોગી સુવિધા તરીકે રજૂ કરવામાં આવે છે અને સક્રિયપણે દબાણ કરવામાં આવે છે.

Reiser4 પર "નીચેથી" સ્તરોનું ઉલ્લંઘન કરવાનો આરોપ મૂકવામાં આવ્યો હતો. હકીકત એ છે કે ફાઇલ સિસ્ટમ અન્ય તમામની જેમ મોનોલિથિક નથી, પરંતુ મોડ્યુલર છે, એક અપ્રમાણિત ધારણા બનાવવામાં આવી હતી કે તે ઉપરના સ્તરે (VFS) જે કરવું જોઈએ તે કરે છે.

શું ReiserFS v3.6 અને ઉદાહરણ તરીકે, JFS ના મૃત્યુ વિશે વાત કરવી શક્ય છે? તાજેતરમાં તેઓને કોરમાં લગભગ કોઈ ધ્યાન આપવામાં આવ્યું નથી. શું તેઓ અપ્રચલિત છે?

અહીં આપણે સોફ્ટવેર પ્રોડક્ટના મૃત્યુનો અર્થ શું છે તે વ્યાખ્યાયિત કરવાની જરૂર છે. એક તરફ, તેઓ સફળતાપૂર્વક ઉપયોગમાં લેવાય છે (તે તે છે જેના માટે તેઓ બનાવવામાં આવ્યા હતા, છેવટે), જેનો અર્થ છે કે તેઓ જીવે છે. બીજી બાજુ, હું JFS માટે બોલી શકતો નથી (મને વધુ ખબર નથી), પરંતુ ReiserFS (v3) માટે નવા વલણો (વ્યવહારમાં પરીક્ષણ કરાયેલ) સાથે અનુકૂલન કરવું ખૂબ મુશ્કેલ છે. આનો અર્થ એ છે કે ભવિષ્યમાં વિકાસકર્તાઓ તેના પર નહીં, પરંતુ અનુકૂલન કરવા માટે સરળ છે તેના પર ધ્યાન આપશે. આ બાજુથી તે તારણ આપે છે કે, અરે, તે આર્કિટેક્ચરલ દ્રષ્ટિએ મૃત છે. હું "નૈતિક રીતે અપ્રચલિત" ના ખ્યાલને જરાય ચાલાકી નહીં કરું. તે સારી રીતે લાગુ પડે છે, ઉદાહરણ તરીકે, કપડા પર, પરંતુ સોફ્ટવેર ઉત્પાદનો પર નહીં. કોઈ વસ્તુમાં હીનતા અને શ્રેષ્ઠતાનો ખ્યાલ છે. હું ચોક્કસ કહી શકું છું કે ReserFS v3 હવે દરેક બાબતમાં Reiser4 કરતાં હલકી ગુણવત્તાવાળા છે, પરંતુ અમુક પ્રકારના વર્કલોડમાં તે અન્ય તમામ અપસ્ટ્રીમ FSs કરતાં ચડિયાતું છે.

શું તમે FS Tux3 અને HAMMER/HAMMER2 (FS for DragonFly BSD) ના વિકાસ વિશે જાણો છો?

હા, આપણે જાણીએ છીએ. Tux3 માં મને એક વખત તેમના સ્નેપશોટની ટેક્નોલોજીમાં રસ હતો (કહેવાતા "સંસ્કરણ પોઇન્ટર"), પરંતુ Reiser4 માં અમે મોટે ભાગે અલગ માર્ગ પર જઈશું. હું લાંબા સમયથી સ્નેપશોટને ટેકો આપવા વિશે વિચારી રહ્યો છું અને હજી સુધી નક્કી કર્યું નથી કે તેને સરળ Reiser4 વોલ્યુમો માટે કેવી રીતે અમલમાં મૂકવું. હકીકત એ છે કે ઓહદ રોડેહ દ્વારા પ્રસ્તાવિત નવી "આળસુ" સંદર્ભ કાઉન્ટર ટેકનિક માત્ર બી-ટ્રીઝ માટે જ કામ કરે છે. અમારી પાસે તેઓ નથી. તે ડેટા સ્ટ્રક્ચર્સ માટે કે જેનો ઉપયોગ Reiesr4 માં થાય છે, "આળસુ" કાઉન્ટર્સ વ્યાખ્યાયિત નથી - તેમને રજૂ કરવા માટે, ચોક્કસ અલ્ગોરિધમિક સમસ્યાઓ હલ કરવી જરૂરી છે, જે હજી સુધી કોઈએ લીધી નથી.

હેમર મુજબ: મેં સર્જકનો એક લેખ વાંચ્યો. રસ નથી. ફરીથી, બી-વૃક્ષો. આ ડેટા માળખું નિરાશાજનક રીતે જૂનું છે. છેલ્લી સદીમાં અમે તેને છોડી દીધું.

તમે CephFS/GlusterFS/etc જેવા નેટવર્ક ક્લસ્ટર FS ની વધતી માંગનું મૂલ્યાંકન કેવી રીતે કરશો? શું આ માંગનો અર્થ નેટવર્ક FS તરફ વિકાસકર્તાઓની પ્રાથમિકતાઓમાં ફેરફાર અને સ્થાનિક FS પર અપૂરતું ધ્યાન છે?

હા, પ્રાથમિકતાઓમાં આવો ફેરફાર થયો છે. સ્થાનિક ફાઇલ સિસ્ટમનો વિકાસ અટકી ગયો છે. અરે, સ્થાનિક વોલ્યુમો માટે નોંધપાત્ર કંઈક કરવું હવે ખૂબ મુશ્કેલ છે અને દરેક જણ તે કરી શકતું નથી. કોઈ તેમના વિકાસમાં રોકાણ કરવા માંગતું નથી. આ એક વ્યાપારી સંસ્થાને ગાણિતિક સંશોધન માટે નાણાં ફાળવવા માટે કહેવા જેવું જ છે - કોઈપણ ઉત્સાહ વિના તેઓ તમને પૂછશે કે તમે નવા પ્રમેય પર કેવી રીતે પૈસા કમાઈ શકો છો. હવે સ્થાનિક FS એવી વસ્તુ છે જે જાદુઈ રીતે "બૉક્સની બહાર" દેખાય છે અને "હંમેશા કામ કરવું જોઈએ," અને જો તે કામ કરતું નથી, તો તે બિનસંબોધિત બડબડાટનું કારણ બને છે જેમ કે: "હા, તેઓ શું વિચારે છે!"

આથી સ્થાનિક FS પર ધ્યાનનો અભાવ, જો કે તે વિસ્તારમાં હજુ ઘણું કામ બાકી છે. અને હા, દરેક જણ વિતરિત સ્ટોરેજ તરફ વળ્યા છે, જે પહેલાથી અસ્તિત્વમાં છે તે સ્થાનિક ફાઇલ સિસ્ટમ્સના આધારે બનાવવામાં આવ્યું છે. તે હવે ખૂબ જ ફેશનેબલ છે. "બિગ ડેટા" વાક્ય ઘણા લોકો માટે એડ્રેનાલિન ધસારોનું કારણ બને છે, તેને કોન્ફરન્સ, વર્કશોપ, મોટા પગાર, વગેરે સાથે સાંકળે છે.

સૈદ્ધાંતિક રીતે યુઝર સ્પેસને બદલે કર્નલ સ્પેસમાં નેટવર્ક ફાઈલ સિસ્ટમનો અમલ કરવો કેટલું વાજબી છે?

એક ખૂબ જ વાજબી અભિગમ જે હજુ સુધી ક્યાંય અમલમાં આવ્યો નથી. સામાન્ય રીતે, નેટવર્ક ફાઇલ સિસ્ટમને કઈ જગ્યામાં લાગુ કરવી જોઈએ તે પ્રશ્ન "દ્વિ ધારી તલવાર" છે. સારું, ચાલો એક ઉદાહરણ જોઈએ. ક્લાયંટે રિમોટ મશીન પર ડેટા રેકોર્ડ કર્યો. તેઓ ગંદા પૃષ્ઠોના રૂપમાં તેના પૃષ્ઠ કેશમાં પડ્યાં. કર્નલ સ્પેસમાં "પાતળા ગેટવે" નેટવર્ક ફાઇલ સિસ્ટમ માટે આ કામ છે. પછી ઑપરેટિંગ સિસ્ટમ વહેલા કે પછીથી તમને તે પૃષ્ઠોને મુક્ત કરવા માટે ડિસ્ક પર લખવાનું કહેશે. પછી IO-ફોરવર્ડિંગ (મોકલવા) નેટવર્ક FS મોડ્યુલ અમલમાં આવે છે. તે નક્કી કરે છે કે આ પૃષ્ઠો કયા સર્વર મશીન (સર્વર નોડ) પર જશે.

પછી નેટવર્ક સ્ટેક કબજે કરે છે (અને, જેમ આપણે જાણીએ છીએ, તે કર્નલ સ્પેસમાં લાગુ થાય છે). આગળ, સર્વર નોડ ડેટા અથવા મેટાડેટા સાથે તે પેકેટ મેળવે છે અને આ બધી સામગ્રીને રેકોર્ડ કરવા માટે બેકએન્ડ સ્ટોરેજ મોડ્યુલ (એટલે ​​​​કે, સ્થાનિક FS જે કર્નલ સ્પેસમાં કાર્ય કરે છે) ને સૂચના આપે છે. તેથી, અમે પ્રશ્ન ઘટાડી દીધો છે કે "મોકલવા" અને "પ્રાપ્ત" મોડ્યુલો ક્યાં કામ કરવા જોઈએ. જો તેમાંથી કોઈપણ મોડ્યુલ વપરાશકર્તા જગ્યામાં ચાલે છે, તો આ અનિવાર્યપણે સંદર્ભ સ્વિચિંગ તરફ દોરી જશે (કર્નલ સેવાઓનો ઉપયોગ કરવાની જરૂરિયાતને કારણે). આવા સ્વીચોની સંખ્યા અમલીકરણ વિગતો પર આધારિત છે.

જો આવી ઘણી સ્વીચો હોય, તો સ્ટોરેજ થ્રુપુટ (I/O પ્રદર્શન) ઘટશે. જો તમારું બેકએન્ડ સ્ટોરેજ ધીમી ડિસ્કથી બનેલું હોય, તો તમે નોંધપાત્ર ઘટાડો જોશો નહીં. પરંતુ જો તમારી પાસે ફાસ્ટ ડિસ્ક (SSD, NVRAM, વગેરે) હોય, તો સંદર્ભ સ્વિચિંગ પહેલેથી જ "અડચણ" બની જાય છે અને, સંદર્ભ સ્વિચિંગ પર બચત કરીને, પ્રભાવ નોંધપાત્ર રીતે વધારી શકાય છે. નાણાં બચાવવા માટેની પ્રમાણભૂત રીત એ છે કે મોડ્યુલોને કર્નલ સ્પેસમાં ખસેડો. ઉદાહરણ તરીકે, અમે જોયું કે 9p સર્વરને QEMU થી કર્નલ પર હોસ્ટ મશીન પર ખસેડવાથી VirtFS પ્રદર્શનમાં ત્રણ ગણો વધારો થાય છે.

આ, અલબત્ત, નેટવર્ક FS નથી, પરંતુ તે વસ્તુઓના સારને સંપૂર્ણપણે પ્રતિબિંબિત કરે છે. આ ઓપ્ટિમાઇઝેશનનું નુકસાન એ પોર્ટેબિલિટી સમસ્યાઓ છે. કેટલાક માટે, બાદમાં મહત્વપૂર્ણ હોઈ શકે છે. ઉદાહરણ તરીકે, GlusterFS પાસે કર્નલમાં કોઈ મોડ્યુલ નથી. આનો આભાર, તે હવે NetBSD સહિત ઘણા પ્લેટફોર્મ પર કામ કરે છે.

સ્થાનિક FSs નેટવર્કમાંથી અને તેનાથી વિપરિત કઇ વિભાવનાઓ ઉછીના લઇ શકે છે?

આજકાલ, નેટવર્ક FSs, એક નિયમ તરીકે, સ્થાનિક FSs પર ઍડ-ઑન્સ ધરાવે છે, તેથી હું સમજી શકતો નથી કે તમે પછીથી કઈ રીતે કંઈક ઉધાર લઈ શકો. સારું, ખરેખર, ચાલો 4 કર્મચારીઓની કંપનીને ધ્યાનમાં લઈએ, જેમાં દરેક વ્યક્તિ પોતાનું કામ કરે છે: એક વિતરણ કરે છે, બીજો મોકલે છે, ત્રીજો મેળવે છે, ચોથો સ્ટોર્સ. અને પ્રશ્ન, કંપની તેના કર્મચારી પાસેથી શું ઉધાર લઈ શકે છે જે તેને સંગ્રહિત કરે છે, તે કોઈક રીતે ખોટો લાગે છે (તેની પાસે તે પહેલેથી જ છે જે તે લાંબા સમયથી તેની પાસેથી ઉધાર લઈ શકે છે).

પરંતુ સ્થાનિક FS પાસે નેટવર્કમાંથી શીખવા જેવું ઘણું છે. સૌપ્રથમ, તમારે તેમની પાસેથી શીખવું જોઈએ કે ઉચ્ચ સ્તરે લોજિકલ વોલ્યુમ કેવી રીતે એકત્ર કરવું. હવે કહેવાતા "અદ્યતન" સ્થાનિક ફાઇલ સિસ્ટમો ફક્ત LVM (તે જ ચેપી લેયરિંગ ઉલ્લંઘન કે જે ZFS માં લાગુ કરવામાં આવી હતી) માંથી ઉછીના લીધેલ "વર્ચ્યુઅલ ઉપકરણ" તકનીકનો ઉપયોગ કરીને લોજિકલ વોલ્યુમોને એકીકૃત કરે છે. બીજા શબ્દોમાં કહીએ તો, વર્ચ્યુઅલ એડ્રેસ (બ્લોક નંબર્સ) નું વાસ્તવિક અને પાછળનું ભાષાંતર નીચા સ્તરે થાય છે (એટલે ​​​​કે, ફાઇલ સિસ્ટમે I/O વિનંતી જારી કર્યા પછી).

મહેરબાની કરીને નોંધ કરો કે બ્લોક લેયર પર ગોઠવાયેલા લોજિકલ વોલ્યુમો (મિરર્સ નહીં) માં ઉપકરણોને ઉમેરવા અને દૂર કરવાથી સમસ્યાઓ થાય છે જેના વિશે આવા "સુવિધાઓ" ના સપ્લાયર્સ નમ્રતાપૂર્વક મૌન છે. હું વાસ્તવિક ઉપકરણો પર ફ્રેગમેન્ટેશન વિશે વાત કરું છું, જે ભયંકર મૂલ્યો સુધી પહોંચી શકે છે, જ્યારે વર્ચ્યુઅલ ઉપકરણ પર બધું સારું છે. જો કે, થોડા લોકોને વર્ચ્યુઅલ ઉપકરણોમાં રસ છે: તમારા વાસ્તવિક ઉપકરણો પર શું થઈ રહ્યું છે તેમાં દરેકને રસ છે. પરંતુ ZFS-જેવી FS (તેમજ LVM સાથે જોડાણમાં કોઈપણ FS) માત્ર વર્ચ્યુઅલ ડિસ્ક ઉપકરણો સાથે જ કામ કરે છે (ફ્રીમાંથી વર્ચ્યુઅલ ડિસ્ક સરનામાંઓ ફાળવો, આ વર્ચ્યુઅલ ઉપકરણોને ડિફ્રેગમેન્ટ કરો, વગેરે). અને વાસ્તવિક ઉપકરણો પર શું થઈ રહ્યું છે તેની તેમને કોઈ જાણ નથી!

હવે કલ્પના કરો કે તમારી પાસે વર્ચ્યુઅલ ઉપકરણ પર શૂન્ય ફ્રેગમેન્ટેશન છે (એટલે ​​​​કે, તમારી પાસે ત્યાં માત્ર એક વિશાળ હદ રહે છે), તમે તમારા લોજિકલ વોલ્યુમમાં ડિસ્ક ઉમેરો, અને પછી તમારા લોજિકલ વોલ્યુમમાંથી બીજી રેન્ડમ ડિસ્ક દૂર કરો અને પછી રિબેલેન્સ કરો. અને ઘણી વખત. તે કલ્પના કરવી મુશ્કેલ નથી કે વર્ચ્યુઅલ ઉપકરણ પર તમે હજી પણ તે જ હદ સુધી જીવશો, પરંતુ વાસ્તવિક ઉપકરણો પર તમને કંઈપણ સારું દેખાશે નહીં.

સૌથી ખરાબ વાત એ છે કે તમે આ પરિસ્થિતિને સુધારવા માટે પણ સક્ષમ નથી! તમે અહીં માત્ર એક જ વસ્તુ કરી શકો છો જે ફાઇલ સિસ્ટમને વર્ચ્યુઅલ ઉપકરણને ડિફ્રેગમેન્ટ કરવા માટે કહે છે. પરંતુ તે તમને કહેશે કે ત્યાં બધું સરસ છે - ત્યાં ફક્ત એક જ હદ છે, વિભાજન શૂન્ય છે, અને તે વધુ સારું ન હોઈ શકે! તેથી, બ્લોક લેવલ પર ગોઠવાયેલા લોજિકલ વોલ્યુમો ઉપકરણોને પુનરાવર્તિત ઉમેરવા/દૂર કરવા માટે બનાવાયેલ નથી. સારી રીતે, તમારે માત્ર એક જ વાર બ્લોક સ્તર પર લોજિકલ વોલ્યુમ એસેમ્બલ કરવાની જરૂર છે, તેને ફાઇલ સિસ્ટમને આપો, અને પછી તેની સાથે બીજું કંઈ કરશો નહીં.

વધુમાં, સ્વતંત્ર FS+LVM સબસિસ્ટમનું સંયોજન ડ્રાઇવ્સની વિવિધ પ્રકૃતિને ધ્યાનમાં લેવાની મંજૂરી આપતું નથી કે જેમાંથી લોજિકલ વોલ્યુમો એકત્ર કરવામાં આવે છે. ખરેખર, ધારો કે તમે HDD અને સોલિડ-સ્ટેટ ઉપકરણોમાંથી લોજિકલ વોલ્યુમ એસેમ્બલ કર્યું છે. પરંતુ પછી પહેલાને ડિફ્રેગમેન્ટેશનની જરૂર પડશે, અને બાદમાં નહીં. બાદમાં માટે, તમારે કાઢી નાખવાની વિનંતીઓ જારી કરવાની જરૂર છે, પરંતુ ભૂતપૂર્વ માટે, નહીં, વગેરે. જો કે, આ સંયોજનમાં આવી પસંદગીનું પ્રદર્શન કરવું ખૂબ મુશ્કેલ છે.

નોંધ કરો કે ફાઈલ સિસ્ટમ પર તમારું પોતાનું LVM બનાવ્યા પછી, પરિસ્થિતિ વધુ સારી થતી નથી. તદુપરાંત, આ કરવાથી તમે વાસ્તવમાં ભવિષ્યમાં તેને ક્યારેય સુધારવાની સંભાવનાને સમાપ્ત કરો છો. આ ખૂબ જ ખરાબ છે. એક જ મશીન પર વિવિધ પ્રકારની ડ્રાઈવો જીવી શકે છે. અને જો ફાઇલ સિસ્ટમ તેમની વચ્ચે ભેદ પાડતી નથી, તો પછી કોણ કરશે?

બીજી સમસ્યા કહેવાતાની રાહમાં છે. “લખો-ક્યાંય” ફાઇલ સિસ્ટમ્સ (આમાં Reiser4 પણ શામેલ છે, જો તમે માઉન્ટ દરમિયાન યોગ્ય વ્યવહાર મોડલનો ઉલ્લેખ કર્યો હોય). આવી ફાઇલ સિસ્ટમોએ ડિફ્રેગમેન્ટેશન ટૂલ્સ પ્રદાન કરવા જ જોઈએ જે તેમની શક્તિમાં અભૂતપૂર્વ છે. અને નીચા-સ્તરના વોલ્યુમ મેનેજર અહીં મદદ કરતું નથી, પરંતુ ફક્ત માર્ગમાં આવે છે. હકીકત એ છે કે આવા મેનેજર સાથે, તમારું એફએસ ફક્ત એક ઉપકરણના મફત બ્લોક્સનો નકશો સંગ્રહિત કરશે - એક વર્ચ્યુઅલ. તદનુસાર, તમે ફક્ત વર્ચ્યુઅલ ઉપકરણને ડિફ્રેગમેન્ટ કરી શકો છો. આનો અર્થ એ છે કે તમારું ડિફ્રેગમેન્ટર વર્ચ્યુઅલ એડ્રેસની વિશાળ સિંગલ સ્પેસ પર લાંબા, લાંબા સમય સુધી કામ કરશે.

અને જો તમારી પાસે ઘણા બધા વપરાશકર્તાઓ રેન્ડમ ઓવરરાઈટ કરે છે, તો આવા ડિફ્રેગમેન્ટરની ઉપયોગી અસર શૂન્ય થઈ જશે. તમારી સિસ્ટમ અનિવાર્યપણે ધીમું થવાનું શરૂ કરશે, અને તમારે ફક્ત નિરાશાજનક નિદાન "તૂટેલી ડિઝાઇન" સામે તમારા હાથ ફોલ્ડ કરવા પડશે. સમાન સરનામાંની જગ્યા પર ચાલતા કેટલાક ડિફ્રેગમેન્ટર્સ ફક્ત એકબીજા સાથે દખલ કરશે. જો તમે દરેક વાસ્તવિક ઉપકરણ માટે મફત બ્લોક્સનો તમારો પોતાનો નકશો જાળવી રાખશો તો તે સંપૂર્ણપણે અલગ બાબત છે. આ ડિફ્રેગમેન્ટેશન પ્રક્રિયાને અસરકારક રીતે સમાંતર બનાવશે.

પરંતુ આ ફક્ત ત્યારે જ થઈ શકે છે જો તમારી પાસે ઉચ્ચ-સ્તરના લોજિકલ વોલ્યુમ મેનેજર હોય. આવા મેનેજરો સાથેની સ્થાનિક ફાઇલ સિસ્ટમ્સ અગાઉ અસ્તિત્વમાં ન હતી (ઓછામાં ઓછું, હું તેમના વિશે જાણતો નથી). ફક્ત નેટવર્ક ફાઇલ સિસ્ટમો (ઉદાહરણ તરીકે GlusterFS) પાસે આવા સંચાલકો હતા. બીજું ખૂબ મહત્વનું ઉદાહરણ વોલ્યુમ ઇન્ટિગ્રિટી ચેક (fsck) ઉપયોગિતા છે. જો તમે દરેક સબવોલ્યુમ માટે ફ્રી બ્લોક્સનો તમારો પોતાનો સ્વતંત્ર નકશો સંગ્રહિત કરો છો, તો લોજિકલ વોલ્યુમ તપાસવાની પ્રક્રિયા અસરકારક રીતે સમાંતર થઈ શકે છે. બીજા શબ્દોમાં કહીએ તો, ઉચ્ચ-સ્તરના મેનેજરો સાથે લોજિકલ વોલ્યુમ વધુ સારી રીતે સ્કેલ કરે છે.

વધુમાં, નીચા-સ્તરના વોલ્યુમ મેનેજરો સાથે તમે સંપૂર્ણ સુવિધાયુક્ત સ્નેપશોટ ગોઠવી શકશો નહીં. LVM અને ZFS જેવી ફાઇલ સિસ્ટમો સાથે, તમે માત્ર સ્થાનિક સ્નેપશોટ લઈ શકો છો, પરંતુ વૈશ્વિક સ્નેપશોટ નહીં. સ્થાનિક સ્નેપશોટ તમને ફક્ત નિયમિત ફાઇલ ઑપરેશન્સને તરત જ રોલ બેક કરવાની મંજૂરી આપે છે. અને ત્યાં કોઈ પણ લોજિકલ વોલ્યુમો (ઉપકરણો ઉમેરવા/દૂર કરવા) સાથેની કામગીરીને પાછો ખેંચી શકશે નહીં. ચાલો આને ઉદાહરણ સાથે જોઈએ. અમુક સમયે, જ્યારે તમારી પાસે 100 ફાઇલો ધરાવતા બે ઉપકરણો A અને Bનું લોજિકલ વોલ્યુમ હોય, ત્યારે તમે સિસ્ટમ Sનો સ્નેપશોટ લો અને પછી બીજી સો ફાઇલો બનાવો.

તે પછી, તમે તમારા વોલ્યુમમાં ઉપકરણ C ઉમેરો છો, અને અંતે તમારી સિસ્ટમને સ્નેપશોટ S પર રોલબેક કરો છો. પ્રશ્ન: S પર રોલબેક કર્યા પછી તમારા લોજિકલ વોલ્યુમમાં કેટલી ફાઇલો અને ઉપકરણો હોય છે? તમે ધાર્યું હશે તેમ 100 ફાઇલો હશે, પરંતુ ત્યાં 3 ઉપકરણો હશે - આ એ જ ઉપકરણો A, B અને C છે, જો કે જે સમયે સ્નેપશોટ બનાવવામાં આવ્યો હતો તે સમયે સિસ્ટમમાં ફક્ત બે ઉપકરણો હતા (A અને B ). ઍડ ડિવાઇસ C ઑપરેશન ફરી વળ્યું ન હતું, અને જો તમે હવે કૉમ્પ્યુટરમાંથી ડિવાઇસ Cને હટાવો છો, તો તે તમારા ડેટાને બગાડશે, તેથી ડિલીટ કરતાં પહેલાં તમારે ઉપકરણને રિબેલેન્સ લોજિકલ વોલ્યુમમાંથી દૂર કરવા માટે પહેલાં ખર્ચાળ ઑપરેશન કરવાની જરૂર પડશે, જે ઉપકરણ C થી ઉપકરણ A અને B સુધીના તમામ ડેટાને વેરવિખેર કરશે. પરંતુ જો તમારું FS વૈશ્વિક સ્નેપશોટને સમર્થન આપે છે, તો આવા પુનઃસંતુલનની જરૂર રહેશે નહીં, અને S પર ત્વરિત રોલબેક પછી, તમે કમ્પ્યુટરમાંથી ઉપકરણ C ને સુરક્ષિત રીતે દૂર કરી શકો છો.

તેથી, વૈશ્વિક સ્નેપશોટ સારા છે કારણ કે તે તમને લોજિકલ વોલ્યુમ (લોજિકલ વોલ્યુમમાં) માંથી મોટી માત્રામાં ડેટા (અલબત્ત, જો તમને તમારી સિસ્ટમ "સ્નેપશોટ" કરવાનું યાદ હોય તો) સાથે ઉપકરણને મોંઘા દૂર કરવા (ઉમેરવાનું) ટાળવા દે છે. યોગ્ય સમયે). ચાલો હું તમને યાદ અપાવી દઉં કે સ્નેપશોટ બનાવવા અને ફાઈલ સિસ્ટમને તેના પર પાછું ફેરવવું એ તાત્કાલિક કામગીરી છે. પ્રશ્ન ઉદ્દભવી શકે છે: તમને ત્રણ દિવસ લાગ્યા હોય તેવા લોજિકલ વોલ્યુમ પર ઑપરેશનને તરત જ પાછું ફેરવવાનું કેવી રીતે શક્ય છે? પરંતુ તે શક્ય છે! પૂરી પાડવામાં આવેલ છે કે તમારી ફાઇલ સિસ્ટમ યોગ્ય રીતે ડિઝાઇન કરવામાં આવી છે. મને આવા “3D સ્નેપશોટ”નો વિચાર ત્રણ વર્ષ પહેલાં આવ્યો હતો અને ગયા વર્ષે મેં આ ટેકનિકને પેટન્ટ કરાવી હતી.

સ્થાનિક FS એ નેટવર્કમાંથી શીખવું જોઈએ તે પછીની વસ્તુ એ છે કે નેટવર્ક FSs તેમને અલગ મશીનો (કહેવાતા મેટાડેટા સર્વર્સ) પર સ્ટોર કરે છે તે રીતે અલગ ઉપકરણો પર મેટાડેટા સંગ્રહિત કરવા. એવી એપ્લિકેશનો છે જે મુખ્યત્વે મેટાડેટા સાથે કામ કરે છે, અને આ એપ્લિકેશનોને મોંઘા ઉચ્ચ-પ્રદર્શન સ્ટોરેજ ઉપકરણો પર મેટાડેટા મૂકીને મોટા પ્રમાણમાં ઝડપી બનાવી શકાય છે. FS+LVM સંયોજન સાથે, તમે આવી પસંદગીને દર્શાવવા માટે સમર્થ હશો નહીં: LVM એ જાણતું નથી કે તમે તેને પસાર કરેલ બ્લોક પર શું છે (ત્યાંનો ડેટા અથવા મેટાડેટા).

FS+LVM સંયોજનની તુલનામાં FS માં તમારા પોતાના નિમ્ન-સ્તરના LVM ને અમલમાં મૂકવાથી તમને વધુ ફાયદો થશે નહીં, પરંતુ તમે જે ખૂબ સારી રીતે કરી શકો છો તે FS ને ક્લટર કરે છે જેથી પછીથી તેના કોડ સાથે કામ કરવું અશક્ય બની જાય. ZFS અને Btrfs, જે વર્ચ્યુઅલ ઉપકરણો સાથે દોડી આવ્યા છે, તે બધા સ્પષ્ટ ઉદાહરણો છે કે કેવી રીતે લેયરિંગ ઉલ્લંઘન આર્કિટેક્ચરલ દ્રષ્ટિએ સિસ્ટમને મારી નાખે છે. તો, હું આ બધું શા માટે છું? વધુમાં, ફાઈલ સિસ્ટમમાં તમારા પોતાના લો-લેવલ LVM ને સ્થાપિત કરવાની કોઈ જરૂર નથી. તેના બદલે, તમારે ઉપકરણોને ઉચ્ચ સ્તરે લોજિકલ વોલ્યુમમાં એકત્રિત કરવાની જરૂર છે, જેમ કે કેટલીક નેટવર્ક ફાઇલ સિસ્ટમ્સ વિવિધ મશીનો (સ્ટોરેજ નોડ્સ) સાથે કરે છે. સાચું છે, ખરાબ અલ્ગોરિધમ્સના ઉપયોગને કારણે તેઓ આ ઘૃણાસ્પદ રીતે કરે છે.

એકદમ ભયંકર અલ્ગોરિધમ્સના ઉદાહરણો GlusterFS ફાઇલ સિસ્ટમમાં DHT અનુવાદક અને Ceph ફાઇલ સિસ્ટમમાં કહેવાતા CRUSH નકશો છે. સાદગી અને સારી માપનીયતાના સંદર્ભમાં મેં જોયેલા કોઈપણ અલ્ગોરિધમ્સ મને સંતુષ્ટ કરી શક્યા નથી. તેથી મારે બીજગણિત યાદ રાખવું પડ્યું અને બધું જાતે શોધવું પડ્યું. 2015 માં, હેશ ફંક્શન્સ પર બંડલ્સ સાથે પ્રયોગ કરતી વખતે, હું કંઈક સાથે આવ્યો અને મને અનુકૂળ આવે તેવું પેટન્ટ કર્યું. હવે હું કહી શકું છું કે આ બધું વ્યવહારમાં મૂકવાનો પ્રયાસ સફળ રહ્યો. મને નવા અભિગમમાં માપનીયતા સાથે કોઈ સમસ્યા દેખાતી નથી.

હા, દરેક સબવોલ્યુમને અલગ સ્ટ્રક્ચરની જરૂર પડશે જેમ કે મેમરીમાં સુપરબ્લોક. શું આ ખૂબ જ ડરામણી છે? સામાન્ય રીતે, હું જાણતો નથી કે કોણ "સમુદ્રને ઉકાળશે" અને એક સ્થાનિક મશીન પર સેંકડો હજારો અથવા વધુ ઉપકરણોના લોજિકલ વોલ્યુમ બનાવશે. જો કોઈ મને આ સમજાવશે, તો હું ખૂબ આભારી રહીશ. આ દરમિયાન, મારા માટે આ માર્કેટિંગ બુલશીટ છે.

કર્નલ બ્લોક ઉપકરણ સબસિસ્ટમમાં ફેરફારો (ઉદાહરણ તરીકે, blk-mq નો દેખાવ) FS અમલીકરણ માટેની જરૂરિયાતોને કેવી રીતે અસર કરે છે?

તેમને કોઈ અસર થઈ ન હતી. મને ખબર નથી કે બ્લોક લેયર પર શું થશે જેનાથી નવી FS ડિઝાઇન કરવી જરૂરી બનશે. આ સબસિસ્ટમ્સની ક્રિયાપ્રતિક્રિયા ઇન્ટરફેસ ખૂબ નબળી છે. ડ્રાઇવર બાજુથી, FS ફક્ત નવા પ્રકારની ડ્રાઇવ્સના દેખાવથી પ્રભાવિત થવી જોઈએ, જેમાં બ્લોક લેયરને પહેલા એડજસ્ટ કરવામાં આવશે, અને પછી FS (reiser4 માટે આનો અર્થ નવા પ્લગિન્સનો દેખાવ હશે).

શું નવા પ્રકારનાં માધ્યમોના ઉદભવ (ઉદાહરણ તરીકે, SMR, અથવા SSD ની સર્વવ્યાપકતા) નો અર્થ ફાઈલ સિસ્ટમ ડિઝાઇન માટે મૂળભૂત રીતે નવા પડકારો છે?

હા. અને આ FS ના વિકાસ માટે સામાન્ય પ્રોત્સાહનો છે. પડકારો અલગ અને સંપૂર્ણપણે અનપેક્ષિત હોઈ શકે છે. ઉદાહરણ તરીકે, મેં એવી ડ્રાઇવ્સ વિશે સાંભળ્યું છે જ્યાં I/O ઑપરેશનની ઝડપ ડેટાના ભાગ અને તેના ઑફસેટના કદ પર ખૂબ નિર્ભર હોય છે. Linux માં, જ્યાં FS બ્લોકનું કદ પૃષ્ઠના કદ કરતાં વધી શકતું નથી, આવી ડ્રાઇવ મૂળભૂત રીતે તેની સંપૂર્ણ ક્ષમતાઓ બતાવશે નહીં. જો કે, જો તમારી ફાઇલ સિસ્ટમ યોગ્ય રીતે ડિઝાઇન કરવામાં આવી છે, તો તેમાંથી ઘણું બધું મેળવવાની તક છે.

તમારા સિવાય હાલમાં કેટલા લોકો Reiser4 કોડ સાથે કામ કરી રહ્યા છે?

હું ઇચ્છું તેના કરતાં ઓછું, પરંતુ મને સંસાધનોની તીવ્ર અછતનો અનુભવ થતો નથી. હું Reiser4 ના વિકાસની ગતિથી વધુ સંતુષ્ટ છું. હું "ઘોડા ચલાવવા" નથી જઈ રહ્યો - આ યોગ્ય ક્ષેત્ર નથી. અહીં, "જો તમે વધુ શાંતિથી વાહન ચલાવશો, તો તમે આગળ વધવાનું ચાલુ રાખશો!" આધુનિક ફાઇલ સિસ્ટમ એ સૌથી જટિલ કર્નલ સબસિસ્ટમ છે, જેના ખોટા ડિઝાઈન નિર્ણયો માનવીય કાર્યના અનુગામી વર્ષોને પૂર્વવત્ કરી શકે છે.

સ્વયંસેવકોને કંઈક અમલમાં મૂકવાની ઓફર કરીને, હું હંમેશા ખાતરી આપું છું કે પ્રયત્નો ચોક્કસપણે યોગ્ય પરિણામ તરફ દોરી જશે, જે ગંભીર જરૂરિયાતો માટે માંગમાં હોઈ શકે છે. જેમ તમે સમજો છો, એક સાથે આવી ઘણી ગેરંટી હોઈ શકતી નથી. તે જ સમયે, હું એવા "આંકડાઓ" ને ટકી શકતો નથી જે દેખીતી રીતે બિનઉપયોગી સૉફ્ટવેરની "સુવિધાઓ" નો નિર્લજ્જતાથી પ્રચાર કરે છે, સેંકડો વપરાશકર્તાઓ અને વિકાસકર્તાઓને છેતરે છે, અને તે જ સમયે કર્નલ સમિટમાં બેસીને સ્મિત કરે છે.

શું કોઈ કંપનીએ Reiser4 ના વિકાસને સમર્થન આપવાની ઈચ્છા દર્શાવી છે?

હા, આવી દરખાસ્તો હતી, સહિત. અને મુખ્ય વિક્રેતા પાસેથી. પરંતુ આ માટે મારે બીજા દેશમાં જવું પડ્યું. કમનસીબે, હું હવે 30 વર્ષનો નથી, હું છૂટા પડી શકતો નથી અને પહેલી સીટી વાગે તે રીતે છોડી શકતો નથી.

Reiser4 માં હાલમાં કઈ સુવિધાઓ ખૂટે છે?

ReiserFS(v3) માં મળેલ સમાન વોલ્યુમો માટે કોઈ "રીસાઈઝ" કાર્ય નથી. વધુમાં, DIRECT_IO ફ્લેગ સાથેની ફાઇલ કામગીરીને નુકસાન થશે નહીં. આગળ, હું વોલ્યુમને "સિમેન્ટીક સબવોલ્યુમ્સ" માં વિભાજિત કરવા સક્ષમ બનવા માંગુ છું, જેનું કદ નિશ્ચિત નથી અને જે સ્વતંત્ર વોલ્યુમ તરીકે માઉન્ટ કરી શકાય છે. આ સમસ્યાઓ નવા નિશાળીયા માટે સારી છે જેઓ "વાસ્તવિક વસ્તુ" પર પોતાનો હાથ અજમાવવા માંગે છે.

અને અંતે, હું સરળ અમલીકરણ અને વહીવટ (આધુનિક અલ્ગોરિધમ્સ પહેલાથી જ આને મંજૂરી આપે છે) સાથે નેટવર્ક લોજિકલ વોલ્યુમ્સ ધરાવવા માંગુ છું. પરંતુ RAID-Z, સ્ક્રબ્સ, ફ્રી સ્પેસ કેશ, 4-બીટ વેરિયેબલ્સ અને અન્ય માર્કેટિંગ નોનસેન્સ જે કેટલીક ફાઇલ સિસ્ટમ્સના વિકાસકર્તાઓમાં વિચારોની અછતની પૃષ્ઠભૂમિ સામે ઉદ્ભવ્યું છે તે Reiser128 ચોક્કસપણે ક્યારેય નહીં હોય.

શું પ્લગઈન્સ દ્વારા જરૂરી હોય તેવી દરેક વસ્તુનો અમલ કરી શકાય છે?

જો આપણે ફક્ત ઈન્ટરફેસ અને પ્લગઈન્સ (મોડ્યુલો)ના સંદર્ભમાં વાત કરીએ જે તેને અમલમાં મૂકે છે, તો બધું જ નહીં. પરંતુ જો તમે આ ઇન્ટરફેસો પર સંબંધો પણ રજૂ કરો છો, તો પછી, અન્ય વસ્તુઓની સાથે, તમારી પાસે ઉચ્ચ પોલિમોર્ફિઝમ્સની વિભાવનાઓ હશે, જે તમે પહેલેથી જ મેળવી શકો છો. કલ્પના કરો કે તમે ઑબ્જેક્ટ-ઓરિએન્ટેડ રનટાઇમ સિસ્ટમને અનુમાનિત રીતે સ્થિર કરી છે, સમાન X ઇન્ટરફેસને અમલમાં મૂકતા અન્ય પ્લગઇન તરફ નિર્દેશ કરવા માટે સૂચના પોઇન્ટરની કિંમત બદલી છે, અને પછી સિસ્ટમને અનફ્રોઝ કરી છે જેથી તે એક્ઝિક્યુટ કરવાનું ચાલુ રાખે.

જો અંતિમ વપરાશકર્તા આવા "અવેજી"ની નોંધ લેતો નથી, તો અમે કહીએ છીએ કે સિસ્ટમ X ઇન્ટરફેસમાં શૂન્ય-ક્રમ પોલીમોર્ફિઝમ ધરાવે છે (અથવા X ઇન્ટરફેસમાં સિસ્ટમ વિજાતીય છે, જે સમાન વસ્તુ છે). જો હવે તમારી પાસે ફક્ત ઇન્ટરફેસનો સમૂહ નથી, પણ તેના પર સંબંધો પણ છે (ઇન્ટરફેસ ગ્રાફ), તો પછી તમે ઉચ્ચ ઓર્ડરના પોલીમોર્ફિઝમ્સ રજૂ કરી શકો છો, જે કોઈપણ ઇન્ટરફેસના "પડોશ" માં પહેલેથી જ સિસ્ટમની વિશિષ્ટતાને લાક્ષણિકતા આપશે. મેં લાંબા સમય પહેલા આવા વર્ગીકરણની રજૂઆત કરી હતી, પરંતુ, કમનસીબે, તે ક્યારેય બન્યું નથી.

તેથી, પ્લગઇન્સ અને આવા ઉચ્ચ પોલીમોર્ફિઝમ્સની મદદથી, તમે કોઈપણ જાણીતી વિશેષતાનું વર્ણન કરી શકો છો, તેમજ તે "અનુમાન" કરી શકો છો જેનો ઉલ્લેખ ક્યારેય કરવામાં આવ્યો નથી. હું આને સખત રીતે સાબિત કરી શક્યો નથી, પરંતુ મને હજી સુધી પ્રતિઉદાહરણની પણ ખબર નથી. સામાન્ય રીતે, આ પ્રશ્ને મને ફેલિક્સ ક્લેઈનના “એર્લાંગેન પ્રોગ્રામ”ની યાદ અપાવી. એક સમયે તેણે તમામ ભૂમિતિને બીજગણિતની શાખા તરીકે રજૂ કરવાનો પ્રયાસ કર્યો (ખાસ કરીને, જૂથ સિદ્ધાંત).

હવે મુખ્ય પ્રશ્ન પર - Reiser4 ના પ્રમોશન સાથે મુખ્ય કોર પર વસ્તુઓ કેવી રીતે જઈ રહી છે? શું આ ફાઇલ સિસ્ટમના આર્કિટેક્ચર પર કોઈ પ્રકાશનો હતા જેના વિશે તમે છેલ્લી મુલાકાતમાં વાત કરી હતી? તમારા દૃષ્ટિકોણથી આ પ્રશ્ન કેટલો સુસંગત છે?

સામાન્ય રીતે, અમે ત્રણ વર્ષથી મુખ્ય શાખામાં સમાવેશ કરવા માટે કહીએ છીએ. સાર્વજનિક થ્રેડમાં રીઝરની છેલ્લી ટિપ્પણી જ્યાં પુલ વિનંતી કરવામાં આવી હતી તે અનુત્તરિત રહી. તેથી આગળના બધા પ્રશ્નો આપણા માટે નથી. હું વ્યક્તિગત રીતે સમજી શકતો નથી કે શા માટે આપણે ચોક્કસ ઓપરેટિંગ સિસ્ટમમાં "મર્જ" કરવાની જરૂર છે. Linux પર, પ્રકાશ ફાચરની જેમ એકીકૃત થતો ન હતો. તેથી, એક અલગ રીપોઝીટરી છે જેમાં વિવિધ OS માટે અનેક શાખા-બંદરો હશે. જેને તેની જરૂર હોય તે અનુરૂપ પોર્ટને ક્લોન કરી શકે છે અને તેની સાથે તમે જે ઇચ્છો તે કરી શકો છો (અલબત્ત લાયસન્સની અંદર). ઠીક છે, જો કોઈને તેની જરૂર નથી, તો તે મારી સમસ્યા નથી. આ બિંદુએ, હું "મુખ્ય Linux કર્નલમાં પ્રમોશન" ના પ્રશ્નને સ્થાયી તરીકે ધ્યાનમાં લેવાનો પ્રસ્તાવ મૂકું છું.

FS આર્કિટેક્ચર પરના પ્રકાશનો સંબંધિત છે, પરંતુ અત્યાર સુધી મને મારા નવા પરિણામો માટે માત્ર સમય મળ્યો છે, જેને હું ઉચ્ચ પ્રાથમિકતા માનું છું. બીજી વાત એ છે કે હું ગણિતશાસ્ત્રી છું, અને ગણિતમાં કોઈપણ પ્રકાશન એ પ્રમેય અને તેમના પુરાવાઓનો સારાંશ છે. પુરાવા વિના ત્યાં કંઈપણ પ્રકાશિત કરવું એ ખરાબ સ્વાદની નિશાની છે. જો હું FS ના આર્કિટેક્ચર વિશેના કોઈપણ નિવેદનને સંપૂર્ણ રીતે સાબિત કરીશ અથવા નકારી કાઢું, તો પરિણામ એવા થાંભલાઓ આવશે કે તેમાંથી પસાર થવું ખૂબ મુશ્કેલ હશે. કોને તેની જરૂર છે? કદાચ આ જ કારણ છે કે બધું તેના જૂના સ્વરૂપમાં જ રહે છે - સ્રોત કોડ અને તેના પર ટિપ્પણીઓ.

છેલ્લા કેટલાક વર્ષોમાં Reiser4 માં નવું શું છે?

લાંબા સમયથી રાહ જોવાતી સ્થિરતા આખરે સાકાર થઈ છે. સૌથી છેલ્લે દેખાતો એક બગ હતો જે "અનડીલીટેબલ" ડિરેક્ટરીઓ તરફ દોરી ગયો. મુશ્કેલી એ હતી કે તે નામ હેશ અથડામણની પૃષ્ઠભૂમિ સામે અને ટ્રી નોડમાં નિર્દેશિકા રેકોર્ડના ચોક્કસ સ્થાન સાથે જ દેખાય છે. જો કે, હું હજી પણ ઉત્પાદન માટે Reiser4 ની ભલામણ કરી શકતો નથી: આ માટે તમારે ઉત્પાદન સિસ્ટમ સંચાલકો સાથે સક્રિય ક્રિયાપ્રતિક્રિયા સાથે થોડું કામ કરવાની જરૂર છે.

અમે આખરે અમારા લાંબા સમયથી ચાલતા વિચારને અમલમાં મુકવામાં સફળ થયા - વિવિધ ટ્રાન્ઝેક્શન મોડલ્સ. અગાઉ, Reiser4 માત્ર એક હાર્ડકોડેડ Macdonald-Reiser મોડલ ચલાવતું હતું. આનાથી ડિઝાઇન સમસ્યાઓ ઊભી થઈ. ખાસ કરીને, આવા વ્યવહારિક મોડેલમાં સ્નેપશોટ શક્ય નથી - તે "ઓવરરાઈટ સેટ" નામના અણુ ઘટક દ્વારા દૂષિત થશે. Reiser4 હાલમાં ત્રણ ટ્રાન્ઝેક્શન મોડલને સપોર્ટ કરે છે. તેમાંના એકમાં (કોઈપણ જગ્યાએ લખો), અણુ ઘટક ઓવરરાઈટ સેટમાં ફક્ત સિસ્ટમ પૃષ્ઠો (ડિસ્ક બીટમેપ્સની છબીઓ, વગેરે) શામેલ છે, જે "ફોટોગ્રાફી" કરી શકાતા નથી (ચિકન અને ઇંડાની સમસ્યા).

તેથી ચિત્રો હવે શ્રેષ્ઠ શક્ય રીતે સાકાર કરી શકાય છે. અન્ય ટ્રાન્ઝેક્શનલ મોડલમાં, બધા સંશોધિત પૃષ્ઠો ફક્ત ઓવરરાઈટ સેટ પર જાય છે (એટલે ​​​​કે, તે આવશ્યકપણે શુદ્ધ જર્નલિંગ છે). આ મોડેલ તે લોકો માટે છે જેમણે Reiser4 પાર્ટીશનોના ઝડપી ફ્રેગમેન્ટેશન વિશે ફરિયાદ કરી હતી. હવે આ મોડેલમાં તમારું પાર્ટીશન ReiserFS (v3) કરતા વધુ ઝડપથી ફ્રેગમેન્ટ થશે નહીં. હાલના ત્રણેય મોડલ, કેટલાક રિઝર્વેશન સાથે, કામગીરીની અણુશકિતની બાંયધરી આપે છે, પરંતુ અણુશકિતની ખોટ અને માત્ર વિભાગની અખંડિતતાને જાળવતા મોડલ પણ ઉપયોગી થઈ શકે છે. આવા મોડેલો તમામ પ્રકારની એપ્લિકેશનો (ડેટાબેસેસ, વગેરે) માટે ઉપયોગી થઈ શકે છે, જેણે આમાંના કેટલાક કાર્યો પહેલેથી જ લીધા છે. આ મોડલ્સને Reiser4 માં ઉમેરવું ખૂબ જ સરળ છે, પરંતુ મેં તે કર્યું નથી, કારણ કે કોઈએ મને પૂછ્યું નથી, અને મને વ્યક્તિગત રીતે તેની જરૂર નથી.

મેટાડેટા ચેકસમ દેખાયા અને મેં તાજેતરમાં તેમને "આર્થિક" અરીસાઓ (હજુ પણ અસ્થિર સામગ્રી) સાથે પૂરક બનાવ્યા. જો કોઈપણ બ્લોકનું ચેકસમ નિષ્ફળ જાય, તો Reiser4 તરત જ પ્રતિકૃતિ ઉપકરણમાંથી અનુરૂપ બ્લોક વાંચે છે. નોંધ કરો કે ZFS અને Btrf આ કરી શકતા નથી: ડિઝાઇન તેને મંજૂરી આપતી નથી. ત્યાં તમારે "સ્ક્રબ" નામની ખાસ બેકગ્રાઉન્ડ સ્કેનિંગ પ્રક્રિયા ચલાવવી પડશે અને તે સમસ્યારૂપ બ્લોક સુધી પહોંચે તેની રાહ જોવી પડશે. પ્રોગ્રામરો અલંકારિક રીતે આવી ઘટનાઓને "ક્રચ" કહે છે.

અને છેવટે, વિજાતીય લોજિકલ વોલ્યુમો દેખાયા છે, જે ZFS, Btrfs, બ્લોક લેયર, તેમજ FS+LVM સંયોજનો સિદ્ધાંતમાં પ્રદાન કરી શકતા નથી તે બધું પ્રદાન કરે છે - સમાંતર સ્કેલિંગ, O(1) ડિસ્ક સરનામું ફાળવનાર, સબવોલ્યુમ્સ વચ્ચે પારદર્શક ડેટા સ્થળાંતર. બાદમાં યુઝર ઇન્ટરફેસ પણ છે. હવે તમે સૌથી ગરમ ડેટાને તમારા વોલ્યુમ પર સૌથી વધુ-પ્રદર્શન ડ્રાઇવ પર સરળતાથી ખસેડી શકો છો.

વધુમાં, આવી ડ્રાઈવમાં કોઈપણ ગંદા પૃષ્ઠોને તાત્કાલિક ફ્લશ કરવું શક્ય છે, જેનાથી એપ્લીકેશનને નોંધપાત્ર રીતે ઝડપી બનાવી શકાય છે જે ઘણીવાર fsync(2) તરીકે ઓળખાય છે. હું નોંધું છું કે બ્લોક લેયર કાર્યક્ષમતા, જેને bcache કહેવામાં આવે છે, તે ક્રિયાની આવી સ્વતંત્રતા પૂરી પાડતી નથી. નવા લોજિકલ વોલ્યુમો મારા અલ્ગોરિધમ્સ પર આધારિત છે (ત્યાં અનુરૂપ પેટન્ટ છે). સૉફ્ટવેર પહેલેથી જ એકદમ સ્થિર છે, તેનો પ્રયાસ કરવો, પ્રદર્શન માપવા વગેરે શક્ય છે. એકમાત્ર અસુવિધા એ છે કે હમણાં માટે તમારે વોલ્યુમ ગોઠવણીને મેન્યુઅલી અપડેટ કરવાની અને તેને ક્યાંક સંગ્રહિત કરવાની જરૂર છે.

અત્યાર સુધી હું મારા વિચારોને 10 ટકા અમલમાં લાવવામાં સફળ રહ્યો છું. જો કે, મેં જે સૌથી મુશ્કેલ બાબત ગણી હતી તેમાં હું સફળ થયો છું - તાર્કિક વોલ્યુમોને ફ્લેશ પ્રક્રિયા સાથે કનેક્ટ કરવું જે રીઝર 4 માં બધી વિલંબિત ક્રિયાઓ કરે છે. આ બધું હજી પ્રાયોગિક “ફોર્મેટ 41” શાખામાં છે.

શું Reiser4 xfstests પાસ કરે છે?

જ્યારે હું છેલ્લી રિલીઝ તૈયાર કરી રહ્યો હતો ત્યારે ઓછામાં ઓછું તે મારા માટે થયું.

શું પ્લગિન્સનો ઉપયોગ કરીને Reiser4 ને નેટવર્ક (ક્લસ્ટર) FS બનાવવાનું સિદ્ધાંતમાં શક્ય છે?

તે શક્ય છે, અને તે પણ જરૂરી છે! જો તમે યોગ્ય રીતે ડિઝાઇન કરેલી સ્થાનિક ફાઇલ સિસ્ટમ પર આધારિત નેટવર્ક ફાઇલ બનાવો છો, તો પરિણામ ખૂબ જ પ્રભાવશાળી હશે! આધુનિક નેટવર્ક FS માં, હું બેકએન્ડ સ્ટોરેજ સ્તરની હાજરીથી સંતુષ્ટ નથી, જે કોઈપણ સ્થાનિક FS નો ઉપયોગ કરીને લાગુ કરવામાં આવે છે. આ સ્તરનું અસ્તિત્વ સંપૂર્ણપણે ગેરવાજબી છે. નેટવર્ક FS એ બ્લોક લેયર સાથે સીધું જ ક્રિયાપ્રતિક્રિયા કરવી જોઈએ, અને સ્થાનિક FS ને કોઈપણ અન્ય સેવા ફાઈલો બનાવવા માટે કહો નહીં!

સામાન્ય રીતે, ફાઈલ સિસ્ટમને સ્થાનિક અને નેટવર્કમાં વિભાજીત કરવી એ દુષ્ટતામાંથી છે. તે અલ્ગોરિધમ્સની અપૂર્ણતામાંથી ઉદભવ્યું છે જેનો ઉપયોગ ત્રીસ વર્ષ પહેલાં કરવામાં આવ્યો હતો, અને તેના સ્થાને હજુ સુધી કંઈપણ પ્રસ્તાવિત કરવામાં આવ્યું નથી. આ બિનજરૂરી સૉફ્ટવેર ઘટકો (વિવિધ સેવાઓ, વગેરે) ના સમૂહના દેખાવનું કારણ પણ છે. સારી રીતે, કર્નલ મોડ્યુલના સ્વરૂપમાં માત્ર એક FS હોવો જોઈએ અને દરેક મશીન પર ઇન્સ્ટોલ કરેલ વપરાશકર્તા ઉપયોગિતાઓનો સમૂહ હોવો જોઈએ - એક ક્લસ્ટર નોડ. આ FS સ્થાનિક અને નેટવર્ક બંને છે. અને વધુ કંઈ નહીં!

જો Linux પર Reiser4 સાથે કંઈ કામ ન થાય, તો હું ફ્રીબીએસડી માટે એફએસ ઓફર કરવા માંગુ છું (અગાઉના ઇન્ટરવ્યુમાંથી અવતરણ: “...ફ્રીબીએસડી... શૈક્ષણિક મૂળ ધરાવે છે... અને આનો અર્થ એ છે કે ઉચ્ચ સ્તરની સંભાવના સાથે અમે વિકાસકર્તાઓ સાથે સામાન્ય ભાષા મળશે")?

તેથી, જેમ આપણે હમણાં જ શોધી કાઢ્યું છે, બધું પહેલેથી જ લિનક્સ સાથે સંપૂર્ણ રીતે કામ કરી ગયું છે: અમારા ભંડારની મુખ્ય શાખાના રૂપમાં તેના માટે એક અલગ કાર્યકારી Reiser4 પોર્ટ છે. હું ફ્રીબીએસડી વિશે ભૂલી ગયો નથી! ઓફર! હું એવા લોકો સાથે નજીકથી કામ કરવા તૈયાર છું જેઓ FreeBSD ની અંદરની બાબતો સારી રીતે જાણે છે. માર્ગ દ્વારા: મને તેમના સમુદાય વિશે ખરેખર જે ગમે છે તે એ છે કે ત્યાં સ્વતંત્ર નિષ્ણાતોની અપડેટ કાઉન્સિલ દ્વારા નિર્ણયો લેવામાં આવે છે, જેને એક કાયમી વ્યક્તિની સરકારી છેતરપિંડી સાથે કોઈ લેવાદેવા નથી.

આજે તમે Linux વપરાશકર્તા સમુદાયને કેવી રીતે રેટ કરો છો? શું તે વધુ "પોપ" બની ગયું છે?

મારા કામની પ્રકૃતિને જોતાં, આનું મૂલ્યાંકન કરવું મારા માટે ઘણું મુશ્કેલ છે. મોટાભાગે વપરાશકર્તાઓ બગ રિપોર્ટ્સ અને વિભાગને ઠીક કરવાની વિનંતીઓ સાથે મારી પાસે આવે છે. વપરાશકર્તાઓ તરીકે વપરાશકર્તાઓ. કેટલાક વધુ સમજદાર છે, કેટલાક ઓછા. દરેકની સાથે સમાન વ્યવહાર કરવામાં આવે છે. ઠીક છે, જો વપરાશકર્તા મારી સૂચનાઓને અવગણે છે, તો મને માફ કરો: અવગણો ઓર્ડર મારા તરફથી પણ દાખલ કરવામાં આવશે.

શું આગામી પાંચથી દસ વર્ષ માટે ફાઇલ સિસ્ટમ્સના વિકાસની આગાહી કરવી શક્ય છે? તમને શું લાગે છે કે FS ડેવલપર્સ જે મુખ્ય પડકારોનો સામનો કરી શકે છે?

હા, આવી આગાહી કરવી મુશ્કેલ નથી. અપસ્ટ્રીમમાં લાંબા સમયથી ફાઈલ સિસ્ટમનો કોઈ વિકાસ થયો નથી. આવા માત્ર દેખાવ જ સર્જાય છે. સ્થાનિક ફાઇલ સિસ્ટમના વિકાસકર્તાઓ નબળી ડિઝાઇન સાથે સંકળાયેલ સમસ્યાઓનો સામનો કરી રહ્યા હતા. અહીં એક ચેતવણી આપવી જરૂરી છે. હું કહેવાતા "સ્ટોરેજ", "ચાટવું" અને કોડના પોર્ટિંગને વિકાસ અને વિકાસ માનતો નથી. અને હું "Btrfs" નામની ગેરસમજને વિકાસ તરીકે વર્ગીકૃત કરતો નથી જે કારણો મેં પહેલાથી જ સમજાવ્યા છે.

દરેક પેચ ફક્ત તેની સમસ્યાઓને વધુ ખરાબ બનાવે છે. વેલ. અને ત્યાં હંમેશા વિવિધ પ્રકારના "પ્રચારક" હોય છે જેમના માટે "બધું કાર્ય કરે છે." મૂળભૂત રીતે, આ શાળાના બાળકો અને વિદ્યાર્થીઓ પ્રવચનો છોડતા હોય છે. જરા કલ્પના કરો: તે તેના માટે કામ કરે છે, પરંતુ પ્રોફેસર નથી કરતું. આ શું એડ્રેનાલિન ધસારો છે! મારા દૃષ્ટિકોણથી, સૌથી વધુ નુકસાન "કારીગરો" દ્વારા થાય છે જેઓ ઉત્સાહપૂર્વક Btrfs ની અદ્ભુત વિશેષતાઓને સિસ્ટમડ, ડોકર, વગેરે જેવા તમામ પ્રકારના સ્તરો પર "સ્ક્રૂ" કરવા દોડી ગયા હતા. - આ પહેલેથી જ મેટાસ્ટેસિસ જેવું લાગે છે.

ચાલો હવે પાંચથી દસ વર્ષ માટે આગાહી કરવાનો પ્રયાસ કરીએ. મેં પહેલેથી જ સંક્ષિપ્તમાં સૂચિબદ્ધ કર્યું છે કે આપણે Reiser4 માં શું કરીશું. અપસ્ટ્રીમના સ્થાનિક FS વિકાસકર્તાઓ માટે મુખ્ય પડકાર હશે (હા, તે પહેલેથી જ બની ગયું છે) પગાર માટે યોગ્ય નોકરી કરવામાં અસમર્થતા. ડેટા સ્ટોરેજના ક્ષેત્રમાં કોઈપણ વિચારો વિના, તેઓ આ કમનસીબ VFS, XFS અને ext4ને પેચ કરવાનો પ્રયાસ કરવાનું ચાલુ રાખશે. VFS ની પરિસ્થિતિ આ પૃષ્ઠભૂમિ સામે ખાસ કરીને હાસ્યજનક લાગે છે, જે રેસ્ટોરન્ટના ઉન્મત્ત આધુનિકીકરણની યાદ અપાવે છે જેમાં કોઈ રસોઇયા નથી અને કોઈ રસોઇયાની અપેક્ષા નથી.

હવે VFS કોડ, કોઈપણ શરતો વિના, એક જ સમયે અનેક મેમરી પૃષ્ઠોને લોક કરે છે અને અંતર્ગત FS ને તેમના પર કામ કરવા માટે આમંત્રિત કરે છે. ડિલીટ ઓપરેશન્સ પર Ext4 ના પ્રદર્શનને સુધારવા માટે આ રજૂ કરવામાં આવ્યું હતું, પરંતુ સમજવામાં સરળ છે તેમ, આવા સમવર્તી લોકીંગ અદ્યતન ટ્રાન્ઝેક્શન મોડલ્સ સાથે સંપૂર્ણપણે અસંગત છે. એટલે કે, તમે કર્નલમાં કેટલીક સ્માર્ટ ફાઇલ સિસ્ટમ માટે આધાર ઉમેરવા માટે સમર્થ હશો નહીં. હું જાણતો નથી કે Linux ના અન્ય ક્ષેત્રોમાં શું પરિસ્થિતિ છે, પરંતુ જ્યાં સુધી ફાઇલ સિસ્ટમનો સંબંધ છે, અહીંનો કોઈપણ વિકાસ વ્યવહારમાં Torvalds દ્વારા અનુસરવામાં આવતી નીતિ સાથે સુસંગત હોવાની શક્યતા નથી (શૈક્ષણિક પ્રોજેક્ટ્સ બહાર કાઢવામાં આવે છે, અને સ્કેમર્સ જેઓ બી-ટ્રી, વિશ્વાસની અનંત ક્રેડિટ્સ જારી કરવામાં આવે છે તે વિશે કોઈ ખ્યાલ નથી). તેથી, ધીમા સડો માટે કોર્સ સેટ કરવામાં આવ્યો હતો. અલબત્ત, તેઓ તેને "વિકાસ" તરીકે પસાર કરવા માટે તેમની તમામ શક્તિથી પ્રયાસ કરશે.

આગળ, ફાઇલ સિસ્ટમના “કસ્ટોડિયન”, એ સમજીને કે તમે એકલા “સ્ટોરેજ”માંથી વધુ કમાણી કરી શકતા નથી, વધુ નફાકારક વ્યવસાયમાં તેમનો હાથ અજમાવશે. આ, એક નિયમ તરીકે, વિતરિત ફાઇલ સિસ્ટમ્સ અને વર્ચ્યુઅલાઈઝેશન છે. કદાચ તેઓ ફેશનેબલ ZFS ને બીજે ક્યાંક પોર્ટ કરશે જ્યાં તે હજી અસ્તિત્વમાં નથી. પરંતુ તે, અપસ્ટ્રીમના તમામ એફએસની જેમ, નવા વર્ષના વૃક્ષ જેવું લાગે છે: જો તમે ટોચ પર કેટલીક અન્ય નાની વસ્તુઓ લટકાવી શકો છો, તો પછી તમે વધુ ઊંડાણ મેળવી શકતા નથી. હું કબૂલ કરું છું કે ઝેડએફએસ પર આધારિત ગંભીર એન્ટરપ્રાઇઝ સિસ્ટમ બનાવવી શક્ય છે, પરંતુ હવે આપણે ભવિષ્યની ચર્ચા કરી રહ્યા છીએ, તેથી હું ફક્ત એટલું જ કહી શકું છું કે ઝેડએફએસ આ સંદર્ભમાં નિરાશાજનક છે: તેમના વર્ચ્યુઅલ ઉપકરણો સાથે, લોકોએ ઓક્સિજનને કાપી નાખ્યો છે. વધુ વિકાસ માટે પોતાને અને ભાવિ પેઢીઓ માટે. ZFS એ ભૂતકાળની વાત છે. અને ext4 અને XFS એ ગઈ કાલના એક દિવસ પહેલા પણ નથી.

"નેક્સ્ટ જનરેશનની લિનક્સ ફાઇલ સિસ્ટમ" ના સનસનાટીભર્યા ખ્યાલ વિશે અલગથી ઉલ્લેખ કરવો યોગ્ય છે. આ એક સંપૂર્ણ રાજકીય અને માર્કેટિંગ પ્રોજેક્ટ છે જે તક માટે બનાવવામાં આવ્યો છે, તેથી બોલવા માટે, Linux માં ચોક્કસ અક્ષરોની પાછળ "ફાઇલ સિસ્ટમ્સના ભાવિને પિન કરવા" માટે. હકીકત એ છે કે લિનક્સ "ફક્ત મનોરંજન માટે" હતું. પરંતુ હવે તે મુખ્યત્વે પૈસા કમાવવાનું મશીન છે. તેઓ શક્ય બધું પર બનાવવામાં આવે છે. ઉદાહરણ તરીકે, એક સારું સોફ્ટવેર ઉત્પાદન બનાવવું ખૂબ જ મુશ્કેલ છે, પરંતુ સ્માર્ટ "વિકાસકર્તાઓ" લાંબા સમયથી સમજી ગયા છે કે તેમાં કોઈ તાણની જરૂર નથી: તમે બિન-અસ્તિત્વ ધરાવતા સોફ્ટવેરને સફળતાપૂર્વક વેચી શકો છો જેની જાહેરાત અને પ્રચાર તમામ પ્રકારના જાહેરમાં કરવામાં આવ્યો હતો. ઇવેન્ટ્સ - મુખ્ય વસ્તુ એ છે કે પ્રસ્તુતિ સ્લાઇડ્સમાં વધુ "સુવિધાઓ" હોવી જોઈએ.

ફાઇલ સિસ્ટમ્સ આ માટે યોગ્ય છે, કારણ કે તમે પરિણામ પર દસ વર્ષ માટે સુરક્ષિત રીતે સોદો કરી શકો છો. ઠીક છે, જો કોઈ વ્યક્તિ પછીથી આ ખૂબ જ પરિણામના અભાવ વિશે ફરિયાદ કરે છે, તો તે ફાઇલ સિસ્ટમ્સ વિશે કંઈપણ સમજી શકતો નથી! આ એક નાણાકીય પિરામિડની યાદ અપાવે છે: ટોચ પર સાહસિકો છે જેમણે આ ગડબડ શરૂ કરી હતી, અને તે થોડા જેઓ "નસીબદાર" હતા: તેઓએ "ડિવિડન્ડ પાછું ખેંચ્યું," એટલે કે. વિકાસ માટે પૈસા મેળવ્યા, મેનેજર તરીકે સારી વેતનવાળી નોકરી મેળવી, પરિષદોમાં "બતાવ્યા" વગેરે.

આગળ તે લોકો આવે છે જેઓ "બદનસીબ" છે: તેઓ નુકસાનની ગણતરી કરશે, બિનઉપયોગી સોફ્ટવેર ઉત્પાદનને ઉત્પાદનમાં જમાવવાના પરિણામો સાથે વ્યવહાર કરશે, "વગેરે. તેમાંના ઘણા વધુ છે. ઠીક છે, પિરામિડના પાયા પર વિકાસકર્તાઓનો વિશાળ સમૂહ "સોઇંગ" નકામો કોડ છે. તેઓ સૌથી વધુ ગુમાવનારા છે, કારણ કે વેડફાયેલો સમય પરત કરી શકાતો નથી. આવા પિરામિડ ટોરવાલ્ડ્સ અને તેના સહયોગીઓ માટે અત્યંત ફાયદાકારક છે. અને આ પિરામિડ જેટલા વધુ છે, તેમના માટે વધુ સારું છે. આવા પિરામિડને ખવડાવવા માટે, કોઈપણ વસ્તુને મૂળમાં લઈ શકાય છે. અલબત્ત, જાહેરમાં તેઓ વિરુદ્ધ કહે છે. પરંતુ હું શબ્દો દ્વારા નહીં પરંતુ ક્રિયાઓ દ્વારા ન્યાય કરું છું.

તેથી, "લિનક્સમાં ફાઇલ સિસ્ટમ્સનું ભાવિ" એ બીજું ખૂબ પ્રચારિત, પરંતુ ભાગ્યે જ ઉપયોગી સોફ્ટવેર છે. Btrfs પછી, ઉચ્ચ સંભાવના સાથે, આવા "ભવિષ્ય" નું સ્થાન Bcachefs દ્વારા લેવામાં આવશે, જે ફાઇલ સિસ્ટમ સાથે Linux બ્લોક સ્તરને પાર કરવાનો બીજો પ્રયાસ છે (ખરાબ ઉદાહરણ ચેપી છે). અને લાક્ષણિક શું છે: Btrfs જેવી જ સમસ્યાઓ છે. મને લાંબા સમય સુધી આની શંકા હતી, અને પછી કોઈક રીતે હું પ્રતિકાર કરી શક્યો નહીં અને કોડમાં જોયું - તે સાચું છે!

Bcachefs અને Btrfs ના લેખકો, તેમના FS બનાવતી વખતે, સક્રિયપણે અન્ય લોકોના સ્ત્રોતોનો ઉપયોગ કરતા હતા, તેમના વિશે થોડું સમજતા હતા. પરિસ્થિતિ બાળકોની રમત "તૂટેલા ફોન" ની ખૂબ જ યાદ અપાવે છે. અને હું અંદાજે કલ્પના કરી શકું છું કે આ કોડ કર્નલમાં કેવી રીતે સમાવવામાં આવશે. વાસ્તવમાં, કોઈ પણ "રેક્સ" જોશે નહીં (દરેક લોકો પછીથી તેમના પર પગ મૂકશે). કોડની શૈલી, અવિદ્યમાન ઉલ્લંઘનોના આરોપો વગેરે વિશે અસંખ્ય પ્રશ્નો પછી, લેખકની "વફાદારી" વિશે, તે અન્ય વિકાસકર્તાઓ સાથે કેટલી સારી રીતે "પ્રતિક્રિયા કરે છે" અને આ બધું કેટલી સફળતાપૂર્વક કરી શકે છે તે વિશે એક નિષ્કર્ષ કાઢવામાં આવશે. પછી કોર્પોરેશનોને વેચવામાં આવશે.

અંતિમ પરિણામ કોઈને રસ લેશે નહીં. વીસ વર્ષ પહેલાં, કદાચ, મને રસ પડ્યો હોત, પરંતુ હવે પ્રશ્નો અલગ રીતે ઉભા થાય છે: શું આને પ્રોત્સાહન આપવું શક્ય બનશે જેથી આગામી દસ વર્ષમાં ચોક્કસ લોકોને રોજગારી મળી શકે. અને, અરે, અંતિમ પરિણામ વિશે આશ્ચર્ય કરવાનો રિવાજ નથી.

સામાન્ય રીતે, હું શરૂઆતથી તમારી ફાઇલ સિસ્ટમને ફરીથી શોધવાનું શરૂ કરવા સામે સખત સલાહ આપીશ. કારણ કે નોંધપાત્ર નાણાકીય રોકાણો પણ દસ વર્ષમાં સ્પર્ધાત્મક કંઈક મેળવવા માટે પૂરતા નથી. અલબત્ત, હું ગંભીર પ્રોજેક્ટ્સ વિશે વાત કરી રહ્યો છું, અને તે વિશે નહીં કે જે કર્નલમાં "દબાણ" કરવાનો છે. તેથી, તમારી જાતને વ્યક્ત કરવાની વધુ અસરકારક રીત એ છે કે અમારી જેમ વાસ્તવિક વિકાસમાં જોડાવું. આ, અલબત્ત, કરવું સરળ નથી - પરંતુ આ કોઈપણ ઉચ્ચ-સ્તરના પ્રોજેક્ટનો કેસ છે.

પ્રથમ, તમારે સ્વતંત્ર રીતે સમસ્યા દૂર કરવાની જરૂર પડશે જે હું ઓફર કરીશ. જે પછી, તમારા ઇરાદાઓની ગંભીરતાની ખાતરી, હું મદદ કરવાનું શરૂ કરીશ. પરંપરાગત રીતે, આપણે ફક્ત આપણા પોતાના વિકાસનો ઉપયોગ કરીએ છીએ. અપવાદો કમ્પ્રેશન અલ્ગોરિધમ્સ અને કેટલાક હેશ કાર્યો છે. અમે વિકાસકર્તાઓને પરિષદોમાં મુસાફરી કરવા માટે મોકલતા નથી, અને પછી અમે બેસીને અન્ય લોકોના વિચારો ("કદાચ શું થશે") ભેગા કરતા નથી, જેમ કે મોટાભાગના સ્ટાર્ટઅપ્સમાં રિવાજ છે.

અમે બધા એલ્ગોરિધમ્સ જાતે વિકસાવીએ છીએ. મને હાલમાં ડેટા સ્ટોરેજ સાયન્સના બીજગણિત અને સંયુક્ત પાસાઓમાં રસ છે. ખાસ કરીને, મર્યાદિત ક્ષેત્રો, એસિમ્પ્ટોટીક્સ, અસમાનતાનો પુરાવો. સામાન્ય પ્રોગ્રામરો માટે પણ કામ છે, પરંતુ મારે તમને તરત જ ચેતવણી આપવી જોઈએ: "બીજી એફએસ જુઓ અને તે જ કરો" માટેના બધા સૂચનો અવગણવામાં આવ્યા છે. VFS મારફત Linux સાથે ગાઢ સંકલન કરવાના હેતુથી પેચો પણ ત્યાં જશે.

તેથી, અમારી પાસે રેક નથી, પરંતુ અમને ક્યાં ખસેડવાની જરૂર છે તેની અમને સમજ છે, અને અમને વિશ્વાસ છે કે આ દિશા યોગ્ય છે. આ સમજ સ્વર્ગમાંથી માન્ના સ્વરૂપે આવી નથી. હું તમને યાદ કરાવી દઉં કે અમારી પાછળ 29 વર્ષનો વિકાસ અનુભવ છે, બે ફાઇલ સિસ્ટમ શરૂઆતથી લખેલી છે. અને ડેટા પુનઃપ્રાપ્તિ ઉપયોગિતાઓની સમાન સંખ્યા. અને આ ઘણું છે!

સોર્સ: opennet.ru