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

ઠીક છે, ZFS, જિજ્ઞાસુ વાચકો સાથે પરિચિત થવા માટે આજનો શ્રેષ્ઠ દિવસ છે. ફક્ત એટલું જાણો કે OpenZFS ડેવલપર મેટ એહરન્સના નમ્ર મૂલ્યાંકનમાં, "તે ખરેખર મુશ્કેલ છે."

પરંતુ અમે નંબરો પર પહોંચીએ તે પહેલાં - અને ત્યાં હશે, હું વચન આપું છું - આઠ-ડિસ્ક ZFS રૂપરેખાંકનના તમામ પ્રકારો માટે, આપણે તેના વિશે વાત કરવાની જરૂર છે કેવી રીતે સામાન્ય રીતે, ZFS ડિસ્ક પર ડેટા સ્ટોર કરે છે.

Zpool, vdev અને ઉપકરણ

આ સંપૂર્ણ પૂલ ડાયાગ્રામમાં ત્રણ સહાયક vdevs, દરેક વર્ગમાંથી એક અને RAIDz2 માટે ચારનો સમાવેશ થાય છે.

સામાન્ય રીતે મેળ ન ખાતા vdev પ્રકારો અને કદનો પૂલ બનાવવાનું કોઈ કારણ હોતું નથી - પરંતુ જો તમે ઇચ્છો તો તમને આમ કરવાથી કોઈ રોકતું નથી.

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

ઝૂપુલ

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

ZFS રીડન્ડન્સી વર્ચ્યુઅલ ઉપકરણ સ્તર પર છે, પૂલ સ્તર પર નહીં. પૂલ લેવલ પર કોઈ નિરર્થકતા નથી - જો કોઈ vdev અથવા સમર્પિત vdev ખોવાઈ જાય, તો તેની સાથે આખો પૂલ ખોવાઈ જાય છે.

આધુનિક સ્ટોરેજ પુલ વર્ચ્યુઅલ ઉપકરણની કેશ અથવા લોગના નુકશાનથી બચી શકે છે - જો કે જો તેઓ પાવર આઉટેજ અથવા સિસ્ટમ ક્રેશ દરમિયાન vdev લોગ ગુમાવે તો તેઓ થોડી માત્રામાં ગંદા ડેટા ગુમાવી શકે છે.

એક સામાન્ય ગેરસમજ છે કે ZFS "ડેટા પટ્ટાઓ" સમગ્ર પૂલ પર લખાયેલ છે. આ સાચુ નથી. Zpool એ રમુજી RAID0 નથી, તે વધુ રમુજી છે જે.બી.ઓ.ડી. જટિલ ચલ વિતરણ પદ્ધતિ સાથે.

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

આધુનિક ZFS રાઈટ એલોકેશન મેથડમાં બનેલ યુટિલાઈઝેશન ડિટેક્શન મિકેનિઝમ લેટન્સી ઘટાડી શકે છે અને અસામાન્ય રીતે ઊંચા લોડના સમયગાળા દરમિયાન થ્રુપુટ વધારી શકે છે - પરંતુ એવું નથી કાર્ટે બ્લેન્ચે એક પૂલમાં ધીમા HDD અને ઝડપી SSD ના અનૈચ્છિક મિશ્રણ પર. આવા અસમાન પૂલ હજી પણ સૌથી ધીમા ઉપકરણની ઝડપે કાર્ય કરશે, એટલે કે, જાણે કે તે સંપૂર્ણપણે આવા ઉપકરણોથી બનેલું હોય.

vdev

