Linux માં વર્ચ્યુઅલ ફાઇલ સિસ્ટમ્સ: શા માટે તેઓની જરૂર છે અને તેઓ કેવી રીતે કાર્ય કરે છે? ભાગ 2

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

eBPF અને bcc ટૂલ્સનો ઉપયોગ કરીને VFS ને કેવી રીતે મોનિટર કરવું

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

સદભાગ્યે, સાધનોની મદદથી eBPF નો ઉપયોગ કરવાનું શરૂ કરવું એકદમ સરળ છે BCC, જે સામાન્ય વિતરણમાંથી પેકેજ તરીકે ઉપલબ્ધ છે Linux અને વિગતવાર દસ્તાવેજીકરણ બર્નાર્ડ ગ્રેગ. સાધનો bcc પાયથોન સ્ક્રિપ્ટો સી કોડના નાના દાખલાઓ સાથે છે, જેનો અર્થ છે કે બંને ભાષાઓથી પરિચિત કોઈપણ તેને સરળતાથી સુધારી શકે છે. IN bcc/tools ત્યાં 80 પાયથોન સ્ક્રિપ્ટો છે, જેનો અર્થ છે કે મોટાભાગે વિકાસકર્તા અથવા સિસ્ટમ એડમિનિસ્ટ્રેટર સમસ્યાને ઉકેલવા માટે યોગ્ય કંઈક પસંદ કરવામાં સક્ષમ હશે.
ચાલતી સિસ્ટમ પર VFS શું કામ કરે છે તેનો ઓછામાં ઓછો સુપરફિસિયલ વિચાર મેળવવા માટે, પ્રયાસ કરો vfscount અથવા vfsstat. આ બતાવશે, ચાલો કહીએ, કે ડઝનેક કૉલ્સ vfs_open() અને "તેના મિત્રો" શાબ્દિક રીતે દર સેકન્ડે થાય છે.

vfsstat.py સી કોડ ઇન્સર્ટ સાથેની પાયથોન સ્ક્રિપ્ટ છે જે ફક્ત VFS ફંક્શન કૉલ્સની ગણતરી કરે છે.

ચાલો એક વધુ તુચ્છ ઉદાહરણ આપીએ અને જોઈએ કે જ્યારે આપણે કમ્પ્યુટરમાં USB ફ્લેશ ડ્રાઇવ દાખલ કરીએ અને સિસ્ટમ તેને શોધી કાઢે ત્યારે શું થાય છે.

eBPF નો ઉપયોગ કરીને તમે જોઈ શકો છો કે શું થઈ રહ્યું છે /sysજ્યારે USB ફ્લેશ ડ્રાઇવ દાખલ કરવામાં આવે છે. એક સરળ અને જટિલ ઉદાહરણ અહીં બતાવવામાં આવ્યું છે.

ઉપર બતાવેલ ઉદાહરણમાં, bcc સાધન trace.py જ્યારે આદેશ ચલાવવામાં આવે ત્યારે સંદેશ છાપે છે sysfs_create_files(). તે આપણે જોઈએ છીએ sysfs_create_files() નો ઉપયોગ કરીને લોન્ચ કરવામાં આવ્યો હતો kworker એ હકીકતના જવાબમાં સ્ટ્રીમ કરો કે ફ્લેશ ડ્રાઇવ શામેલ કરવામાં આવી હતી, પરંતુ કઈ ફાઇલ બનાવવામાં આવી હતી? બીજું ઉદાહરણ eBPF ની શક્તિ દર્શાવે છે. અહીં trace.py કર્નલ બેકટ્રેસ (-K વિકલ્પ) અને જે ફાઈલ બનાવવામાં આવી હતી તેનું નામ છાપે છે sysfs_create_files(). સિંગલ સ્ટેટમેન્ટ નિવેશ એ C કોડ છે જેમાં પાયથોન સ્ક્રિપ્ટ દ્વારા પૂરી પાડવામાં આવેલ સરળતાથી ઓળખી શકાય તેવી ફોર્મેટ સ્ટ્રિંગ શામેલ છે જે LLVM ચલાવે છે. જસ્ટ-ઇન-ટાઇમ કમ્પાઇલર. તે આ લાઇનને કમ્પાઇલ કરે છે અને કર્નલની અંદર વર્ચ્યુઅલ મશીનમાં એક્ઝિક્યુટ કરે છે. સંપૂર્ણ કાર્ય સહી sysfs_create_files () બીજા આદેશમાં પુનઃઉત્પાદન કરવું આવશ્યક છે જેથી ફોર્મેટ સ્ટ્રિંગ પરિમાણોમાંથી એકનો સંદર્ભ લઈ શકે. C કોડના આ ભાગમાં ભૂલો C કમ્પાઇલરમાંથી ઓળખી શકાય તેવી ભૂલોમાં પરિણમે છે. ઉદાહરણ તરીકે, જો -l પરિમાણ અવગણવામાં આવે છે, તો તમે "BPF ટેક્સ્ટ કમ્પાઇલ કરવામાં નિષ્ફળ" જોશો. વિકાસકર્તાઓ કે જેઓ C અને Python થી પરિચિત છે તેઓને સાધનો મળશે bcc વિસ્તરણ અને બદલવા માટે સરળ.

