लैन पर एक बड़ी फ़ाइल की प्रतिलिपि बनाने का तेज़ तरीका

Question

मुझे एनएफएस से कुछ परेशानी हो रही है, और मैं सादे पुराने टीसीपी का उपयोग करने की कोशिश करना चाहता हूं।

मुझे पता नहीं है कि कहां से शुरू करना है, हालांकि।

हार्डवेयर-वार, मैं दो नेटबुक नेटवर्क के लिए ईथरनेट क्रॉसओवर केबल का उपयोग कर रहा हूं।

उन्हें नेटवर्क करने के लिए, मैं टाइप करता हूं

$ sudo ifconfig eth0 192.168.1.1 up && ping -c 10 -s 10 192.168.1.2 && sudo /etc/init.d/nfs-kernel-server start

पहली नेटबुक पर और

$ sudo ifconfig eth0 192.168.1.2 up
$ ping -c 10 -s 10 192.168.1.1
$ mount /mnt/network1

दूसरे स्थान पर

के /mnt/network1रूप में / etc / fstab में निर्दिष्ट किया गया है

192.168.1.1:/home /mnt/network1 nfs noauto,user,exec,soft,nfsvers=2 0 0

साथ ही साथ में /etc/exports(उस फ़ाइल का सिंटेक्स के उपयोग से), पहला नेटबुक पर।

ऊपर ठीक काम करता है, लेकिन फ़ाइलें और निर्देशिका बहुत बड़ी हैं। फाइलें औसतन आधा गीगाबाइट एक टुकड़ा है, और निर्देशिका सभी 15 और 50 गीगाबाइट के बीच हैं।

मैं rsyncउन्हें स्थानांतरित करने के लिए उपयोग कर रहा हूं , और कमांड (चालू 192.168.1.2) है

$ rsync -avxS /mnt/network1 ~/somedir

मुझे यकीन नहीं है कि अगर बड़ी फ़ाइलों को बेहतर तरीके से संभालने के लिए मेरी एनएफएस सेटिंग्स को मोड़ने का कोई तरीका है, लेकिन मैं यह देखना चाहूंगा कि क्या rsyncसादे पुराने टीसीपी पर डेमन चलाने rsyncसे एनएफएस की तुलना में बेहतर काम होता है ।

तो, दोहराना करने के लिए, मैं टीसीपी के साथ एक समान नेटवर्क कैसे स्थापित करूं?

अद्यतन करें:

इसलिए, अपने स्वयं के अज्ञानता (या, जैसा कि मैं इसके बारे में सोचना पसंद करता हूं, अपने खुद के बूटस्ट्रैप्स द्वारा खुद को ऊपर खींचने के लिए) को खींचने के लिए कुछ घंटों के प्रयास के बाद मैं कुछ उपयोगी तथ्यों के साथ आया हूं।

लेकिन सबसे पहले, मुझे इस खरगोश के निशान पर ले जाने के बजाय केवल वर्तमान सर्वोत्तम उत्तर को स्वीकार करने का कारण यह था: ncयह एक अविश्वसनीय रूप से अच्छा कार्यक्रम है जो मेरे लिए काम करने में पूरी तरह से विफल रहता है। मैंने कोशिश की है netcat-openbsdऔर netcat-traditionalकोई भाग्य के साथ संकुल जो भी हो।

मुझे प्राप्त करने की मशीन पर त्रुटि ( 192.168.1.2) है:

me@netbook:~$ nc -q 1 -l -p 32934 | tar xv
Can't grab 0.0.0.0:32934 with bind
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors

route देता है:

me@netbook:~$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         dir-615         0.0.0.0         UG    0      0        0 wlan0
link-local      *               255.255.0.0     U     1000   0        0 eth0
192.168.0.0     *               255.255.255.0   U     2      0        0 wlan0
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0

लेकिन, यहां अच्छी खबर है: स्थिर आईपी पते निर्धारित किए गए हैं /etc/network/interfaces, जो मैंने ncकाम करने की कोशिश करते हुए शुरू किए थे , मेरी सभी एनएफएस समस्याओं को ठीक किया और एनएफएस के लिए अपने प्यार को फिर से जागृत किया।

सटीक कॉन्फ़िगरेशन जिसका मैंने उपयोग किया ( 192.168.1.1पहली नेटबुक के लिए, निश्चित रूप से) था:

auto eth0
iface eth0 inet static
address 192.168.1.2
netmask 255.255.255.0

उन सेटिंग्स के साथ, दो नेटबुक सीधे बूट किए जाने के बाद एक दूसरे को पिंग करने में सक्षम होंगे, यहां तक ​​कि बिना भी ifup।

वैसे भी, मैं अभी भी वास्तव ncमें कार्रवाई में देखना चाहता हूं, इसलिए मैं उम्मीद कर रहा हूं कि कोई मुझे इस प्रक्रिया को डीबग करने में मदद करेगा।

Comments

यदि दोनों निर्देशिकाएं स्थानीय हैं, तो आप सादे पुराने का उपयोग करके बेहतर हैं /bin/cpया NFS का उपयोग नहीं करते हैं

— कार्लसन

NFS पर एक्सेस की गई फ़ाइल के खिलाफ rsync चलाने का मतलब है कि फ़ाइल की संपूर्ण सामग्री को कम से कम एक बार नेटवर्क पर कॉपी करने की आवश्यकता है। आपको क्लाइंट / सर्वर rsync को आमंत्रित करने के लिए डेमॉन की आवश्यकता नहीं है - बस इसे ssh पर चलाएँ। (यह टेलनेट / rsh पर दूरस्थ अंत को लागू करने के लिए सैद्धांतिक रूप से संभव है - लेकिन व्यवहार में ऐसी सेवा चलाने के लिए मूर्खतापूर्ण है - ssh ओवरहेड का एक बहुत कुछ नहीं जोड़ता है)।

— सिम्बियन

NFSv2 बहुत पुराना है। आप कौन सा ओएस उपयोग कर रहे हैं?

— नील

क्रमशः नवीनतम डेबियन और नवीनतम उबंटू। मैं nfsvers=2इस ट्यूटोरियल ( michaelminn.com/linux/home_network ) से उन सभी आदेशों (सहित ) को मिला

— ixtmixilix

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

— derobert

Answer 1

त्वरित तरीका है

लैन पर फ़ाइलों को स्थानांतरित करने का सबसे तेज़ तरीका संभवतः rsync नहीं है, जब तक कि कुछ बदलाव न हों। rsync समय-समय पर चेकसम को करने, मतभेदों की गणना करने आदि का एक अच्छा समय बिताता है, अगर आप जानते हैं कि आप वैसे भी अधिकांश डेटा स्थानांतरित करने जा रहे हैं, तो बस कुछ ऐसा करें (ध्यान दें: कई कार्यान्वयन हैं netcat; मैनुअल की जांच करें सही विकल्प। विशेष रूप से, आपकी इच्छा नहीं हो सकती है -p):

user@dest:/target$ nc -q 1 -l -p 1234 | tar xv

user@source:/source$ tar cv . | nc -q 1 dest-ip 1234

ncपोर्ट 1234 पर एक कच्चे टीसीपी कनेक्शन पर टार भेजने के लिए netcat ( ) का उपयोग करता है। कोई एन्क्रिप्शन, प्रामाणिकता जाँच इत्यादि नहीं है, इसलिए यह बहुत तेज़ है। यदि आपका क्रॉस-कनेक्ट गीगाबिट या उससे कम पर चल रहा है, तो आप नेटवर्क को पेग करेंगे; यदि इसकी अधिकता है, तो आप डिस्क को पेग करेंगे (जब तक कि आपके पास स्टोरेज एरे, या फास्ट डिस्क न हो)। vराल के झंडे यह फ़ाइल नाम प्रिंट के रूप में यह हो जाता है (मोड शब्द) बनाते हैं। बड़ी फ़ाइलों के साथ, यह व्यावहारिक रूप से कोई उपरि नहीं है। यदि आप छोटी फ़ाइलों के टन कर रहे थे, तो आप इसे बंद कर देंगे। इसके अलावा, आप pvप्रगति संकेतक प्राप्त करने के लिए पाइपलाइन में कुछ डाल सकते हैं :

user@dest:/target$ nc -q 1 -l -p 1234 | pv -pterb -s 100G | tar xv