દરેક સ્ટોરેજ પૂલમાં એક અથવા વધુ વર્ચ્યુઅલ ઉપકરણો (વર્ચ્યુઅલ ઉપકરણ, vdev) નો સમાવેશ થાય છે. બદલામાં, દરેક vdev એક અથવા વધુ વાસ્તવિક ઉપકરણો ધરાવે છે. મોટા ભાગના વર્ચ્યુઅલ ઉપકરણોનો ઉપયોગ સાદા ડેટા સ્ટોરેજ માટે થાય છે, પરંતુ CACHE, LOG અને SPECIAL સહિત કેટલાક vdev સહાયક વર્ગો છે. આ vdev પ્રકારોમાંના દરેકમાં પાંચમાંથી એક ટોપોલોજી હોઈ શકે છે: સિંગલ ડિવાઇસ (સિંગલ-ડિવાઈસ), RAIDz1, RAIDz2, RAIDz3, અથવા મિરર (મિરર).

RAIDz1, RAIDz2 અને RAIDz3 એ ખાસ જાતો છે જેને જૂના સમયના લોકો ડબલ (વિકર્ણ) પેરિટી RAID કહે છે. 1, 2 અને 3 દરેક ડેટા સ્ટ્રીપ માટે કેટલા પેરિટી બ્લોક્સ ફાળવવામાં આવ્યા છે તેનો સંદર્ભ આપે છે. પેરિટી માટે અલગ ડિસ્કને બદલે, RAIDz વર્ચ્યુઅલ ઉપકરણો આ પેરિટીને સમગ્ર ડિસ્કમાં અર્ધ-સમાન રીતે વિતરિત કરે છે. RAIDz એરે પેરિટી બ્લોક્સ ધરાવે છે તેટલી ડિસ્ક ગુમાવી શકે છે; જો તે બીજું ગુમાવે છે, તો તે તૂટી જશે અને તેની સાથે સ્ટોરેજ પૂલ લઈ જશે.

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

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

CACHE, LOG અને SPECIAL વર્ચ્યુઅલ ઉપકરણો ઉપરોક્ત કોઈપણ ટોપોલોજીમાં બનાવી શકાય છે - પરંતુ યાદ રાખો કે વિશિષ્ટ વર્ચ્યુઅલ ઉપકરણ ગુમાવવાનો અર્થ એ છે કે પૂલ ગુમાવવો, તેથી બિનજરૂરી ટોપોલોજીની ખૂબ ભલામણ કરવામાં આવે છે.

ઉપકરણ

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

ડિસ્ક, ક્યાં તો ચુંબકીય અથવા ઘન સ્થિતિ, એ vdev ના બિલ્ડીંગ બ્લોક્સ તરીકે ઉપયોગમાં લેવાતા સૌથી સામાન્ય બ્લોક ઉપકરણો છે. જો કે, /dev માં વર્ણનકર્તા સાથેનું કોઈપણ ઉપકરણ કરશે - જેથી સમગ્ર હાર્ડવેર RAID એરે અલગ ઉપકરણો તરીકે વાપરી શકાય છે.

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

તમે થોડીક સેકન્ડોમાં સ્પાર્સ ફાઇલોમાંથી ટેસ્ટ પૂલ બનાવી શકો છો - પરંતુ પછીથી આખો પૂલ અને તેના ઘટકોને કાઢી નાખવાનું ભૂલશો નહીં.

ચાલો કહીએ કે તમે આઠ ડિસ્ક પર સર્વર મૂકવા માંગો છો અને 10 TB ડિસ્ક (~9300 GiB) નો ઉપયોગ કરવાની યોજના ઘડી રહ્યા છો - પરંતુ તમને ખાતરી નથી કે કઈ ટોપોલોજી તમારી જરૂરિયાતોને શ્રેષ્ઠ અનુરૂપ છે. ઉપરના ઉદાહરણમાં, અમે સ્પાર્સ ફાઇલોમાંથી સેકન્ડોમાં ટેસ્ટ પૂલ બનાવીએ છીએ - અને હવે આપણે જાણીએ છીએ કે આઠ 2 TB ડિસ્કનો RAIDz10 vdev 50 TiB ઉપયોગી ક્ષમતા પ્રદાન કરે છે.

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

