ZFS भेजने / पुन: पेश करने के लिए सर्वश्रेष्ठ संपीड़न

Question

मैं एक पॉइंट-टू-पॉइंट T1 लाइन पर वृद्धिशील ZFS स्नैपशॉट भेज रहा हूं और हम एक ऐसे बिंदु पर हैं जहां एक दिन के स्नैपशॉट का मूल्य बमुश्किल अगले बैकअप शुरू होने से पहले तार पर बना सकते हैं। हमारा भेजें / पुनः आदेश है:

zfs send -i tank/vm@2009-10-10 tank/vm@2009-10-12 | bzip2 -c | \
ssh offsite-backup "bzcat | zfs recv -F tank/vm"

मेरे पास बहुत से सीपीयू साइकिल हैं। वहाँ एक बेहतर संपीड़न एल्गोरिथ्म या वैकल्पिक विधि मैं लाइन पर कम डेटा पुश करने के लिए उपयोग कर सकता है?

Comments

क्या आपने यह सत्यापित किया है कि यह वास्तव में सबसे धीमा हिस्सा है? शायद यह डिस्क रीडिंग / राइटिंग है।

— kbyrd

हाँ, मुझे NFS के माध्यम से बॉक्स से जुड़ने वाले 80-100 एमबीपीएस मिलते हैं। नेटवर्क कनेक्शन १.५ एमबीपीएस

— १६:०१

क्या आपने lzma --best का उपयोग करने की कोशिश की है?

— अमोक

जैसा कि अमुक ने बताया, LZMA वर्तमान में व्यापक रूप से उपलब्ध सबसे अच्छा सामान्य डेटा संपीड़न एल्गोरिथ्म है।

— क्रिस एस

उदाहरण के लिए, ऐसे आंकड़े जो दिखाते हैं कि zfs receiveअपराधी हो सकते हैं:received 953MB stream in 36 seconds (26.5MB/sec)

— poige

Answer 1

ऐसा लगता है कि आपने सभी सर्वोत्तम संपीड़न तंत्रों की कोशिश की है और अभी भी लाइन गति द्वारा सीमित किया जा रहा है। यह मानते हुए कि एक तेज़ लाइन चल रही है, इस सवाल से बाहर है, क्या आपने बैकअप को कम बार चलाने पर विचार किया है ताकि उनके पास दौड़ने के लिए अधिक समय हो?

उसमें से छोटा, क्या किसी प्रकार के डेटा को कम करने का तरीका है? आपके आवेदन को जाने बिना यह कहना कठिन है, लेकिन यह सुनिश्चित करने के लिए कि नए ऐप बनाने के बजाय मौजूदा फ़ाइलों को अधिलेखित कर दिया जाए। और सुनिश्चित करें कि आप टेम्प / कैश फ़ाइलों का बैकअप सहेजने की ज़रूरत नहीं है, जो आपको चाहिए।

Answer 2

यहाँ मैंने वही सीखा है जो आप कर रहे हैं। मैं mbuffer का उपयोग करने का सुझाव देता हूं। मेरे वातावरण में परीक्षण करते समय यह केवल प्राप्त अंत पर मदद करता है, इसके बिना सभी भेजे जाने पर धीमा हो जाता है जबकि प्राप्त होता है।

कुछ उदाहरण: http://everycity.co.uk/alasdair/2010/07/using-mbuffer-to-speed-up-slow-zfs-send-zfs-receive/

विकल्पों और वाक्यविन्यास के साथ मुखपृष्ठ http://www.maier-komor.de/mbuffer.html

मेरी प्रतिकृति स्क्रिप्ट से आदेश भेजें:

zfs send -i tank/pool@oldsnap tank/pool@newsnap | ssh -c arcfour remotehostip "mbuffer -s 128k -m 1G | zfs receive -F tank/pool"