आप निश्चित रूप से अन्य चीजों को भी सम्मिलित कर सकते हैं, जैसे gzip -1(और zप्राप्त अंत zपर ध्वज जोड़ें- भेजने वाले छोर पर ध्वज 1 से अधिक उच्च संपीड़न स्तर का उपयोग करेगा, जब तक कि आप निश्चित रूप से GZIP पर्यावरण चर सेट नहीं करते हैं)। हालांकि gzip शायद वास्तव में धीमी होगी, जब तक कि आपका डेटा वास्तव में संकुचित न हो।

यदि आपको वास्तव में rsync की आवश्यकता है

यदि आप वास्तव में केवल उस डेटा के एक छोटे से हिस्से को स्थानांतरित कर रहे हैं जो बदल गया है, तो rsync तेज हो सकता है। आप वास्तव में तेज़ नेटवर्क (जैसे क्रॉस-कनेक्ट) के साथ -W/ --whole-fileविकल्प को देख सकते हैं, जो तेज़ हो सकता है।

Rsync चलाने का सबसे आसान तरीका ssh है। आप ssh सिफर्स के साथ प्रयोग करना चाहते हैं, यह देखने के लिए कि यह सबसे तेज़ है, यह AES, ChaCha20 या ब्लोफ़िश होगा (हालांकि ब्लोफ़िश के 64-बिट ब्लॉक आकार के साथ कुछ सुरक्षा चिंताएं हैं), इस पर निर्भर करता है कि क्या आपकी चिप में इंटेल का AES है -NI निर्देश (और आपका OpenSSL उनका उपयोग करता है)। एक नए पर्याप्त ssh पर, rsync-over-ssh इस तरह दिखता है:

user@source:~$ rsync -e 'ssh -c [e-mail]' -avP /source/ user@dest-ip:/target

पुराने ssh / sshd के लिए, aes128-ctrया aes128-cbcके स्थान पर प्रयास करें [e-mail]।

ChaCha20 होगा [e-mail](एक नए पर्याप्त ssh / sshd की भी आवश्यकता होगी) और ब्लोफ़िश ब्लोफ़िश-सीबीसी होगी। ओपनएसएसएच एक सिफर के बिना चलने की अनुमति नहीं देता है। आप निश्चित रूप से जो भी आप की जगह की तरह rsync विकल्प का उपयोग कर सकते हैं -avP। और निश्चित रूप से आप दूसरी दिशा में जा सकते हैं, और स्रोत मशीन (पुश) के बजाय गंतव्य मशीन (पुल) से rsync चला सकते हैं।

Rsync अधिक तेज़ बनाना

यदि आप rsync डेमॉन चलाते हैं, तो आप क्रिप्टो ओवरहेड से छुटकारा पा सकते हैं। सबसे पहले, आप एक डेमॉन कॉन्फ़िगरेशन फ़ाइल ( /etc/rsyncd.conf) बनाएंगे , उदाहरण के लिए स्रोत मशीन पर (विवरण के लिए rsyncd.conf मैनपेज पढ़ें):

[big-archive]
    path = /source
    read only = yes
    uid = someuser
    gid = somegroup

फिर, गंतव्य मशीन पर, आप दौड़ेंगे:

user@dest:~$ rsync -avP source-ip::big-archive/ /target

आप इसे दूसरे तरीके से भी कर सकते हैं (लेकिन निश्चित रूप से आपको केवल पढ़ने के लिए सेट करने की आवश्यकता होगी)। प्रमाणीकरण आदि के लिए विकल्प हैं, विवरण के लिए मैनपेज की जांच करें।

Comments

यह एक उत्कृष्ट उत्तर है। दूसरा भी महान है। क्या कोई स्वीकृत उत्तर सिर्फ इसलिए नहीं है क्योंकि पूछने वाला उनके बीच चयन नहीं कर सकता है?

— सूदो

netcatदृष्टिकोण कितना मजबूत है ? यदि नेटवर्क पैकेट गिराता है, तो ऐसा लगता है जैसे यह फाइलों के यादृच्छिक भागों को खो देगा।

— सूदो

@sudo यह TCP का उपयोग कर रहा है, जो आवश्यकतानुसार पुनःप्रकाशित होगा। तो यह पैकेट के नुकसान के खिलाफ ठीक होना चाहिए, यादृच्छिक भ्रष्टाचार (हद तक टीसीपी और ईथरनेट चेकसम इसे पकड़ते हैं), आदि, बेशक, यह एसश पर सुरंग बनाने जैसे हमले के खिलाफ सुरक्षित नहीं है।