અસરગ્રસ્ત vdev સાથે કનેક્ટ થયા પછી, ફાજલ ઉપકરણ ખોવાયેલા ઉપકરણ પર હોવા જોઈએ તે ડેટાની નકલો અથવા પુનઃનિર્માણ પ્રાપ્ત કરવાનું શરૂ કરે છે. પરંપરાગત RAID માં તેને પુનઃનિર્માણ કહેવામાં આવે છે, જ્યારે ZFS માં તેને રિસિલ્વરિંગ કહેવામાં આવે છે.

એ નોંધવું અગત્યનું છે કે ફાજલ ઉપકરણો નિષ્ફળ ઉપકરણોને કાયમી ધોરણે બદલતા નથી. આ માત્ર એક અસ્થાયી ફેરબદલી છે જે vdev ના અધોગતિના સમયને ઘટાડવા માટે છે. એડમિનિસ્ટ્રેટરે નિષ્ફળ vdev ને બદલ્યા પછી, તે કાયમી ઉપકરણ પર રીડન્ડન્સી પુનઃસ્થાપિત કરવામાં આવે છે, અને SPARE ને vdev થી ડિસ્કનેક્ટ કરવામાં આવે છે અને સમગ્ર પૂલ માટે ફાજલ તરીકે કામ પર પાછા ફરે છે.

ડેટા સેટ્સ, બ્લોક્સ અને સેક્ટર

અમારા ZFS પ્રવાસ પર સમજવા માટે બિલ્ડીંગ બ્લોક્સનો આગળનો સેટ હાર્ડવેર વિશે ઓછો છે અને ડેટા પોતે કેવી રીતે વ્યવસ્થિત અને સંગ્રહિત થાય છે તે વિશે વધુ છે. અમે અહીં કેટલાક સ્તરો છોડી રહ્યાં છીએ - જેમ કે મેટાસ્લેબ - જેથી કરીને એકંદર માળખાની સમજ જાળવી રાખતી વખતે વિગતોમાં ગડબડ ન થાય.

ડેટાસેટ

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

Zvol એ તેના ફાઇલસિસ્ટમ લેયરમાંથી છીનવી લેવાયેલ ડેટાસેટ છે, જેને અમે અહીં સંપૂર્ણ સામાન્ય ext4 ફાઇલસિસ્ટમ સાથે બદલી રહ્યા છીએ.

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

સૌ પ્રથમ, ડેટાસેટમાં સોંપાયેલ ક્વોટા હોઈ શકે છે. જો સેટ કરો zfs set quota=100G poolname/datasetname, તો પછી તમે માઉન્ટ થયેલ ફોલ્ડરમાં લખી શકશો નહીં /poolname/datasetname 100 GiB થી વધુ.

દરેક લાઇનની શરૂઆતમાં સ્લેશની હાજરી - અને ગેરહાજરી - પર ધ્યાન આપો? ZFS હાયરાર્કી અને સિસ્ટમ માઉન્ટ હાઇરાર્કી બંનેમાં દરેક ડેટાસેટનું પોતાનું સ્થાન છે. ZFS હાયરાર્કીમાં કોઈ અગ્રણી સ્લેશ નથી - તમે પૂલના નામથી પ્રારંભ કરો અને પછી એક ડેટાસેટથી બીજા સુધીનો માર્ગ. દાખ્લા તરીકે, pool/parent/child નામના ડેટાસેટ માટે child પિતૃ ડેટાસેટ હેઠળ parent સર્જનાત્મક નામ સાથે પૂલમાં pool.

ડિફૉલ્ટ રૂપે, ડેટાસેટનો માઉન્ટ પોઈન્ટ ZFS વંશવેલોમાં તેના નામની સમકક્ષ હશે, જેમાં અગ્રણી સ્લેશ - પૂલ નામ આપવામાં આવ્યું છે pool તરીકે માઉન્ટ થયેલ છે /pool, ડેટા સેટ parent માં માઉન્ટ થયેલ છે /pool/parent, અને બાળ ડેટાસેટ child માં માઉન્ટ થયેલ છે /pool/parent/child. જો કે, ડેટાસેટનો સિસ્ટમ માઉન્ટ પોઈન્ટ બદલી શકાય છે.