જ્યારે USB ડ્રાઇવ દાખલ કરવામાં આવે છે, ત્યારે કર્નલ બેકટ્રેસ બતાવશે કે PID 7711 એક થ્રેડ છે. kworkerજેણે ફાઈલ બનાવી «events» в sysfs. તદનુસાર, તરફથી કોલ sysfs_remove_files() બતાવશે કે ડ્રાઇવને દૂર કરવાથી ફાઇલ કાઢી નાખવામાં આવી છે events, જે સંદર્ભ ગણતરીના સામાન્ય ખ્યાલને અનુરૂપ છે. તે જ સમયે, જોવાનું sysfs_create_link () eBPF સાથે USB ડ્રાઇવ દાખલ કરતી વખતે બતાવશે કે ઓછામાં ઓછી 48 સાંકેતિક લિંક્સ બનાવવામાં આવી છે.

તો ઘટનાઓ ફાઈલનો મુદ્દો શું છે? ઉપયોગ cscope શોધ માટે __ઉપકરણ_ઉમેરો_ડિસ્ક(), તે શું કારણ બને છે તે દર્શાવે છે disk_add_events (), અને ક્યાં તો "media_change", અથવા "eject_request" ઇવેન્ટ ફાઇલમાં રેકોર્ડ કરી શકાય છે. અહીં કર્નલ બ્લોક લેયર યુઝરસ્પેસને જાણ કરે છે કે "ડિસ્ક" દેખાય છે અને બહાર નીકળી ગઈ છે. સ્ત્રોતમાંથી વસ્તુઓ કેવી રીતે કામ કરે છે તે શોધવાના પ્રયાસની સરખામણીમાં USB ડ્રાઇવ દાખલ કરીને આ સંશોધન પદ્ધતિ કેટલી માહિતીપ્રદ છે તેની નોંધ લો.

ફક્ત વાંચવા માટે રૂટ ફાઇલ સિસ્ટમ એમ્બેડેડ ઉપકરણોને સક્ષમ કરે છે

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

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

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

બનાવટ rootfs ફક્ત વાંચવા માટે એમ્બેડેડ વિકાસકર્તાઓ માટે કેટલાક વધારાના પ્રયત્નોની જરૂર છે, અને આ તે છે જ્યાં VFS ચિત્રમાં આવે છે. Linux માટે જરૂરી છે કે ફાઇલો અંદર હોય /var લખી શકાય તેવા હતા, અને વધુમાં, ઘણી લોકપ્રિય એપ્લિકેશનો કે જે એમ્બેડેડ સિસ્ટમ ચલાવે છે તે રૂપરેખાંકન બનાવવાનો પ્રયાસ કરશે. dot-files в $HOME. હોમ ડિરેક્ટરીમાં રૂપરેખાંકન ફાઇલો માટેનો એક ઉકેલ સામાન્ય રીતે તેને પૂર્વ-જનરેટ અને બિલ્ડ કરવાનો છે rootfs. માટે /var એક સંભવિત અભિગમ તેને અલગ લખી શકાય તેવા પાર્ટીશન પર માઉન્ટ કરવાનો છે, જ્યારે / ફક્ત વાંચવા માટે માઉન્ટ થયેલ. બીજો લોકપ્રિય વિકલ્પ એ છે કે બાઇન્ડ અથવા ઓવરલે માઉન્ટ્સનો ઉપયોગ કરવો.

લિંકેબલ અને સ્ટેકેબલ માઉન્ટ, કન્ટેનર દ્વારા તેમનો ઉપયોગ

આદેશ અમલ man mount બાંધી શકાય તેવા અને ઓવરલેયેબલ માઉન્ટો વિશે શીખવાની શ્રેષ્ઠ રીત છે, જે વિકાસકર્તાઓ અને સિસ્ટમ સંચાલકોને એક પાથમાં ફાઇલ સિસ્ટમ બનાવવાની ક્ષમતા આપે છે અને પછી તેને બીજા પાથમાં એપ્લીકેશન્સ માટે એક્સપોઝ કરે છે. એમ્બેડેડ સિસ્ટમ્સ માટે, આનો અર્થ છે ફાઇલોને સ્ટોર કરવાની ક્ષમતા /var ફક્ત વાંચવા માટે ફ્લેશ ડ્રાઇવ પર, પરંતુ ઓવરલે અથવા લિંક કરી શકાય તેવા માઉન્ટ પાથથી tmpfs в /var લોડ કરતી વખતે, તે એપ્લિકેશનોને ત્યાં નોંધો લખવાની મંજૂરી આપશે (સ્ક્રોલ કરો). આગલી વખતે જ્યારે તમે ફેરફારોને ચાલુ કરો /var ખોવાઈ જશે. ઓવરલે માઉન્ટ વચ્ચેનું જોડાણ બનાવે છે tmpfs અને અંતર્ગત ફાઇલ સિસ્ટમ અને તમને વર્તમાન ફાઇલોમાં દેખીતા ફેરફારો કરવાની મંજૂરી આપે છે ro-tootf જ્યારે બાંધવા યોગ્ય માઉન્ટ નવાને ખાલી કરી શકે છે tmpfs માં લખી શકાય તેવા ફોલ્ડર્સ દેખાય છે ro-rootfs માર્ગો જ્યારે overlayfs આ સાચો છે (proper) ફાઇલ સિસ્ટમ પ્રકાર, બાઇન્ડેબલ માઉન્ટ અમલમાં મૂકવામાં આવે છે VFS નેમસ્પેસ.