यह दूरस्थ होस्ट पर mbuffer को एक रिसीव बफर के रूप में चलाता है ताकि भेजने में जितनी जल्दी हो सके। मैं एक 20mbit लाइन चलाता हूँ और पाया कि भेजने वाले पक्ष में mbuffer होने के साथ-साथ मदद भी नहीं की, मेरे मुख्य zfs बॉक्स ने सभी को RAM के रूप में उपयोग कर रहा है इसलिए mbuffer को 1g देने से भी मुझे कुछ कैश आकार कम करने की आवश्यकता होगी।

इसके अलावा, और यह वास्तव में मेरी विशेषज्ञता का क्षेत्र नहीं है, मुझे लगता है कि यह सिर्फ ssh संपीड़न करने के लिए सबसे अच्छा है। आपके उदाहरण में मुझे लगता है कि आप bzip का उपयोग कर रहे हैं और फिर ssh का उपयोग कर रहे हैं जो डिफ़ॉल्ट रूप से संपीड़न का उपयोग करता है, इसलिए SSH एक संपीड़ित स्ट्रीम को संपीड़ित करने की कोशिश कर रहा है। मैंने सिफर के रूप में आर्कफॉर का उपयोग करके समाप्त किया क्योंकि यह कम से कम सीपीयू गहन है और मेरे लिए महत्वपूर्ण था। आपके पास एक और सिफर के साथ बेहतर परिणाम हो सकते हैं, लेकिन मैं निश्चित रूप से सुझाव देता हूँ कि SSH को कम्प्रेशन करने दें (या ssh कम्प्रेशन को बंद करें यदि आप वास्तव में कुछ ऐसा उपयोग करना चाहते हैं जो इसका समर्थन नहीं करता है)।

Whats वास्तव में दिलचस्प है कि लोकलहोस्ट पर भेजने और प्राप्त करने के दौरान mbuffer का उपयोग करने के साथ-साथ चीजों को गति देता है:

zfs send tank/pool@snapshot | mbuffer -s 128k -m 4G -o - | zfs receive -F tank2/pool

मैंने पाया कि लोकलहोस्ट ट्रांसफर के लिए 4 जी मेरे लिए मिठाइयों की तरह लगता है। यह सिर्फ यह दिखाने के लिए जाता है कि zfs को भेजने / प्राप्त करने के लिए वास्तव में विलंबता या स्ट्रीम में कोई अन्य ठहराव सबसे अच्छा काम नहीं करता है।

बस मेरा अनुभव, आशा है कि यह मदद करता है। मुझे यह सब पता लगाने में थोड़ी देर लगी।

Comments

इस पोस्ट के लिए बहुत धन्यवाद। Zfs को अधिक निकटता से देखने पर मुझे बहुत जल्दी यह अहसास हुआ कि लेटेंसी-बाउंड टारगेट पर भेजते समय यह एक बुरा व्यवहार (उर्फ "डिज़ाइन") है। लगभग एक दर्जन परिणामों के बाद बताया कि zfs संभवतः कभी भी किसी भी चीज़ के लिए दोषी नहीं हो सकते। मैं बहुत आभारी हूं कि आपने इसे देखने के लिए समय लिया और अपने परिणाम पोस्ट किए।

— फ़्लोरियन हीगल

Answer 3

यह आपके विशिष्ट प्रश्न का उत्तर है:

आप रज़िप की कोशिश कर सकते हैं , लेकिन यह उन तरीकों से काम करता है जो सेक / बीज़िप / गज़िप से थोड़ा अलग हैं:

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

यदि आपका संसाधन बाधा आपका पाइप है, तो आप किसी भी तरह बैकअप 24x7 चला रहे हैं, इसलिए आपको बस लगातार स्नैपशॉट कॉपी करने की आवश्यकता होगी और आप किसी भी तरह से उम्मीद करेंगे।

आपका नया आदेश होगा:

remotedir=/big/filesystem/on/remote/machine/
while 
  snaploc=/some/big/filesystem/
  now=$(date +%s)
  snap=snapshot.$now.zfssnap
  test -f $snaploc/$snap
do
  sleep 1
done