જો આપણે સ્પષ્ટ કરીએ zfs set mountpoint=/lol pool/parent/child, પછી ડેટા સેટ pool/parent/child તરીકે સિસ્ટમ પર માઉન્ટ થયેલ છે /lol.

ડેટાસેટ્સ ઉપરાંત, આપણે વોલ્યુમ્સ (ઝવોલ્સ) નો ઉલ્લેખ કરવો જોઈએ. વોલ્યુમ લગભગ ડેટાસેટ જેટલું જ હોય ​​છે, સિવાય કે તેમાં વાસ્તવમાં ફાઇલ સિસ્ટમ હોતી નથી—તે માત્ર એક બ્લોક ઉપકરણ છે. તમે, ઉદાહરણ તરીકે, બનાવી શકો છો zvol નામ સાથે mypool/myzvol, પછી તેને ext4 ફાઇલસિસ્ટમ સાથે ફોર્મેટ કરો, અને પછી તે ફાઇલસિસ્ટમને માઉન્ટ કરો - હવે તમારી પાસે ext4 ફાઇલસિસ્ટમ છે, પરંતુ ZFS ની તમામ સુરક્ષા સુવિધાઓ સાથે! આ એક કમ્પ્યુટર પર મૂર્ખ લાગે છે, પરંતુ iSCSI ઉપકરણની નિકાસ કરતી વખતે બેકએન્ડ તરીકે વધુ અર્થપૂર્ણ બને છે.

બ્લોક્સ

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

અમે ખરેખર ખરેખર જો તમે શિફ્ટ ખૂબ ઓછી સેટ કરો છો તો અમે વિશાળ પ્રદર્શન દંડ વિશે મજાક નથી કરી રહ્યા

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

અન્યથા ઉલ્લેખિત ન હોય ત્યાં સુધી, વર્તમાન ડિફોલ્ટ રેકોર્ડ કદ 128 KiB છે. તે એક પ્રકારનું મુશ્કેલ ટ્રેડ-ઓફ છે જ્યાં પ્રદર્શન સંપૂર્ણ નથી, પરંતુ મોટાભાગના કિસ્સાઓમાં તે ભયંકર પણ નથી. Recordsize 4K થી 1M સુધી કોઈપણ મૂલ્ય પર સેટ કરી શકાય છે (અદ્યતન સેટિંગ્સ સાથે recordsize તમે હજી વધુ ઇન્સ્ટોલ કરી શકો છો, પરંતુ આ ભાગ્યે જ સારો વિચાર છે).

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

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

zvol વોલ્યુમો પાસે મિલકત નથી recordsize - તેના બદલે તેમની પાસે સમકક્ષ મિલકત છે volblocksize.

ક્ષેત્રો

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

ZFS સિસ્ટમમાં એક પ્રોપર્ટી છે જે તમને સેક્ટરનું કદ મેન્યુઅલી સેટ કરવાની મંજૂરી આપે છે. આ મિલકત ashift. કંઈક અંશે ગૂંચવણભરી રીતે, શિફ્ટ એ બેની શક્તિ છે. દાખ્લા તરીકે, ashift=9 એટલે કે 2^9 અથવા 512 બાઇટ્સનું સેક્ટરનું કદ.

ZFS ઓપરેટિંગ સિસ્ટમને દરેક બ્લોક ઉપકરણ વિશે વિગતવાર માહિતી માટે પૂછે છે જ્યારે તેને નવા vdev માં ઉમેરવામાં આવે છે, અને તે માહિતીના આધારે સૈદ્ધાંતિક રીતે આપમેળે શિફ્ટ યોગ્ય રીતે સેટ કરે છે. કમનસીબે, Windows XP સાથે સુસંગતતા જાળવવા માટે ઘણી ડ્રાઈવો તેમના સેક્ટરના કદ વિશે જૂઠું બોલે છે (જે અન્ય ક્ષેત્રના કદ સાથેની ડ્રાઈવોને સમજવામાં અસમર્થ હતી).

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