— derobert

@ आप इसे एक ही बार में कर सकते हैं, teeचेकसमों की गणना करने के लिए दोनों तरफ पाइप में कुछ कमांड डालें ।

— derobert

@ TheStoryCoder tarभाग में स्थित डॉट इसे वर्तमान निर्देशिका करने के लिए कह रहा है। यह वास्तव में ncकमांड का हिस्सा नहीं है , टार का उपयोग टार्क आर्काइव बनाने के लिए किया जा रहा है, जिसे netcat में पाइप किया जा रहा है (और दूसरी तरफ, netcat को संग्रह निकालने के लिए टार में पाइप किया जा रहा है)। मैं डर एक टिप्पणी पाइप व्याख्या करने के लिए वास्तव में पर्याप्त नहीं है, लेकिन उम्मीद है कि आप आरंभ करने के लिए काफी है ...

— derobert

Answer 2

कैसे? या टीएल; डीआर

मैंने जो सबसे तेज़ तरीका पाया है, वह संयोजन है tar, mbufferऔर ssh।

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

tar zcf - bigfile.m4p | mbuffer -s 1K -m 512 | ssh otherhost "tar zxf -"

इसका उपयोग करके मैंने 1Gb लिंक पर 950 एमबी / एस से अधिक निरंतर स्थानीय नेटवर्क स्थानान्तरण प्राप्त किया है। प्रत्येक टास्क कमांड में पथों को बदलें जो आप स्थानांतरित कर रहे हैं उसके लिए उपयुक्त हो।

क्यूं कर? mbuffer!

एक नेटवर्क पर बड़ी फ़ाइलों को स्थानांतरित करने में सबसे बड़ी अड़चन है, अब तक, डिस्क I / O। इसका उत्तर है mbufferया buffer। वे काफी हद तक समान हैं लेकिन mbufferकुछ फायदे हैं। डिफ़ॉल्ट बफर का आकार 2 एमबी mbufferऔर 1 एमबी के लिए है buffer। बड़े बफ़र्स कभी खाली नहीं होने की अधिक संभावना है। एक ब्लॉक आकार चुनना जो लक्ष्य और गंतव्य फाइल सिस्टम दोनों पर देशी ब्लॉक आकार का सबसे कम सामान्य गुण है, सबसे अच्छा प्रदर्शन देगा।

बफ़रिंग वह चीज़ है जो सभी अंतर बनाती है! यदि आपके पास है तो इसका उपयोग करें! यदि आपके पास यह नहीं है, तो इसे प्राप्त करें! (m}?bufferप्लस का उपयोग करना अपने आप में किसी भी चीज़ से बेहतर है। यह लगभग सचमुच धीमी नेटवर्क फ़ाइल स्थानांतरण के लिए एक रामबाण है।

यदि आप एक से अधिक फ़ाइलों tarको एक ही डेटा स्ट्रीम में "गांठ" करने के लिए स्थानांतरित कर रहे हैं । यदि यह एक एकल फाइल है जिसका आप उपयोग कर सकते हैं catया I / O पुनर्निर्देशन कर सकते हैं । tarबनाम ओवरहेड catसांख्यिकीय रूप से महत्वहीन है इसलिए मैं हमेशा उपयोग करता हूं tar(या zfs -sendजहां मैं कर सकता हूं) जब तक कि यह पहले से ही एक टारबॉल न हो । इनमें से कोई भी आपको मेटाडेटा (और विशेष रूप catसे नहीं होगा) देने की गारंटी है । यदि आप मेटाडेटा चाहते हैं, तो मैं इसे आपके लिए एक अभ्यास के रूप में छोड़ दूँगा।

अंत में, sshपरिवहन तंत्र के लिए उपयोग करना सुरक्षित है और बहुत कम ओवरहेड किया जाता है। फिर, sshबनाम ncका उपरि सांख्यिकीय रूप से महत्वहीन है।

Comments