zfs send -i tank/vm@2009-10-10 tank/vm@2009-10-12 > $snaploc/$snap &&
rzip $snaploc/$snap &&
ssh offsite-backup "
        cat > $remotedir/$snap.rzip && 
        rzip -d $remotedir/$snap.rzip && 
        zfs recv -F tank/vm < $remotedir/$snap &&
        rm $remotedir/$snap " < $snaploc/$snap &&
rm $snaploc/$snap

आप बेहतर त्रुटि सुधार करना चाहते हैं, और आप संकुचित फ़ाइलों को स्थानांतरित करने के लिए rsync जैसी किसी चीज़ का उपयोग करने पर विचार करना चाहते हैं, ताकि यदि बीच में स्थानांतरण विफल हो जाए तो आप उसे उठा सकते हैं जहाँ आपने छोड़ा था।

Answer 4

इस प्रश्न के पोस्ट होने के बाद से वर्षों में चीजें बदल गई हैं:

1: ZFS अब संपीड़ित प्रतिकृति का समर्थन करता है, बस-ध्वज को zfs कमांड भेजने के लिए ध्वज जोड़ें, और डिस्क पर जो संपीड़ित थे वह संपीड़ित रहेगा क्योंकि वे पाइप से दूसरे छोर तक जाते हैं। अभी भी अधिक संपीड़न प्राप्त किया जा सकता है, क्योंकि ZFS में डिफ़ॉल्ट संपीड़न lz4 है

2: इस मामले में उपयोग करने के लिए सबसे अच्छा कंप्रेसर zstd (ZStandard) है, इसमें अब एक 'अनुकूली' मोड है जो संपीड़न स्तर को बदल देगा (19+ स्तरों के बीच समर्थित, प्लस नई उच्च गति zstd-fast स्तर) के आधार पर zfs सेंड और zfs के बीच की लिंक की गति पुनरावृत्ति। यह पाइप के बाहर जाने के लिए प्रतीक्षा कर रहे डेटा की कतार को न्यूनतम तक रखने के दौरान जितना हो सके उतना कम हो जाता है। यदि आपका लिंक तेज़ है, तो इससे डेटा को कम करने में समय बर्बाद नहीं होगा, और यदि आपका लिंक धीमा है, तो यह डेटा को अधिक संपीड़ित करने के लिए काम करता रहेगा और अंत में आपका समय बचाएगा। यह थ्रेडेड संपीड़न का भी समर्थन करता है, इसलिए मैं कई कोर का लाभ उठा सकता हूं, जो कि गज़िप और बज़िप नहीं है, विशेष संस्करण जैसे कि पिज़िप के बाहर।

Answer 5

मैं मान रहा हूँ कि आप अपनी साइट के कच्चे बैंडविड्थ को बढ़ा नहीं सकते हैं ...

आप मेजबान पर संपीड़न का उपयोग नहीं करने से लाभ देख सकते हैं।

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

यदि आप सीमित सीमा पर हैं, तो आप rsync का उपयोग करके और असम्पीडित स्नैपशॉट का उपयोग करके एक समान सुधार देख सकते हैं , अर्थात:

zfs send -i tank/vm@2009-10-10 tank/vm@2009-10-12 > /path/to/snapshotdir/snapshotfile
rsync /path/to/snapshotdir/snapshotfile offsite-backup:/remote/path/to/snapshotfile
ssh offsite-backup 'zfs recv -F tank/vm < /remote/path/to/snapshotfile'

यह तेज होगा क्योंकि rsync केवल कल के स्नैपशॉट और आज के बीच के अंतर को स्थानांतरित करेगा। स्नैपशॉट प्रक्रिया कैसे काम करती है, इस पर निर्भर करते हुए, दोनों के बीच अब भी बहुत अधिक अतिरेक हो सकता है, भले ही वे वास्तव में एक ही फ़ाइल न हों।