વાસ્તવિક દુનિયામાં, આવી પેનલ્ટી સેમસંગ ઇવીઓ એસએસડીને ફટકારે છે, જેના માટે ashift=13, પરંતુ આ SSD તેમના સેક્ટરના કદ વિશે જૂઠું બોલે છે, અને તેથી ડિફોલ્ટ પર સેટ છે ashift=9. જ્યાં સુધી કોઈ અનુભવી સિસ્ટમ એડમિનિસ્ટ્રેટર આ સેટિંગને બદલે, આ SSD કામ કરે છે ધીમી પરંપરાગત ચુંબકીય HDD.

સરખામણી માટે, ખૂબ મોટા કદ માટે ashift વ્યવહારીક રીતે કોઈ દંડ નથી. ત્યાં કોઈ વાસ્તવિક પ્રદર્શન દંડ નથી, અને બિનઉપયોગી જગ્યામાં વધારો અનંત છે (અથવા કમ્પ્રેશન સક્ષમ સાથે શૂન્ય). તેથી, અમે ભારપૂર્વક ભલામણ કરીએ છીએ કે તે ડ્રાઇવ્સ પણ જે 512-બાઇટ સેક્ટરનો ઉપયોગ કરે છે તે ઇન્સ્ટોલ કરો ashift=12 અથવા તો ashift=13ભવિષ્યમાં વિશ્વાસપૂર્વક જોવા માટે.

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

કૉપિ-ઑન-રાઇટ મિકેનિઝમ

જો નિયમિત ફાઇલ સિસ્ટમને ડેટા પર ફરીથી લખવાની જરૂર હોય, તો તે દરેક બ્લોક જ્યાં છે ત્યાં બદલે છે

કૉપિ-ઑન-રાઇટ ફાઇલ સિસ્ટમ બ્લોકનું નવું સંસ્કરણ લખે છે અને પછી જૂના સંસ્કરણને અનલૉક કરે છે

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

હવે આપણે કોપી-ઓન-રાઈટ સ્નેપશોટ કેવી રીતે કાર્ય કરે છે તેનો સારો વિચાર મેળવી શકીએ છીએ - દરેક બ્લોક બહુવિધ સ્નેપશોટનો હોઈ શકે છે અને જ્યાં સુધી તમામ સંકળાયેલ સ્નેપશોટનો નાશ ન થાય ત્યાં સુધી તે ચાલુ રહેશે.

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

તેના બદલે, કૉપિ-ઑન-રાઇટ ફાઇલ સિસ્ટમ સુધારેલા બ્લોકનું નવું સંસ્કરણ લખે છે, અને પછી જૂના બ્લોકને અનલિંક કરવા અને તમે હમણાં જ લખેલા નવા બ્લોક સાથે તેને સાંકળવા માટે ફાઇલના મેટાડેટાને અપડેટ કરે છે.

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

ZFS માં કૉપિ-ઑન-રાઇટ માત્ર ફાઇલ સિસ્ટમ સ્તરે જ નહીં, પણ ડિસ્ક મેનેજમેન્ટ સ્તરે પણ થાય છે. આનો અર્થ એ છે કે ZFS રેકોર્ડમાં વ્હાઇટસ્પેસ માટે સંવેદનશીલ નથી (RAID માં છિદ્ર) - એક ઘટના જ્યારે રીબૂટ પછી એરેને નુકસાન સાથે, સિસ્ટમ ક્રેશ થાય તે પહેલાં સ્ટ્રીપ માત્ર આંશિક રીતે રેકોર્ડ કરવામાં આવી હતી. અહીં પટ્ટા પરમાણુ રીતે લખાયેલ છે, vdev હંમેશા ક્રમિક છે, અને બોબ તમારા કાકા છે.

