আমি কীভাবে আবিষ্কার করতে পারি যে কোনও ফাইল যেখানে শারীরিকভাবে ডিস্কে অবস্থিত (ব্লক সংখ্যা)?


10

এটি একটি অস্পষ্ট প্রশ্ন, আমি জানি। আমি একটি লিনাক্স বাক্সে কিছু ডিস্কের কিছু পারফরম্যান্স টেস্ট করার চেষ্টা করছি। একই ডিস্কে একই পরীক্ষা চালিয়ে আমি কিছু অসঙ্গত ফলাফল পাচ্ছি। আমি জানি যে ডিস্কের কোন অংশটি অ্যাক্সেস করা হচ্ছে তার উপর নির্ভর করে ডিস্কগুলির বিভিন্ন কর্মক্ষমতা থাকে have বিশেষত, ডিস্কের বাইরের অংশে পড়া এবং লেখার চেয়ে ডিস্কের অভ্যন্তরের অংশে পড়ার চেয়ে অনেক বেশি থ্রুপুট থাকে এবং অবিচ্ছিন্ন ডাটা ঘনত্ব এবং ধ্রুবক ঘূর্ণন গতির কারণে।

আমি দেখতে চাই যে আমার অসম্পূর্ণতাগুলি এই জ্যামিতি-প্ররোচিত পরিবর্তনের মাধ্যমে থ্রুটপুটকে দায়ী করা যায় কিনা। ডিস্কে একটি ফাইলটি কোথায় রাখা হয়েছে তা সন্ধান করার জন্য বিদ্যমান সরঞ্জামগুলি ব্যবহার করে কি সম্ভব?

যদি তা না হয় তবে আমি মনে করি যে আমি সরাসরি ফাইল সিস্টেমটি বাইপাস করে (এবং ধ্বংস) ডিভাইস ফাইলটিতে সরাসরি অনুসন্ধান করতে, পড়তে এবং লিখতে লিখতে পারি, তবে আমি এটি এড়াতে আশা করছি। আমি বর্তমানে একটি 3.0 কার্নেলটিতে আর্কিট 4 ব্যবহার করছি (আর্চ লিনাক্স, যদি এটি গুরুত্বপূর্ণ হয়) তবে আমি অন্যান্য ফাইল সিস্টেমের জন্য কৌশলগুলিতেও আগ্রহী।


1
ফাইলগুলি এক জায়গায় আছে কে বলে? যদি তারা খণ্ডিত হয়ে যায় (যা তারা সাধারণত করেন) তবে তারা সব শেষ করতে পারে।
সিরেক্স

একেবারে। তবে তারা এখনও অন্য কোথাও রয়েছেন :-) এবং আমার বিশেষ ক্ষেত্রে, একটি সদ্য নির্মিত ফাইল সিস্টেমে ফাইলগুলি লেখার ক্ষেত্রে এগুলি বেশিরভাগ ক্ষেত্রেই (বেশিরভাগ) অবরুদ্ধ।
রিক কোশি

আপনি এটি করতে পারবেন না। সবচেয়ে ভাল আপনি পেতে পারেন ফাইলগুলির এলবিএ ব্লক নম্বরগুলি, যা অগত্যা নির্দিষ্ট শারীরিক অবস্থানের সাথে সামঞ্জস্য করে না (অন্তত এমনভাবে নয় যা আপনি নির্ধারণ করতে পারেন, কারণ ড্রাইভগুলি এই ম্যাপিং প্রকাশ করে না)। এছাড়াও অন্যান্য জিনিস রয়েছে, উদাহরণস্বরূপ, 3-5 টি ব্লকগুলি ধারাবাহিকভাবে সংখ্যাযুক্ত হতে পারে, তবে 4 টি ড্রাইভের সম্পূর্ণ ভিন্ন স্থানে পুনর্নির্বাচিত হতে পারে কারণ 4 এ মূল ক্ষেত্রটি শারীরিকভাবে ক্ষতিগ্রস্থ হয়েছিল, ইত্যাদি আপনি তথ্য পেতে পারেন না You ড্রাইভ প্রস্তুতকারক আপনাকে বিস্তারিত ঠিকানা চশমা দিতে রাজি না হলে আপনি সন্ধান করছেন।
জেসন সি

উত্তর:


7

আপনি এটির debugfsজন্য ব্যবহার করতে পারেন :

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

সেই অনুযায়ী হার্ড / পার্টিশন ড্রাইভটি পরিবর্তন করুন এবং নিশ্চিত করুন যে ড্রাইভটি আনমাউন্ট হয়েছে। ব্যবহৃত সমস্ত ব্লক সহ আপনি একটি তালিকা পাবেন:

BLOCKS:
(0):1643532
TOTAL: 1

1
এই নিখুঁত, ধন্যবাদ। যদিও আপনি ড্রাইভটি আনমাউন্ট করা হয়েছে তা নিশ্চিত করার জন্য কেন বলেছেন বলে আমি নিশ্চিত নই। ম্যানুয়াল পৃষ্ঠা অনুসারে, ডিবাগগুলি ডিফল্টরূপে কেবল পঠন মোডে খোলে, তাই এই কমান্ডটি একটি সক্রিয় ফাইল সিস্টেমেও সম্পূর্ণ নিরাপদ থাকা উচিত। এটি যদি প্রশ্নযুক্ত ফাইলটি সক্রিয়ভাবে সেই সময় সক্রিয়ভাবে পরিবর্তিত হচ্ছে তবে এটি সন্দেহজনক ফলাফল প্রদান করতে পারে তবে অন্য কোনও সমস্যার ফলস্বরূপ দেখা উচিত নয়। আমি কিছু মিস করেছি?
রিক কোশি