वान ऑप्टिमाइज़र इस समस्या को ठीक करने के लिए एक अधिक संभावित तरीका है (खैर, मेट्रो ईथरनेट इस समस्या को हल करने का सबसे संभावित तरीका है, लेकिन हम उस तालिका को छोड़ देंगे)। Rsync अंधेरे में सिर्फ एक जंगली शॉट है जो परीक्षण के लायक है (स्थानीय रूप से; rsync आपको बताएगा कि फाइबर के लिए बड़ा चेक लिखने या रिवरबेड इंस्टॉल करने से पहले अपने स्थानीय डेटा पर कितना समय उसने सीधे कॉपी पर बचाया)।

Answer 6

हांलांकि इसकी कीमत के बारे निश्चित नहीं हूँ। मैं डायरेक्ट सेंड नहीं करूँगा | सेक | डीकंप्रेस | इसे प्राप्त करने के अंत में समस्याओं को जन्म दे सकता है यदि हस्तांतरण लाइन स्नैप और आपका पूल प्राप्त होने के दौरान लंबे समय तक ऑफ़लाइन रहेगा। हम एक स्थानीय फ़ाइल भेजते हैं, फिर स्नैपशॉट को gzip करते हैं और rsync (रिवरबेड के साथ) का उपयोग करके स्थानांतरण करते हैं, फिर हम फ़ाइल से प्राप्त करते हैं। यदि हस्तांतरण में कोई समस्या है, तो रिवरबेड ट्रैफ़िक BUT को ऑप्टिमाइज़ नहीं करता है और इसे रीबेंड अप रिवरबेड स्पीड को रीस्टार्ट करने की आवश्यकता है।

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

यदि आपके पास एक रिवरबेड है तो rsync का उपयोग न करें ssh के रूप में रिवरबेड rsync को समझता है और इसे ऑप्टिमाइज़ करने का प्रयास करेगा और डेटा को कैश में जोड़ देगा (ऊपर देखें, फिर से स्थानांतरण को पुनः आरंभ करें)।

Answer 7

मेरा अनुभव यह है कि zfs sendनिम्नलिखित संपीड़न कदम की तुलना में बहुत तेज (औसतन) होने के बावजूद काफी फट गया है। मेरा बैकअप इसके बाद zfs sendऔर बाद में काफी बफरिंग सम्मिलित करता है gzip:

zfs send $SNAP | mbuffer $QUIET -m 100M | gzip | mbuffer -q -m 20M | gpg ... > file

मेरे मामले में आउटपुट डिवाइस USB (नेटवर्क नहीं) जुड़ा हुआ है, लेकिन बफ़रिंग एक समान कारण के लिए महत्वपूर्ण है: जब USB ड्राइव को 100% व्यस्त रखा जाता है, तो समग्र बैकअप समय तेज होता है। आप समग्र रूप से कम बाइट नहीं भेज सकते हैं (जैसा कि आप अनुरोध करते हैं) लेकिन आप अभी भी जल्द ही समाप्त कर सकते हैं। बफरिंग सीपीयू-बाउंड कंप्रेशन स्टेप को आईओ-बाउंड बनने से रोकता है।

Answer 8

WAN पर भेजते समय मैं हर समय pbzip2 (समानांतर bzip2) का उपयोग करता हूं । चूंकि यह थ्रेडेड है, आप -p विकल्प के साथ उपयोग करने के लिए थ्रेड्स की संख्या निर्दिष्ट कर सकते हैं। होस्ट भेजने और प्राप्त करने दोनों पर पहले pbzip2 स्थापित करें, स्थापना निर्देश http://compression.ca/pbzip2/ पर हैं ।

zfs send -i tank/vm@2009-10-10 tank/vm@2009-10-12 | pbzip2 -c | \
ssh offsite-backup "pbzip2 -dc | zfs recv -F tank/vm"