ZIL: ZFS ઉદ્દેશ્ય લોગ

ZFS સિસ્ટમ સિંક્રનસ રાઇટ્સને ખાસ રીતે વર્તે છે - તે અસ્થાયી રૂપે પરંતુ તરત જ તેમને અસુમેળ લખાણો સાથે કાયમી ધોરણે લખતા પહેલા ZIL માં સંગ્રહિત કરે છે.

સામાન્ય રીતે, ZIL ને લખવામાં આવેલ ડેટા ફરી ક્યારેય વાંચવામાં આવતો નથી. પરંતુ તે સિસ્ટમ ક્રેશ પછી શક્ય છે

SLOG, અથવા સેકન્ડરી LOG ઉપકરણ, માત્ર એક વિશિષ્ટ છે - અને પ્રાધાન્યમાં ખૂબ જ ઝડપી - vdev, જ્યાં ZIL ને મુખ્ય સ્ટોરેજથી અલગથી સંગ્રહિત કરી શકાય છે.

ક્રેશ પછી, ZIL માંનો તમામ ગંદા ડેટા ફરીથી ચલાવવામાં આવે છે - આ કિસ્સામાં, ZIL SLOG પર છે, તેથી તે ત્યાંથી ફરીથી ચલાવવામાં આવે છે

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

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

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

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

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

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

પૂલમાં LOG સાથે vdev ઉમેરવાનું કામ કરતું નથી નથી કરી શકતા અસુમેળ લેખન કાર્યક્ષમતામાં સુધારો કરો - પછી ભલે તમે બધાને ZIL ને લખવા દબાણ કરો zfs set sync=always, તેઓ હજુ પણ TXG માં મુખ્ય સ્ટોરેજ સાથે તે જ રીતે અને તે જ ગતિએ લિંક કરવામાં આવશે જે રીતે લોગ વગર. સિંક્રનસ રાઇટ્સની વિલંબતા (કારણ કે ઝડપી લોગ કામગીરીને ઝડપી બનાવે છે) એ એકમાત્ર સીધો પ્રભાવ સુધારણા છે. sync).

જો કે, એવા વાતાવરણમાં કે જેને પહેલાથી જ ઘણાં સિંક્રનસ રાઇટ્સની જરૂર હોય છે, vdev LOG અપ્રત્યક્ષ રીતે અસુમેળ લખાણો અને બિન-કેશ્ડ રીડને ઝડપી બનાવી શકે છે. ZIL એન્ટ્રીઓને અલગ vdev LOG પર ઑફલોડ કરવાનો અર્થ એ છે કે પ્રાથમિક સ્ટોરેજ પર IOPS માટે ઓછી તકરાર છે, જે અમુક અંશે બધા વાંચન અને લેખનનું પ્રદર્શન સુધારે છે.

સ્નેપશોટ

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

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

પ્રતિકૃતિ

2015 માં મારી સ્ટીમ લાઇબ્રેરી 158 GiB હતી અને તેમાં 126 ફાઇલો શામેલ હતી. આ rsync માટે શ્રેષ્ઠ પરિસ્થિતિની ખૂબ નજીક છે - નેટવર્ક પર ZFS પ્રતિકૃતિ "માત્ર" 927% ઝડપી હતી.

સમાન નેટવર્ક પર, એક જ 40GB Windows 7 વર્ચ્યુઅલ મશીન ઇમેજ ફાઇલની નકલ કરવી એ સંપૂર્ણપણે અલગ વાર્તા છે. ZFS પ્રતિકૃતિ rsync કરતાં 289 ગણી ઝડપી છે - અથવા "માત્ર" 161 ગણી ઝડપી છે જો તમે --inplace સાથે rsync ને કૉલ કરવા માટે પૂરતા સમજદાર છો.

