ext4: फाइलसिस्टम स्पेस का हिसाब कैसे दें?

Question

मैंने हाल ही में एक्सटी 4 के साथ एनटीएफएस को बदलने के इरादे से 1.5 टीबी ड्राइव तैयार किया है।

तब मैंने देखा कि मैंने जो फाइलें बचाईं, वे नए विभाजन पर फिट नहीं हुईं।

df:

ext4 (ext3 & ext2 show the same behavior)
Filesystem      1K-blocks   Used  Available Use% Mounted on
/dev/sdb1      1442146364   71160 1442075204    1% /media/Seagate

ntfs (similar to all other options that gparted offers):
/dev/sdb1      1465137148  110700 1465026448    1% /media/Seagate

उस 1K- ब्लॉक अंतर का मतलब है एक शानदार 22 GiB कम प्रयोग करने योग्य स्थान।

मैं पहले ही अंजाम दे चुका हूं

tune2fs -O \^has_journal
tune2fs -r 0
tune2fs -m 0

के साथ, आश्चर्यजनक रूप से, ऐसा कोई प्रभाव नहीं है जो उन ब्लॉकों को प्रभावित नहीं करता है जो अभी नहीं हैं।

फिर भी, fdisk रिपोर्ट करता है कि ext4 विभाजन संपूर्ण डिस्क को कवर करता है।

fdisk -l /dev/sdb:

WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted.

Disk /dev/sdb: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders, total 2930277168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1  2930277167  1465138583+  ee  GPT

और इस तरह उदाहरण के लिए resize2fs रिपोर्ट है कि "कुछ नहीं करना है!"

dumpe2fs -h /dev/sdb1:
dumpe2fs 1.41.14 (22-Dec-2010)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          d6fc8971-89bd-4c03-a7cd-abdb945d2173
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              91578368
Block count:              366284288
Reserved block count:     0
Free blocks:              360518801
Free inodes:              91578357
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      936
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Sat May 21 17:12:04 2011
Last mount time:          Sat May 21 17:15:30 2011
Last write time:          Sat May 21 17:24:32 2011
Mount count:              1
Maximum mount count:      32
Last checked:             Sat May 21 17:12:04 2011
Check interval:           15552000 (6 months)
Next check after:         Thu Nov 17 16:12:04 2011
Lifetime writes:          1372 MB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Default directory hash:   half_md4
Directory Hash Seed:      c334e6ef-b060-45d2-b65d-4ac94167cb09
Journal backup:           inode blocks

उस लापता स्थान का उपयोग क्या है?

Answer 1

चलो देखते हैं। डिवाइस का आकार 1,465,138,583B kB = 1,500,301,909,504 बी है। फाइल सिस्टम में 4096 बी के 366,284,288 ब्लॉक हैं, जो 1,500,300,443,648 बी हैं। मुझे नहीं पता कि शेष 1,465,856 बी (1.4 एमबी) का उपयोग सुपर की अतिरिक्त प्रतियों के लिए किया जाता है। ? मुझे पता है कि बूटलोडर के लिए शुरुआत में कुछ केबी का स्थान है।)

फाइलसिस्टम में प्रत्येक में 256 बाइट्स के 91,578,368 इनकोड हैं, जो 23,444,062,208 बी (लगभग 22 जीबी, संकेत, संकेत) लेता है। फिर फ़ाइल सामग्री के लिए 1,442,146,364 kB = 1,476,757,876,736 बी है। यह 23,444,062,208 बी + 1,476,757,876,736 बी = 1,500,201,938,944 बी के लिए खाता है। शेष आकार 98,504,704 बी = 24,029 ब्लॉक है जो जर्नल आकार के लिए सही सीमा में है।

जैसा कि आप देख सकते हैं, सब कुछ के लिए जिम्मेदार है। (ठीक है, लगभग सब कुछ, लेकिन हम मेगाबाइट की बात कर रहे हैं, गीगाबाइट की नहीं।)

Comments

धन्यवाद, यह निश्चित रूप से है। (जिस तरह से आप इसे प्रस्तुत करते हैं, यह भी स्पष्ट है - मुझे इसके बारे में थोड़ा और सोचना चाहिए।) इसलिए मैंने "mkfs.ext4 -m 0 -O sparse_super -T bigfile4" के साथ विभाजन को फिर से बनाया क्योंकि यह केवल कुछ हज़ार से अधिक को पकड़ना है। फाइलें, अब 357728 इनोडेस बनाम 1464880364 ब्लॉक उपलब्ध हैं।