मुख्य कुंजी लगातार अंतराल (~ 10mins) पर स्नैपशॉट बनाना है ताकि आपके स्नैपशॉट का आकार छोटा हो सके और फिर प्रत्येक स्नैपशॉट भेजें। ssh टूटी हुई स्नैपशॉट स्ट्रीम से फिर से शुरू नहीं होगा इसलिए यदि आपके पास भेजने के लिए एक बड़ा स्नैपशॉट है, स्ट्रीम को pbzip2 पर पाइप करें, फिर प्रबंधनीय आकार के टुकड़ों में विभाजित करें, फिर होस्ट प्राप्त करने के लिए फ़ाइलों को rsync विभाजित करें, फिर concfenated pbzip2 फ़ाइलों को zfs के लिए पाइप करें।

zfs send -i tank/vm@2009-10-10 tank/vm@2009-10-12 | pbzip2 -c | \
split -b 500M - /somedir/snap-inc-10-to-12.pbzip2--

यह 500MB विखंडू में नामित फ़ाइलों का उत्पादन करेगा:

/somedir/snap-inc-10-to-12.pbzip2--aa
/somedir/snap-inc-10-to-12.pbzip2--ab
/somedir/snap-inc-10-to-12.pbzip2--ac
...

कई बार होस्ट प्राप्त करने के लिए rsync (आप zfs पूरा होने से पहले भी rsync कर सकते हैं या जैसे ही आप एक पूर्ण 500MB chunk देखते हैं), रद्द करने के लिए कभी भी ctrl + c दबाएं :

while [[ true ]]; do rsync -avP /somedir/snap-inc-10-to-12.pbzip2--* offsite-backup:/somedir ; sleep 1; done;

zfs प्राप्त:

cat /somedir/snap-inc-10-to-12.pbzip2--* | pbzip2 -dc | zfs recv -Fv tank/vm

उपयोगकर्ता फ़्रींड का उल्लेख किया गया है: इसके लायक क्या है। मैं डायरेक्ट सेंड नहीं करूँगा | सेक | डीकंप्रेस | इसे प्राप्त करने के अंत में समस्याओं को जन्म दे सकता है यदि हस्तांतरण लाइन स्नैप और आपका पूल प्राप्त होने के दौरान लंबे समय तक ऑफ़लाइन रहेगा। - मुझे पुराने होस्ट के साथ मुद्दों का सामना करना पड़ा है <28 प्राप्त करने वाले होस्ट में </ b> अगर चल रहे सेंड / रिकव को नेटवर्क ड्रॉप्स से बाधित किया जाता है, लेकिन इस हद तक नहीं कि पूल बंद हो जाए। यह तो दिलचस्प है। स्नैपशॉट को केवल तभी भेजें जब "zf recv" प्राप्त अंत में बाहर निकल गया हो। यदि आवश्यक हो तो "zfs recv" को मैन्युअल रूप से मारें। zfs send / recv को अब FreeBSD या Linux में बहुत सुधार किया गया है।

Answer 9

आप ssh के लिए तेजी से सिफर उठा सकते हैं, ब्लोफिश-सीबीसी, -123456789 स्विच भी आज़मा सकते हैं

-1 (or --fast) to -9 (or -best)

Comments

यूनिक्स मैन पेज से: Thefast और --best उपनाम मुख्य रूप से GNU gzip संगतता के लिए हैं। विशेष रूप से, - टेक्स्ट चीजों को साइन-अप नहीं करता है। और --best केवल डिफ़ॉल्ट व्यवहार का चयन करता है।

— सेसाडिमेनिकस

इसलिए आपके मामले में इसका कोई प्रभाव नहीं है। सिफर का क्या?

— इस्तवान

मुझे LZMA संपीड़न के साथ अच्छी किस्मत मिली है, लेकिन यह हो सकता है कि आपका लिंक बहुत धीमा हो।

— अमोक

Answer 10

आपको अपने डेटा के साथ परीक्षण करना होगा। बस इसे एक फ़ाइल में भेजें और इसे प्रत्येक विधि से संपीड़ित करें।

हमारे लिए, gzip में बहुत बड़ा अंतर था और हम उसके माध्यम से सब कुछ चलाते हैं, लेकिन gzip और bzip या 7z के बीच 1% का अंतर भी नहीं था।