જ્યારે VM ઇમેજને માપવામાં આવે છે, ત્યારે rsync તેની સાથે સ્કેલની સમસ્યા કરે છે. 1,9 આધુનિક VM ઈમેજ માટે TiB એટલું મોટું નથી - પરંતુ તે એટલું મોટું છે કે ZFS પ્રતિકૃતિ rsync કરતાં 1148 ગણી ઝડપી છે, rsync ની --inplace દલીલ સાથે પણ

એકવાર તમે સમજો કે સ્નેપશોટ કેવી રીતે કાર્ય કરે છે, તે પ્રતિકૃતિના સારને સમજવું સરળ બનશે. કારણ કે સ્નેપશોટ એ ફક્ત રેકોર્ડ પોઇન્ટરનું વૃક્ષ છે, જો આપણે કરીએ તો તે તેને અનુસરે છે zfs send સ્નેપશોટ, પછી અમે આ વૃક્ષ અને તેની સાથે સંકળાયેલા તમામ રેકોર્ડ મોકલીએ છીએ. જ્યારે અમે આ મોકલીએ છીએ zfs send в zfs receive લક્ષ્ય પર, તે બ્લોકની વાસ્તવિક સામગ્રી અને પોઇન્ટરનું વૃક્ષ બંને લખે છે જે લક્ષ્ય ડેટાસેટના બ્લોકનો સંદર્ભ આપે છે.

વસ્તુઓ બીજા પર વધુ રસપ્રદ બને છે zfs send. અમારી પાસે હવે બે સિસ્ટમો છે, જેમાં દરેક છે poolname/datasetname@1, અને તમે એક નવો સ્નેપશોટ લો poolname/datasetname@2. તેથી, મૂળ પૂલમાં તમારી પાસે છે datasetname@1 и datasetname@2, અને લક્ષ્ય પૂલમાં અત્યાર સુધી માત્ર પ્રથમ સ્નેપશોટ datasetname@1.

કારણ કે અમારી પાસે સ્ત્રોત અને લક્ષ્ય વચ્ચે સામાન્ય સ્નેપશોટ છે datasetname@1, આપણે તે કરી શકીએ વધારો zfs send તેના ઉપર જ્યારે અમે તંત્રને કહીએ છીએ zfs send -i poolname/datasetname@1 poolname/datasetname@2, તે બે નિર્દેશક વૃક્ષોની તુલના કરે છે. કોઈપણ નિર્દેશકો કે જે ફક્ત માં જ અસ્તિત્વ ધરાવે છે @2, દેખીતી રીતે નવા બ્લોક્સનો સંદર્ભ લો - તેથી અમને આ બ્લોક્સની સામગ્રીની જરૂર છે.

રિમોટ સિસ્ટમ પર, ઇન્ક્રીમેન્ટલ પર પ્રક્રિયા કરી રહી છે send એટલું જ સરળ. પ્રથમ અમે સ્ટ્રીમમાં સમાવિષ્ટ તમામ નવી એન્ટ્રીઓ લખીએ છીએ send, અને પછી તે બ્લોક્સમાં પોઇન્ટર ઉમેરો. વોઇલા, અમારી પાસે છે @2 નવી સિસ્ટમમાં!

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

બિલ્ટ-ઇન કમ્પ્રેશન

કૉપિ-ઑન-રાઇટ પદ્ધતિ ઇનલાઇન કમ્પ્રેશન સિસ્ટમને પણ સરળ બનાવે છે. પરંપરાગત ફાઇલ સિસ્ટમમાં, સંકોચન સમસ્યારૂપ છે - બંને જૂના સંસ્કરણ અને સુધારેલા ડેટાનું નવું સંસ્કરણ સમાન જગ્યામાં રહે છે.

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

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

મૂળ ZFS કમ્પ્રેશન ડિફૉલ્ટ રૂપે અક્ષમ છે, અને સિસ્ટમ પ્લગેબલ અલ્ગોરિધમ્સ ઓફર કરે છે-હાલમાં LZ4, gzip (1-9), LZJB અને ZLE.

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