openssl speedएक i7-3770 पर ~ 126–146 MB / सेकेंड ब्लोफ़िश CBC के लिए और ~ 138–157 MB / AES CBC के लिए सेकंड (इस चिप में AES-NI निर्देश हैं) देता है। फिर ~ 200-300 एमबी / सेकंड के लिए sha256। तो यह सिर्फ मुश्किल से 1 गीगाबिट धक्का दे सकता है। ओपनएसएसएच 6.1+ के साथ, आप एईएस जीसीएम का उपयोग कर सकते हैं, जो यह अंधाधुंध दर (संदेश आकार के आधार पर 370–1320 एमबी / सेकंड) कर सकता है। इसलिए मुझे लगता है कि इसका एकमात्र सच यह है कि अगर आप AES-NI के साथ चिप पर 6.1+ चल रहे हैं और AES-GCM का उपयोग कर रहे हैं, तो OpenSSH का ओवरहेड बहुत कम है।

— derobert

ऊ, मैंने आखिरी मिनट में 6.2+ के बजाय 6.1+ में बदल दिया, जल्दी से फिर से जाँच की। बेशक, यह एक गलती थी, यह 6.1 के बाद से बदलाव है । तो ओपनएसएसएच 6.2+ सही संस्करण है। और यह मुझे अब किसी भी टिप्पणी को संपादित नहीं करने देगा। 5 मिनट से अधिक पुरानी टिप्पणियाँ गलत रहना चाहिए। बेशक, अगर OpenSSH 6.4 से कम है, तो opensh.com/txt/gcmrekey.adv को पैच के बिना देखें , OpenSSH के एईएस-जीसीएम कार्यान्वयन में एक शोषक दोष था।

— derobert

ओवरहेड ssh(या ssh पर rsync) बहुत महत्वपूर्ण है , बहुत महत्वपूर्ण है। मेरे पास एक NAS है जो एक इंटेल एटम सीपीयू का उपयोग करता है। SSH एन्क्रिप्शन ABSOLUTELY TANKS की स्थानांतरण गति है। मुझे आरएसए के लिए लगातार <400 Mbit / sec मिलता है, मैन्युअल रूप से इसे RC4 को ओवरराइड करने पर मुझे ~ 600 Mbit / sec मिल जाता है, और अगर मैं rsync को एक डेमन के रूप में उपयोग करता हूं, तो यह लिंक नेटिव स्पीड (> 900 MBit / sec) पर एक गीगाबिट पर चलता है कनेक्शन)।

— नकली नाम

हालांकि यह सच है कि कई स्थितियों के लिए, परिवहन महत्वपूर्ण नहीं है, इस पर विचार करना बहुत महत्वपूर्ण है, खासकर यदि आप बेहद उच्च अंत हार्डवेयर पर नहीं चल रहे हैं। मेरे मामले में, एटम (यह एक D525 है, दोहरे कोर 1.8 Ghz) एसएमबी के लिए बहुत अधिक गति के साथ, पूरी तरह से ठीक एनएएस के लिए बनाता है, लेकिन एन्क्रिप्शन बिल्कुल इसे मारता है।

— नकली नाम

मुझे mbuffer के पैराड्राइज़ेशन के कारण एक घातक त्रुटि मिलती है: 'mbuffer: fatal: total memory का ब्लॉक साइज \ n से बड़ा होना चाहिए'। सही करने के लिए, मुझे संदेह है कि इसे एमबीबी के लिए खड़े अंतिम 'एम' के साथ 'mbuffer -s 1K -M 512M' जैसा कुछ पढ़ना चाहिए (स्रोत: man mbuffer)

— पीटर लस्टिग

Answer 3

आपको टीसीपी का उपयोग करने की भी आवश्यकता नहीं है। एओई ईथरनेट पर एक एटीए कार्यान्वयन है, परत 2 होने के नाते यह एक निचला-ओवरहेड दृष्टिकोण है जिसमें टीसीपी / आईपी स्टैक का कोई ज्ञान नहीं है। यह आपको कम से कम ओवरहेड के साथ सबसे तेज़ संभव हस्तांतरण प्रदान करेगा। ***

https://en.wikipedia.org/wiki/ATA_over_Ethernet

*** यदि नेटवर्क अड़चन है तो सुनिश्चित करें कि आप संपीड़ित डेटा भेज रहे हैं।

Comments

वाह कि हार्ड कोर है! :) आश्चर्य है कि अगर कोई बेंचमार्क हो ...

— rogerdpack