- 518GiB tar.gz को extract करते समय यह बेहद धीमा हो गया, इसलिए इसकी जांच शुरू की गई
- Tar फ़ॉर्मेट का विवरण और तेज़ tar extractor कोड लिखते हुए उसकी व्याख्या
मूल Tar फ़ाइल फ़ॉर्मेट
- Tar एक archive फ़ाइल के रूप में काफ़ी असामान्य है
→ इसमें archive header नहीं होता, खोज के लिए file index नहीं होता, यह tar है या नहीं इसकी पुष्टि करने वाले magic bytes नहीं होते, footer नहीं होता, और metadata भी नहीं होता
→ Tar के अंदर सिर्फ़ एक ही तरह की वस्तु होती है: file object
- फ़ाइल प्रकार: 0 (सामान्य फ़ाइल), 1 (hard link), 2 (symbolic link)
- 512-बाइट file object header की संरचना का विवरण
→ सबसे बड़ी सीमा यह है कि फ़ाइल path की लंबाई सिर्फ़ 100 अक्षर हो सकती है। साथ ही फ़ाइल आकार की अधिकतम सीमा 8GiB है
UStar विस्तारित फ़ाइल
- फ़ाइल path की अधिकतम लंबाई 256 हो जाती है, और नए फ़ाइल प्रकार जोड़े जाते हैं
- Header को बढ़ाकर magic bytes और prefix field जोड़े गए
- फ़ाइल प्रकार जोड़े गए: 3 (character device), 4 (block device), 5 (directory), 6 (FIFO फ़ाइल), 7 (contiguous फ़ाइल)
- लेकिन 8GiB आकार की सीमा अब भी बनी रहती है
Pax फ़ाइल फ़ॉर्मेट
- POSIX.1-2001 मानक में pax CLI के ज़रिए tar फ़ॉर्मेट का विस्तार किया गया
- UStar जैसा ही है, लेकिन x और g फ़ाइल फ़ॉर्मेट जोड़े गए
→ extended header record में x सिर्फ़ अगली फ़ाइल पर लागू होता है, जबकि g उसके बाद की सभी फ़ाइलों पर लागू होता है
GNU Tar फ़ाइल फ़ॉर्मेट
- इसका अपना फ़ॉर्मेट
gnu है, जो pax से अलग है
- pax की तरह यह भी UStar आधारित है, लेकिन path और बड़ी फ़ाइलों को encode करने के लिए अलग तरीका इस्तेमाल करता है
→ L type: अगले file object का payload "file_path" को दर्शाता है
→ K type: अगले file object का payload "link_path" को दर्शाता है
→ इन दोनों को लगातार लागू किया जा सकता है
→ अगर फ़ाइल 8GiB से बड़ी हो, तो file_size के पहले अक्षर का high bit सेट किया जाता है। फिर शेष string को base 256 के रूप में parse किया जाता है (95-bit integer)
GNU tar extract करते समय धीमा क्यों होता है?
- अगर फ़ाइल के header में
file_path="../hello.txt" जैसी वैल्यू हो, तो सुरक्षा समस्या पैदा होती है। लेकिन इसे रोकना आसान नहीं है
- GNU tar,
link_path में ".." मिलने पर placeholder बनाता है और उसे delay करके प्रोसेस करता है
- लेकिन
".." के बिना hard link के मामले में वह सीधे बनाना चाहता है, पर पहले से placeholder होने के कारण बना नहीं पाता
- यानी hard link बनाने के लिए पहले यह पूरी तरह जांचना पड़ता है कि वह delayed link है या नहीं, और अगर है तो नए link को भी delay करना पड़ता है
→ हर hard link के लिए delayed link खोजना पड़ता है। कारण स्पष्ट नहीं, लेकिन व्यवहार में यह खोज 2 बार होती है
- लेखक की Tar फ़ाइल में
".." वाले 8 लाख से अधिक links और 54 लाख से अधिक hard links थे, इसलिए extraction धीमा हो गया
- इससे बचने के लिए tar में
--absolute-paths या -P विकल्प जोड़ें
→ यह absolute paths को स्टोर करता है और ".." को अस्वीकार करता है
→ यानी -P विकल्प देने पर delayed linking mechanism निष्क्रिय हो जाता है
1 टिप्पणियां
Tar से जुड़ी पोस्ट हमेशा मज़ेदार लगती हैं..
hop - tar से 10 गुना तेज़ archive format
Python से बनाई गई tar.xz फ़ाइल, default tar से बनाई गई फ़ाइल से छोटी क्यों होती है?