અમે લગભગ તમામ ઉપયોગના કેસો માટે LZ4 કમ્પ્રેશનની ભલામણ કરીએ છીએ; અસ્પષ્ટ ડેટાનો સામનો કરતી વખતે પ્રદર્શન દંડ ખૂબ જ નાનો છે, અને વૃદ્ધિ લાક્ષણિક ડેટા માટે કામગીરી નોંધપાત્ર છે. વિન્ડોઝ ઓપરેટિંગ સિસ્ટમના નવા ઇન્સ્ટોલેશન માટે વર્ચ્યુઅલ મશીન ઇમેજની નકલ કરવી (નવી રીતે ઇન્સ્ટોલ કરેલ OS, હજી અંદર કોઈ ડેટા નથી) compression=lz4 કરતાં 27% વધુ ઝડપથી પસાર થયું compression=noneમાં 2015 માં આ પરીક્ષણ.

ARC - અનુકૂલનશીલ રિપ્લેસમેન્ટ કેશ

ZFS એ એકમાત્ર આધુનિક ફાઇલ સિસ્ટમ છે જેના વિશે આપણે જાણીએ છીએ કે જે RAM માં તાજેતરમાં વાંચેલા બ્લોક્સની નકલોને સંગ્રહિત કરવા માટે ઓપરેટિંગ સિસ્ટમના પેજ કેશ પર આધાર રાખવાને બદલે તેની પોતાની રીડ કેશીંગ મિકેનિઝમનો ઉપયોગ કરે છે.

જોકે મૂળ કેશ તેની સમસ્યાઓ વિના નથી - ZFS કર્નલ જેટલી ઝડપથી નવી મેમરી ફાળવણી વિનંતીઓનો જવાબ આપી શકતું નથી, તેથી નવો કૉલ malloc() મેમરી ફાળવણી નિષ્ફળ થઈ શકે છે જો તેને હાલમાં ARC દ્વારા કબજે કરેલ RAMની જરૂર હોય. પરંતુ તમારી પોતાની કેશનો ઉપયોગ કરવાના સારા કારણો છે, ઓછામાં ઓછા હમણાં માટે.

MacOS, Windows, Linux અને BSD સહિતની તમામ જાણીતી આધુનિક ઓપરેટિંગ સિસ્ટમ્સ, પેજ કેશને અમલમાં મૂકવા માટે LRU (Least Recently Used) અલ્ગોરિધમનો ઉપયોગ કરે છે. આ એક આદિમ અલ્ગોરિધમ છે જે દરેક વાંચ્યા પછી કેશ્ડ બ્લોકને "કતારમાં ઉપર" ધકેલે છે, અને નવા કેશ મિસ (બ્લોક કે જે ડિસ્કમાંથી વાંચવા જોઈએ, કેશમાંથી નહીં) ઉમેરવા માટે જરૂર મુજબ બ્લોક્સને "કતારની નીચે" દબાણ કરે છે. ઉપર

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

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

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

નિષ્કર્ષ

ZFS ના મૂળભૂત સિમેન્ટિક્સ શીખ્યા પછી - કેવી રીતે કૉપિ-ઑન-રાઇટ કામ કરે છે, તેમજ સ્ટોરેજ પૂલ, વર્ચ્યુઅલ ઉપકરણો, બ્લોક્સ, સેક્ટરો અને ફાઇલો વચ્ચેના સંબંધો - અમે વાસ્તવિક સંખ્યાઓ સાથે વાસ્તવિક-વિશ્વના પ્રદર્શનની ચર્ચા કરવા તૈયાર છીએ.

આગળના ભાગમાં, અમે મિરર કરેલ vdev અને RAIDz પૂલનું વાસ્તવિક પ્રદર્શન જોઈશું, એકબીજાની સરખામણીમાં, અને અમે તપાસેલ પરંપરાગત Linux કર્નલ RAID ટોપોલોજીની તુલનામાં પણ. અગાઉ.

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

સોર્સ: www.habr.com