ઓવરલે અને લિંકેબલ માઉન્ટના વર્ણનના આધારે, કોઈને આશ્ચર્ય થતું નથી Linux કન્ટેનર તેઓ સક્રિયપણે ઉપયોગમાં લેવાય છે. ચાલો જોઈએ જ્યારે આપણે ઉપયોગ કરીએ ત્યારે શું થાય છે systemd-nspawn સાધનનો ઉપયોગ કરીને કન્ટેનર ચલાવવા માટે mountsnoop થી bcc.

પડકાર system-nspawn ચાલતી વખતે કન્ટેનર શરૂ કરે છે mountsnoop.py.

ચાલો જોઈએ શું થયું:

લોંચ mountsnoop જ્યારે કન્ટેનર "બૂટીંગ" કરે છે તે બતાવે છે કે કન્ટેનરનો રનટાઈમ માઉન્ટ સાથે જોડાયેલા હોવા પર ખૂબ આધાર રાખે છે (માત્ર લાંબા આઉટપુટની શરૂઆત બતાવવામાં આવે છે).

તે systemd-nspawn માં પસંદ કરેલી ફાઇલો પ્રદાન કરે છે procfs и sysfs તેના પાથ તરીકે કન્ટેનરને હોસ્ટ કરો rootfs. ઉપરાંત MS_BIND ફ્લેગ કે જે બાઈન્ડીંગ માઉન્ટને સેટ કરે છે, માઉન્ટ પરના કેટલાક અન્ય ફ્લેગ હોસ્ટ અને કન્ટેનર નેમસ્પેસના ફેરફારો વચ્ચેના સંબંધને વ્યાખ્યાયિત કરે છે. ઉદાહરણ તરીકે, લિંક થયેલ માઉન્ટ ક્યાં તો ફેરફારોને અવગણી શકે છે /proc и /sys કન્ટેનરમાં, અથવા કૉલના આધારે તેમને છુપાવો.

નિષ્કર્ષ

લિનક્સના આંતરિક કાર્યને સમજવું એક અશક્ય કાર્ય જેવું લાગે છે, કારણ કે કર્નલ પોતે જ મોટા પ્રમાણમાં કોડ ધરાવે છે, જે સી લાઇબ્રેરીઓમાં લિનક્સ યુઝર સ્પેસ એપ્લીકેશન અને સિસ્ટમ કોલ ઇન્ટરફેસને બાજુ પર રાખીને glibc. પ્રગતિ કરવાની એક રીત એ છે કે એક કર્નલ સબસિસ્ટમનો સોર્સ કોડ વાંચવો, જેમાં સિસ્ટમ કોલ્સ અને યુઝર-સ્પેસ હેડરો તેમજ મુખ્ય આંતરિક કર્નલ ઇન્ટરફેસ, જેમ કે ટેબલને સમજવા પર ભાર મૂકવામાં આવે છે. file_operations. ફાઇલ ઑપરેશન્સ "બધું જ ફાઇલ છે" સિદ્ધાંત પ્રદાન કરે છે, જે તેમને મેનેજ કરવા માટે ખાસ કરીને આનંદપ્રદ બનાવે છે. ટોચના સ્તરની ડિરેક્ટરીમાં C કર્નલ સ્ત્રોત ફાઇલો fs/ વર્ચ્યુઅલ ફાઇલ સિસ્ટમ્સનું અમલીકરણ રજૂ કરે છે, જે રેપર લેયર છે જે લોકપ્રિય ફાઇલ સિસ્ટમ્સ અને સ્ટોરેજ ઉપકરણો વચ્ચે વ્યાપક અને પ્રમાણમાં સરળ સુસંગતતા પ્રદાન કરે છે. Linux નેમસ્પેસ દ્વારા લિંક અને ઓવરલે માઉન્ટિંગ એ VFS નો જાદુ છે જે ફક્ત વાંચવા માટેના કન્ટેનર અને રૂટ ફાઇલસિસ્ટમ બનાવવાનું શક્ય બનાવે છે. સોર્સ કોડ, eBPF કોર ટૂલ અને તેના ઇન્ટરફેસની પરીક્ષા સાથે સંયુક્ત bcc
કોર એક્સપ્લોરેશન પહેલા કરતા વધુ સરળ બનાવે છે.

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

પ્રથમ ભાગ.

સોર્સ: www.habr.com