না, আপনি ঠিক বলেছেন। এটি আরও একটি 'সেরা অনুশীলন' এর পরে অবশ্যই আবশ্যক। আপনি একটি সক্রিয় ফাইলসিস্টেম উপর এরকম হয়, ফাইল ইত্যাদি পরিবর্তন হতে পারে
বার্ট ডি আপনি এই

1
এলবিএ ব্লক নম্বরটি আপনাকে জানায় না যে ফাইলটি শারীরিকভাবে ডিস্কে অবস্থিত। আধুনিক ড্রাইভের শারীরিক জ্যামিতির জটিলতার কারণে, নেপথ্য ক্ষেত্রে সেক্টর পুনর্নির্মাণ ইত্যাদির কারণে আজকের দিনে সাধারণত এলবিএ থেকে শারীরিক অবস্থানে রূপান্তর সম্ভব হয় না সাধারণত ডিস্ক-ভিত্তিক মিডিয়া নিম্ন এলবিএর জন্য এটি নিরাপদ বাজি বলে ড্রাইভের বাইরের দিকে, তবে এটি কেবল কারণ যে লেআউটটি অতীতে সাধারণ ছিল, পিএইচএসের সম্বোধনের দিনগুলিতে। আধুনিক ড্রাইভগুলি সত্যিকারের সিএইচএস জ্যামিতি আর প্রকাশ করে না, কারণ তারা পারে না।
জেসন সি

ফ্যাট fie সিস্টেম সম্পর্কে কি?
ছদ্মবেশী

10

আপনি এখানে উদাহরণ হিসাবে যেমন 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

দুর্ভাগ্যক্রমে, স্ট্যাটাস দ্বারা কিছুই আউটপুট আমার প্রয়োজনীয় তথ্য নয়। বাইট এবং ব্লক, inode সংখ্যা, অনুমতি ... এই কোনটিই মধ্যে Size প্রতিফলিত যা ব্লক ফাইল এর ডাটা ধারণ করে। উদাহরণস্বরূপ, আমার পরীক্ষার ফাইলগুলি (যা সমস্ত একই আকারের হয়) সমস্ত ইনোড নম্বর এবং অ্যাক্সেস / পরিবর্তনের সময় ব্যতীত একই তথ্য প্রদর্শন করে।
রিক কোশি

হ্যাঁ, আপনি ঠিক বলেছেন, আমি দুঃখিত, আমি সঠিকভাবে পড়িনি। আমি আমার উত্তরটি আরও সঠিকভাবে পরিবর্তন করেছি।
ফ্রাঙ্কোইস জি

এইচডিপিআরএম আমার যা প্রয়োজন তা আমাকে দেয় এবং ডিবাগফের চেয়ে কিছুটা বেশি পাঠযোগ্য বিন্যাসে। যদিও এটি ডিফল্টরূপে (আর্চ লিনাক্সে) ইনস্টল করা হয়নি, আমাকে এটি খুঁজে পেতে হয়েছিল। ডিবাগগুলি e2fsprogs (একই প্যাকেজ যা আমাদেরকে mkfs এবং fsck দেয়) এর একটি অংশ, তাই ডিফল্টরূপে ইনস্টল করা হয়।
রিক কোশি

ড্রাইভের মধ্যে ফাইলটি শারীরিকভাবে কোথায় রয়েছে তা এলবিএ আপনাকে জানায় না। এলবিএগুলির প্রকৃত শারীরিক ম্যাপিং সম্পর্কিত তথ্য পাওয়া সম্ভব নয়।
জেসন সি

আমি এটি চর্বিতে HDIO_GETGEO failed: Inappropriate ioctl for device
পেয়েছি

5

এই থ্রেডটি আপনাকে ext4 ফাইল প্লেসমেন্ট অ্যালগরিদম সম্পর্কে কিছু অন্তর্দৃষ্টি দিতে পারে।

debugfsএকটি bmapফাংশন রয়েছে, যা মনে হয় আপনার দেওয়া ডেটা দেয়। আপনার এটিকে কোনও ফাইলের একটানা ব্লক দিতে এবং শারীরিক ব্লক নম্বর পেতে সক্ষম হওয়া উচিত।


1
Ext4 ফাইল বসানো সম্পর্কে থ্রেডের পয়েন্টারটির জন্য ধন্যবাদ। সেটা ছিল আলোকিত। :-)
রিক কোশি

ড্রাইভের মধ্যে ফাইলটি শারীরিকভাবে কোথায় রয়েছে তা এলবিএ আপনাকে জানায় না। এলবিএগুলির প্রকৃত শারীরিক ম্যাপিং সম্পর্কিত তথ্য পাওয়া সম্ভব নয়।
জেসন সি

2

প্রশ্নটি বরং পুরানো, তবে আরও একটি উত্তর রয়েছে যা গুগলে 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)। সাবধান হন যে লজিকাল অফসেটগুলি সংযুক্ত নাও হতে পারে, কারণ কোনও ফাইলের মধ্যে গর্ত থাকতে পারে (যখন ফাইল সিস্টেম দ্বারা সমর্থিত হয়))

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.