मैं यह कैसे पता लगा सकता हूं कि डिस्क (ब्लॉक नंबर) पर कोई फ़ाइल भौतिक रूप से कहाँ स्थित है?

Question

यह एक अस्पष्ट प्रश्न है, मुझे पता है। मैं लिनक्स बॉक्स पर कुछ डिस्क के कुछ प्रदर्शन परीक्षण करने की कोशिश कर रहा हूं। मुझे कुछ असंगत परिणाम मिल रहे हैं, एक ही डिस्क पर एक ही परीक्षण चल रहा है। मुझे पता है कि डिस्क का अलग-अलग प्रदर्शन है, जिसके आधार पर डिस्क के किस हिस्से तक पहुँचा जा रहा है। विशेष रूप से, डिस्क के बाहर की ओर पढ़ता और लिखता है, डिस्क के अंदर के हिस्से को पढ़ने और लिखने की तुलना में बहुत अधिक थ्रूपुट होता है, जो निकट-निरंतर डेटा घनत्व और निरंतर घूर्णी गति के कारण होता है।

मैं यह देखना चाहता हूं कि क्या मेरी विसंगतियों को थ्रूपुट में इस ज्यामिति-प्रेरित विचरण के लिए जिम्मेदार ठहराया जा सकता है। क्या यह संभव है, मौजूदा साधनों का उपयोग करके, यह पता लगाने के लिए कि डिस्क पर फ़ाइल कहाँ रखी गई है?

यदि नहीं, तो मुझे लगता है कि मैं सीधे फाइल की तलाश करने, पढ़ने, और लिखने के लिए कुछ लिख सकता हूं, फाइल सिस्टम को बायपास (और नष्ट) कर रहा हूं, लेकिन मैं इससे बचने की उम्मीद कर रहा हूं। मैं वर्तमान में 3.0 कर्नेल (आर्क लिनक्स, अगर यह मायने रखता है) पर ext4 का उपयोग कर रहा हूं, लेकिन मैं अन्य फाइल सिस्टम के लिए तकनीकों में भी दिलचस्पी रखता हूं।

Comments

कौन कहता है कि फाइलें एक स्थान पर हैं? यदि वे खंडित हो जाते हैं (जो वे आमतौर पर करते हैं) तो वे सभी खत्म हो सकते हैं।

— सेरेक्स

पूर्ण रूप से। लेकिन वे अभी भी कुछ जगह हैं :-) और मेरे विशेष मामले में, एक नई बनाई गई फाइल सिस्टम के लिए फाइलें लिखना, वे काफी हद तक (अधिकांशतः) राष्ट्रव्यापी हो सकते हैं।

— रिक कोशी

आप ऐसा नहीं कर सकते। आपके द्वारा प्राप्त की जा सकने वाली सर्वश्रेष्ठ फ़ाइलों की LBA ब्लॉक संख्या है, जो आवश्यक रूप से निर्दिष्ट भौतिक स्थानों के अनुरूप नहीं है (कम से कम एक तरह से जिसे आप निर्धारित कर सकते हैं, क्योंकि ड्राइव इस मैपिंग को प्रकाशित नहीं करते हैं)। अन्य चीजें भी हैं, उदाहरण के लिए, ब्लॉक 3-5 को लगातार क्रमांकित किया जा सकता है, लेकिन 4 को ड्राइव पर एक पूरी तरह से अलग स्थान पर पुनः लाया जा सकता है क्योंकि 4 पर मूल क्षेत्र को शारीरिक रूप से क्षतिग्रस्त किया गया था, आदि की जानकारी आपको नहीं मिल सकती है। जब तक ड्राइव निर्माता आपको विस्तृत पता चश्मा देने के लिए तैयार नहीं है, तब तक आप देख रहे हैं।

— जेसन सी

Answer 1

आप इसके लिए उपयोग कर सकते हैं debugfs:

debugfs -R "stat ~/myfile" /dev/hda1

तदनुसार हार्ड / विभाजन ड्राइव को बदलें और सुनिश्चित करें कि ड्राइव अनमाउंट है। आपको उपयोग किए गए सभी ब्लॉकों के साथ एक सूची मिलेगी:

BLOCKS:
(0):1643532
TOTAL: 1

Comments

यह एकदम सही है, धन्यवाद। मुझे यकीन नहीं है कि आपने यह सुनिश्चित करने के लिए क्यों कहा कि ड्राइव अनमाउंट है, हालांकि। मैनुअल पेज के अनुसार, डिबगफॉफ डिफ़ॉल्ट रूप से रीड-ओनली मोड में खुलता है, इसलिए यह कमांड एक सक्रिय फाइलसिस्टम पर भी पूरी तरह से सुरक्षित होना चाहिए। यह संदिग्ध परिणाम प्रदान कर सकता है यदि क्वैरिड फ़ाइल को समय पर सक्रिय रूप से बदला जा रहा है, लेकिन कोई अन्य समस्या नहीं होनी चाहिए। क्या मुझे कुछ याद आया?

— रिक कोशी

नहीं, आप सही हैं। यह एक 'सबसे अच्छा अभ्यास' का अधिक है तो एक चाहिए। यदि आप इसे एक सक्रिय फाइलसिस्टम पर कर रहे हैं, तो फाइलें आदि बदल सकती हैं

— बार्ट दे वोस