यदि आप धीमे T1 पर हैं, तो आपको इसे फ़ाइल में संग्रहीत करना होगा और इसे rsync करना होगा।

उन लोगों के लिए (आप नहीं) जो बैंडविड्थ की तुलना में सीपीयू द्वारा थोड़ा अधिक सीमित हैं, जैसे कि lstvan ने एक अलग सिफर कहा है जैसे कि आर्कफौरसैब चीजों को गति देता है। जब हम चीजों को इधर-उधर करते हैं तो हम आंतरिक रूप से इसका उपयोग करते हैं।

Answer 11

Zfs के लिए डिडअप चालू करने का प्रयोग -D के साथ भेजें। बचत इस बात पर निर्भर करती है कि आपके डेटा में कितना दोहराव है।

Comments

चूंकि वह -i"वृद्धिशील" बैकअप का उपयोग कर रहा है, इसलिए इसमें बहुत उम्मीद नहीं है कि -Dवह कुछ भी देगा।

— गरीब

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

— जेम्स मूर

यदि आपके पास बहुत सारे डुप्लिकेट हैं, तो कोई भी सम्पीडन वैसे भी इसका ख्याल रखेगा।

— पोइग

@poige उन्हें अपने वास्तविक डेटा के खिलाफ मापना होगा। आपके पास निश्चित रूप से डेटासेट हो सकते हैं जो बुरी तरह से संपीड़ित करते हैं और वास्तव में अच्छी तरह से कटौती करते हैं। उदाहरण के लिए, एक ही संपीड़ित वीडियो फ़ाइल की कई प्रतियां वास्तव में अच्छी तरह से कट जाती हैं, और फ़ाइल सिस्टम स्तर पर संपीड़न संभवतः बेकार से भी बदतर है।

— जेम्स मूर

आह, यह मामला - हां

— पीग

Answer 12

"सर्वश्रेष्ठ" संपीड़न एल्गोरिथ्म इस बात पर निर्भर करता है कि आपके पास किस प्रकार का डेटा है - यदि आप एमपी 3 संग्रह संपीड़न को आगे बढ़ा रहे हैं तो संभवतः प्रक्रिया को धीमा कर देगा, जबकि पाठ / लॉगफ़ाइल्स के साथ महत्वपूर्ण रूप से संकुचित किया जा सकता है gzip -9।

आप प्रत्येक दिन कितना डेटा पुश कर रहे हैं?

Answer 13

क्या आपने अपने टीसीपी / आईपी स्टैक को ट्यूनिंग माना है ताकि आप टीसीपी बफर और विंडो आकार थोड़ा बड़ा हो? आप इसके लिए nddसोलारिस पर टूल या sysctlलिनक्स / बीएसडी / मैक ओएसएक्स पर टूल का उपयोग कर सकते हैं । सोलारिस पर, आप देख रहे हैं /dev/tcp tcp_max_bufऔर /dev/tcp tcp_cwnd_maxमूल्यों, और लिनक्स sysctl पर, आप देख रहे हैं net.ipv4.tcp_mem, net.ipv4.tcp_rmemऔर net.ipv4.tcp.wmemमूल्यों।

इसके अलावा, ये लिंक कुछ अतिरिक्त मदद कर सकते हैं:

सोलारिस टीसीपी प्रदर्शन ट्यूनिंग

उस पेज के नीचे लिंक का एक सेट है जो बताएगा कि लिनक्स / बीएसडी / ओएसएक्स के लिए भी ऐसा कैसे करना है।

Comments

1. यह एक 5 साल पुराना सवाल है जिसे आप खोद रहे हैं। 2. उन्होंने यह नहीं कहा कि लिंक को हटा दिया गया और संपीड़न के बारे में पूछा गया, जिसका आप संदर्भ नहीं लेते हैं। 3. अधिकांश OSes इन दिनों स्वचालित रूप से विंडो के आकार को ट्यून करते हैं। आपके द्वारा लिंक की गई जानकारी 3 साल पहले पुरानी थी जब लेखक ने इसे पोस्ट किया था।

— क्रिस एस