दिए गए फ़ाइल के लिए एलवीएम विस्तार संख्या निर्धारित करना


9

मैं वर्तमान में एक गैर-काम से संबंधित गृहकार्य में व्यस्त हूं। मेरे पास एक ext4 फाइलसिस्टम है जो लॉजिकल वॉल्यूम पर बैठा है। मैं विभिन्न प्रदर्शन ट्यूनिंग रणनीतियों का परीक्षण कर रहा हूं और यह विचार मुझे हुआ। चूँकि pvmove व्यक्तिगत और विलुप्त होने की श्रेणियों को स्थानांतरित कर सकता है, तो क्या कोई भौतिक फ़ाइल किसी विशेष फ़ाइल (सिद्धांत रूप में यह डेटाबेस के लिए बैकिंग फ़ाइलों या किसी बड़ी सामान्य रूप से एक्सेस की गई फ़ाइल का हिस्सा हो सकती है) को मैप करने का एक तरीका है और उन्हें एक विशेष में ले जाती है। स्टोरेज डिवाइस (उदाहरण के लिए मेरे पास एक नियमित एचडीडी और एक ही एलवीएम वॉल्यूम ग्रुप में एसएसडी ड्राइव है)?

मैंने "फाइलफ्रैग" का उपयोग करने के बारे में सोचा, लेकिन फिर मेरे साथ यह हुआ कि मैं इस बात पर 100% नहीं था कि क्या आवश्यक रूप से अनुक्रमिक क्रम में उपयोग किया जाएगा (इसलिए यह जानते हुए कि ext4 में कितने सेक्टर एक फाइल को देखना जरूरी नहीं है। मुझे यह पता लगाना चाहिए कि फ़ाइल किस सीमा तक / मात्रा में भौतिक रूप से बैठी है।

कोई विचार?

जवाबों:


13

दो मुख्य तत्व हैं hdparm --fibmap file, जो आपको बताता है कि फ़ाइल भौतिक रूप से LV के भीतर कहाँ स्थित है, और lvs -o +seg_pe_ranges,vg_extent_sizeजो आपको बताता है कि LV आपके डिवाइस (ओं) पर कहाँ स्थित है।

बाकी गणित है।

इसलिए, उदाहरण के लिए:

# hdparm --fibmap linux-3.8.tar.bz2 

linux-3.8.tar.bz2:
 filesystem blocksize 4096, begins at LBA 0; assuming 512 byte sectors.
 byte_offset  begin_LBA    end_LBA    sectors
           0     288776     298511       9736
     4984832     298520     298623        104
     5038080     298640     298695         56
     5066752     298736     298799         64
     5099520     298824     298895         72
     [...]

मुझे नहीं पता कि यह इतना खंडित क्यों है - wget के साथ डाउनलोड किया गया। एक अच्छा उदाहरण हो सकता है क्योंकि जैसा कि आप देखते हैं, आपको किसी भी तरह से स्क्रिप्टिंग के बिना सिरदर्द मिलता है, कम से कम खंडित फ़ाइलों के लिए। मैं सिर्फ पहला खंड 288776-298511 (9736 क्षेत्र) ले जाऊंगा। गिनती गलत है क्योंकि यह 512 बाइट सेक्टर नहीं है, लेकिन किसी भी तरह।

पहले जांचें कि यह डेटा वास्तव में सही है:

# dd if=linux-3.8.tar.bz2 bs=512 skip=0 count=9736 | md5sum
9736+0 records in
9736+0 records out
4984832 bytes (5.0 MB) copied, 0.0506548 s, 98.4 MB/s
7ac1bb05a8c95d10b97982b07aceafa3  -

# dd if=/dev/lvm/src bs=512 skip=288776 count=9736 | md5sum
9736+0 records in
9736+0 records out
4984832 bytes (5.0 MB) copied, 0.123292 s, 40.4 MB/s
7ac1bb05a8c95d10b97982b07aceafa3  -

Wheeee। क्या समान है इसलिए हम सही जगह पर LV-src पढ़ रहे हैं। अब स्रोत-LV कहाँ स्थित है?

# lvs -o +seg_pe_ranges,vg_extent_size
  LV          VG   Attr      LSize   Pool Origin Data%  Move Log Copy%  Convert PE Ranges             Ext   

[...]
 src         lvm  -wi-ao---   4.00g                                            /dev/dm-1:5920-6047   32.00m
[...]

अब यह उबाऊ है, यह LV खंडित नहीं है। यहां सिरदर्द नहीं है। वैसे भी।

यह कहता है कि src / dev / dm-1 पर है और PE 5920 से शुरू होता है और PE 6047 पर समाप्त होता है। और PE का आकार 32BB है।

तो देखते हैं कि क्या हम सीधे / देव / dm-1 से एक ही चीज़ पढ़ सकते हैं। गणित के लिहाज से, यह एक छोटा सा धब्बा है क्योंकि हमने पहले 512 बाइट का इस्तेमाल किया था ...: - / / लेकिन मैं आलसी हूँ इसलिए मैं सिर्फ MiB की गणना करूँगा और फिर 512 से भाग करूँगा! हा! :-D

# dd if=/dev/dm-1 bs=512 skip=$((1024*1024/512 * 32 * 5920 + 288776)) count=9736 | md5sum
9736+0 records in
9736+0 records out
4984832 bytes (5.0 MB) copied, 0.0884709 s, 56.3 MB/s
3858a4cd75b1cf6f52ae2d403b94a685  -

बू बू। यह वह नहीं है जिसकी हम तलाश कर रहे हैं। क्या गलत हुआ? आह! हम LVM मेटाडेटा और बकवास के भंडारण के लिए PV की शुरुआत में LVM के कब्जे वाले ऑफसेट को जोड़ना भूल गए। आमतौर पर यह MiB-align है, इसलिए बस एक और MiB जोड़ें:

# dd if=/dev/dm-1 bs=512 skip=$((1024*1024/512 * 32 * 5920 + 288776 + 1024*1024/512)) count=9736 | md5sum
9736+0 records in
9736+0 records out
4984832 bytes (5.0 MB) copied, 0.0107592 s, 463 MB/s
7ac1bb05a8c95d10b97982b07aceafa3  -

ये लो।


3
किसी दिन वे आपके सम्मान में मूर्तियों का निर्माण करेंगे।
ब्राचली

एक बात हालांकि, किसी भी विचार क्यों मेरे hdparm आह्वान segfaulting है ?
ब्राचली

वास्तव में, हड़ताल, ऐसा लगता है कि मुझे अपने google-fu पर सुधार करने की आवश्यकता है । यह एसएसडी और एलवीएम से संबंधित एक नया आरएचईएल बग है। मैं इसका मतलब है कि SSD पर फ़ाइल पहले से ही ले जाऊँगा। हा
ब्राचली

क्या एलवी में फ़ाइल की स्थिति निर्धारित करने के लिए एक और उपयोगिता है जब तक कि वे इसे ठीक नहीं करते हैं?
ब्राचली

आप पहले से ही यह उल्लेख किया - filefrag। अन्यथा अगर कोई अन्य टूल fibmap या Fiemap करता है तो google।
फ्रॉस्ट्सचुट्ज़
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.