LBA ब्लॉक नंबर आपको यह नहीं बताता है कि फ़ाइल डिस्क पर भौतिक रूप से कहाँ स्थित है। इन दिनों एलबीए से भौतिक स्थान में रूपांतरण आम तौर पर संभव नहीं है, आधुनिक ड्राइव की भौतिक ज्यामिति की जटिलता के कारण, पीछे-पीछे आने वाले सेक्टरों की वास्तविकताओं, आदि आमतौर पर यह बोलते हुए कि आमतौर पर डिस्क आधारित मीडिया कम एलबीए के लिए एक सुरक्षित शर्त है ड्राइव के बाहर की ओर हैं, लेकिन ऐसा सिर्फ इसलिए है क्योंकि लेआउट अतीत में विशिष्ट रहा है, सीएचएस संबोधित दिनों में वापस। आधुनिक ड्राइव वास्तविक CHS ज्यामिति को भी प्रकाशित नहीं करते हैं, क्योंकि वे नहीं कर सकते हैं।

— जेसन सी

वसा फी सिस्टम के बारे में क्या?

— दशमी तिथि

Answer 2

आप FIBMAP ioctl का उपयोग कर सकते हैं , जैसा कि यहाँ पर उदाहरण दिया गया है , या hdparm का उपयोग कर :

/ $ sudo /sbin/hdparm --fibmap /etc/X11/xorg.conf

/etc/X11/xorg.conf:
 filesystem blocksize 4096, begins at LBA 0; assuming 512 byte sectors.
 byte_offset  begin_LBA    end_LBA    sectors
           0    1579088    1579095          8

Comments

दुर्भाग्य से, स्टेट के द्वारा कुछ भी आउटपुट मेरी आवश्यकता की जानकारी नहीं है। बाइट्स और ब्लॉक्स में आकार, इनकोड संख्या, अनुमतियां ... इनमें से कोई भी प्रतिबिंबित नहीं करता है कि किस ब्लॉक में फ़ाइल का डेटा है। एक उदाहरण के रूप में, मेरी परीक्षण फाइलें (जो सभी समान आकार हैं) सभी बिल्कुल एक ही डेटा दिखाती हैं, सिवाय इनोड नंबर और एक्सेस / मोड्यूल समय के।

— रिक कोशी

हाँ, आप सही हैं, मुझे क्षमा करें, मैंने ठीक से नहीं पढ़ा। मैंने अपने उत्तर को और अधिक उपयुक्त stg में बदल दिया।

— फ्रेंकोइस जी

hdparm वास्तव में मुझे वही देता है जो मुझे चाहिए, और डिबगफ़ेट्स की तुलना में कुछ अधिक पठनीय प्रारूप में। मुझे इसे ढूंढना था, हालाँकि, क्योंकि यह (आर्क लिनक्स पर) डिफ़ॉल्ट रूप से स्थापित नहीं है। debugfs e2fsprogs (वही पैकेज जो हमें mkfs और fsck देता है) का हिस्सा है, इसलिए डिफ़ॉल्ट रूप से स्थापित होता है।

— रिक कोशी

LBA आपको यह नहीं बताता कि फ़ाइल भौतिक रूप से ड्राइव पर कहाँ स्थित है। एलबीए की वास्तविक भौतिक मानचित्रण के बारे में जानकारी प्राप्त करना संभव नहीं है।

— जेसन सी

मुझे यह चर्बी पर मिलता है:HDIO_GETGEO failed: Inappropriate ioctl for device

— १४

Answer 3

यह धागा आपको ext4 फ़ाइल प्लेसमेंट एल्गोरिथ्म में कुछ जानकारी दे सकता है।

debugfsएक bmapफ़ंक्शन है, जो आपको इच्छित डेटा देने के लिए लगता है। आपको इसे एक फ़ाइल के लगातार ब्लॉक देने और भौतिक ब्लॉक संख्या प्राप्त करने में सक्षम होना चाहिए।

Comments

Ext4 फ़ाइल प्लेसमेंट के बारे में थ्रेड के लिए पॉइंटर के लिए धन्यवाद। यह ज्ञानवर्धक था। :-)

— रिक कोशी

LBA आपको यह नहीं बताता कि फ़ाइल भौतिक रूप से ड्राइव पर कहाँ स्थित है। एलबीए की वास्तविक भौतिक मानचित्रण के बारे में जानकारी प्राप्त करना संभव नहीं है।

— जेसन सी

Answer 4

सवाल बल्कि पुराना है, लेकिन एक और जवाब है जो Google पर इसे खोजने वालों के लिए उपयोगी हो सकता है: filefrag(डेबियन में यह पैकेज के अंदर है e2fsprogs)।

# filefrag -eX /usr/bin/aptitude
Filesystem type is: ef53
File size of /usr/bin/aptitude is 4261400 (1041 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..     1fa:    15bd805..   15bd9ff:    1fb:            
   1:      1fb..     3f2:    15c6608..   15c67ff:    1f8:    15bda00:
   2:      3f3..     410:    15c8680..   15c869d:     1e:    15c6800: last,eof
/usr/bin/aptitude: 3 extents found

इसका लाभ यह है कि यह अन्य फाइल सिस्टम के लिए भी काम करता है (मैंने इसे यूडीएफ के लिए उपयोग किया है), जो कि यहां वर्णित अन्य उपकरणों द्वारा समर्थित नहीं दिखाई देते हैं।

आउटपुट में प्रस्तुत ऑफसेट दूसरी पंक्ति (4096 यहाँ) में लिखे गए ब्लॉक आकार के कई में होना चाहिए। सावधान रहें कि लॉजिकल ऑफ़सेट्स सन्निहित नहीं हो सकते, क्योंकि फाइल में छेद हो सकते हैं (फाइल सिस्टम द्वारा समर्थित)।