— विविध

Answer 2

सबसे पहले, उपलब्ध स्थान में अंतर जो आप देख रहे हैं, इसका मतलब यह नहीं है कि अंतरिक्ष "बर्बाद" है; यह व्यर्थ नहीं है क्योंकि यह फाइल सिस्टम के कार्य करने के लिए मौलिक महत्व का है। आपको एक्सट 4 और एनटीएफएस की तुलना बहुत बड़े बिना इस तरह से नहीं करनी चाहिए "लेकिन" फाइल सिस्टम के बीच सभी डिज़ाइन और संरचनात्मक अंतरों को निर्दिष्ट करते हुए, और प्रत्येक कार्यान्वयन की बारीकियों को भी निर्दिष्ट करता है (उदाहरण के लिए प्रत्येक ड्राइवर वीएफएस परत को मुक्त स्थान कैसे बताता है)।

एक विशाल स्थान के रूप में विभाजन की कल्पना करें जहां आप अपने पास मौजूद डेटा के किसी भी टुकड़े को रख सकते हैं। यदि आपके पास विभाजन के बराबर आकार के साथ केवल एक ही टुकड़ा है, तो आप इसे विभाजन की शुरुआत में लिख सकते हैं और इसके साथ कूल हो सकते हैं। लेकिन तुम नहीं। इसके बजाय आपके पास हजारों छोटी फाइलें हो सकती हैं, और इन सभी फाइलों को अलग-अलग तरीकों से समूहीकृत किया जाता है, और प्रत्येक फ़ाइल को डेटा के कई अन्य छोटे टुकड़ों (नाम, दिनांक / समय और अनुमतियाँ), आदि से जुड़ी होती है। आपको बड़े स्थान को व्यवस्थित करना होगा। विभाजन ताकि आप डेटा के इन सभी टुकड़ों तक जल्दी और कुशलता से पहुंच सकें। साथ ही, आपको डेटा के नए टुकड़ों को लिखने और डेटा के पुराने टुकड़ों को कुशलता से छोड़ने के बारे में चिंतित होना होगा। आपको डेटा संरचनाओं की आवश्यकता है ।

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

आप निश्चित रूप से एक प्रणाली चाहते हैं:

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

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

Ext4 में अन्य महत्वपूर्ण गुण हैं। फ़ाइल सिस्टम में कोई एकल बिंदु-विफलता नहीं है। विभाजन के माध्यम से महत्वपूर्ण डेटा की कई प्रतियां फैली हुई हैं, जबकि कुछ अन्य फाइल सिस्टम (मैं NTFS के लिए नहीं कह सकता हूं) अगर सही जगह पर विफलता होती है, तो आपके सभी डेटा को अपठनीय बना सकता है। इसके अलावा, एक्सटी 4 फाइलसिस्टम क्रिएशन स्टेज पर आपके डेटा के लिए बहुत जगह रखता है, जबकि NTFS आपके डेटा के साथ बढ़ता है।

Comments

धन्यवाद, यह आखिरी हिस्सा महत्वपूर्ण है। मुझे नहीं पता था कि ext4 करता है (तुलनात्मक रूप से) निर्माण समय पर बहुत सारे काम जो ntfs ऑपरेशन के दौरान करते हैं।

— विविध

Answer 3

WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! 
The util fdisk doesn't support GPT. Use GNU Parted.

यह संदेश इंगित करता है कि डिस्क GPT- शैली विभाजन का उपयोग करती है, और यह fdiskउपकरण केवल विरासत MBR शैली को समझता है।

जीपीटी-विभाजन डिस्क को पुराने गैर-जीपीटी-जागरूक सिस्टम में प्लग किया जाता है, तो आकस्मिक सुधार को रोकने के लिए, जीपीटी विभाजन योजना में "सुरक्षात्मक एमबीआर" शामिल है: एक पूरी तरह से फर्जी विभाजन तालिका जो मूल रूप से बताती है "यह डिस्क पूरी तरह से एक विभाजन प्रकार के उपयोग में है। किसी भी ऑपरेटिंग सिस्टम या टूल के बारे में कुछ भी नहीं जानते हैं जो केवल MBR विभाजन को समझता है।

अपने विभाजन तालिका का सटीक प्रदर्शन प्राप्त करने के लिए /dev/sdb, उपयोग करें:

parted /dev/sdb print