LVM प्रदर्शन को प्रभावित करता है?

Question

मुझे लिनक्स में कुछ सर्वरों को माइग्रेट करना है, और एक महत्वपूर्ण पहलू जिसका मुझे मूल्यांकन करना है, वह यह है कि मेरे नए होस्ट सिस्टम में लोचदार भंडारण क्षमता होनी चाहिए। स्वाभाविक रूप से, कुछ बुनियादी शोध करते हुए, मैं LVM के पार आया।

क्या lvm का उपयोग करने के लिए कोई प्रदर्शन दंड है? यदि हां, तो मैं इसे कैसे माप सकता हूं?

अभी जो मैं विचार कर रहा हूं वह है कि एलवीएम के साथ होस्ट ओएस के रूप में लिनक्स है और इसके ऊपर चलने वाले वर्चुअलाइज्ड लिनक्स बॉक्स (क्या मुझे अतिथि ओएस पर भी एलवीएम जोड़ना चाहिए?)।

Answer 1

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

लेकिन ऐसा नहीं है। कर्नेल को पहले से ही मैपिंग (या वास्तव में मैपिंग की कई परतें) की आवश्यकता होती है, जो डिवाइस ड्राइवरों को "इसे एक फ़ाइल में लिखें" जैसे उच्च स्तरीय संचालन को जोड़ता है जो बदले में डिस्क पर वास्तविक ब्लॉकों से जुड़ते हैं।

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

ऐसे मामले हैं जहां LVM प्रदर्शन समस्याओं का कारण बन सकता है। आप यह सुनिश्चित करना चाहते हैं कि LVM ब्लॉक अंतर्निहित सिस्टम के साथ ठीक से संरेखित हैं, जो कि आधुनिक वितरण के साथ स्वचालित रूप से होना चाहिए। और सुनिश्चित करें कि आप पुराने कर्नेल का उपयोग नहीं कर रहे हैं जो इस तरह के बग के अधीन हैं । ओह, और LVM स्नैपशॉट का उपयोग करने से प्रदर्शन में गिरावट आती है (और प्रत्येक सक्रिय स्नैपशॉट के साथ ऐसा बढ़ता है)। लेकिन ज्यादातर, प्रभाव बहुत छोटा होना चाहिए।

आखिरी के लिए: आप कैसे परीक्षण कर सकते हैं? मानक डिस्क बेंचमार्किंग टूल बोनी ++ है । एलवीएम के साथ एक विभाजन करें, इसका परीक्षण करें, इसे मिटा दें और (उसी स्थान पर, अन्य कारकों को समान रखने के लिए) एक सादा फाइल सिस्टम और बेंचमार्क बनाएं। उन्हें समान के करीब होना चाहिए।

Answer 2

LVM, सब कुछ की तरह, एक मिश्रित आशीर्वाद है।

प्रदर्शन के संबंध में, LVM आपको थोड़ा सा बाधा देगा क्योंकि यह एब्सट्रैक्शन की एक और परत है जिसे डिस्क को हिट करने से पहले काम करना पड़ता है (या डिस्क से पढ़ा जा सकता है)। ज्यादातर स्थितियों में, यह प्रदर्शन हिट व्यावहारिक रूप से अचूक होगा।

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

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

मेरे लिए, LVM का उपयोग नहीं करने का एकमात्र कारण यह है कि आपदा वसूली अच्छी तरह से परिभाषित नहीं है (या कम से कम, नहीं थी)। LVM संस्करणों के साथ एक डिस्क जिसमें उस पर एक स्कैम्ड ओएस था, उसे तुच्छ रूप से दूसरे कंप्यूटर से जोड़ा नहीं जा सकता था और उससे प्राप्त डेटा; LVM वॉल्यूम को पुनर्प्राप्त करने के कई निर्देशों में समय में वापस जाने और vgcfgbackup चलाने जैसे चरण शामिल थे, फिर परिणामित / etc / lvmconf फ़ाइल को आपके hosed वॉल्यूम को होस्ट करने वाले सिस्टम में कॉपी करें । उम्मीद है कि तीन या चार वर्षों में चीजें बदल गई हैं क्योंकि मुझे आखिरी बार इस पर ध्यान देना था, लेकिन व्यक्तिगत रूप से मैं इस कारण से कभी भी एलवीएम का उपयोग नहीं करता।

ने कहा कि।

आपके मामले में, मुझे लगता है कि मेजबान प्रणाली की तुलना में VMs अपेक्षाकृत छोटे होने जा रहे हैं। इसका मतलब यह है कि आप बाद में एक वीएम में भंडारण का विस्तार करना चाहते हैं; यह VM में एक और वर्चुअल डिस्क जोड़कर और फिर प्रभावित VM फाइल सिस्टम को बढ़ाकर सबसे अच्छा है। आपके पास फैले-एकाधिक-डिस्क भेद्यता नहीं है क्योंकि वर्चुअल डिस्क होस्ट सिस्टम पर समान भौतिक डिवाइस पर होने की संभावना होगी।

यदि वीएम आपके लिए बिल्कुल भी महत्व नहीं रखते हैं, तो आप किसी भी तरह से मेजबान सिस्टम को RAID'ing करेंगे, जो बाद में बढ़ते भंडारण के लिए लचीलेपन को कम करेगा। इसलिए LVM के लचीलेपन की आवश्यकता नहीं है।

इसलिए मुझे लगता है कि आप होस्ट सिस्टम पर LVM का उपयोग नहीं करेंगे, लेकिन VMM को LVM का उपयोग करने के लिए स्थापित करेंगे।

Comments

@ डीडीएम - आपको लगता है कि LVM2 भौतिक मात्रा md-RAID सहित किसी भी ब्लॉक डिवाइस हो सकती है, का उल्लेख करते हुए छोड़ दिया है। IE: अंतर्निहित RAID प्रकार / देव / md0 की परवाह किए बिना pvcreate / dev / md0। इसलिए यदि आपका / dev / md0 दर्पण की शारीरिक बनावट का एक RAID सरणी है ... यह आपके LVM2 समूह को प्रभावित करने के लिए एक एकल भौतिक ड्राइव के नुकसान के लिए कठिन है। इसके अलावा: आप RAID सरणी बनाते समय मीडिया पक्ष के रूप में LVM2 तार्किक आयतन का उपयोग कर सकते हैं। दोनों डिवाइस मैपर स्तर पर काम करते हैं, दोनों डिवाइस-इन / डिवाइस-आउट लेयर हैं।

आपके पुनर्प्राप्ति संबंधी चिंताएं अत्यधिक हैं, यह कंप्यूटर के बीच एक lvm सरणी को स्थानांतरित करने के लिए तुच्छ है, जो हाल ही में लिनक्स डिस्ट्रो (यानी डेबियन पुराना होने योग्य नया पर्याप्त है) के साथ

— hildred

@ user13719: हां, आप किसी भी ब्लॉक डिवाइस को LVM कर सकते हैं, लेकिन व्यवहार में लोग ऐसा नहीं करते हैं। वे एक एकल ड्राइव LVM'd के साथ समाप्त होते हैं। फिर वे एक और ड्राइव जोड़ते हैं, और नई डिस्क पर मौजूदा फ़ाइल सिस्टम का विस्तार करने के लिए LVM का उपयोग करते हैं। उस बिंदु पर, या तो डिस्क की विफलता LVM को मार देगी।

— डेविड मैकिन्टोश

@ निस्संदेह, उपरोक्त वह है जिसका मैं उल्लेख कर रहा था - मुझे ऐसे किसी भी उपकरण के बारे में पता नहीं है जो LVM से डेटा को पुनर्प्राप्त कर सकता है जो एक डिस्क के साथ कई डिस्क (ब्लॉक डिवाइस) को फैलाता है।

— डेविड मैकिन्टोश

यह कहने जैसा है कि चाकू खराब हैं क्योंकि हो सकता है कि आप अपने आप को उन्हें जकड़ते समय काट लें ... यह कैसे नहीं कर रहा है? उन्हें उन कार्यों के लिए उपयोग करें जो वे बेहतर हैं, जैसे कि वेजी काटना।

— चिनोटो वोक्रो

Answer 3

सामान्य तौर पर: यदि आप जटिलता की एक नई परत जोड़ते हैं ("उर्फ मोर टू डू") कुछ भी तेज नहीं होगा। नोट: आप केवल काम को जोड़ते हैं और 'परिवर्तन' नहीं करते हैं, जिस तरह से काम किया जाता है।

आप कुछ कैसे माप सकते हैं? ठीक है, आप LVM के साथ एक विभाजन बनाते हैं और एक बिना, फिर एक सामान्य बेंचमार्क का उपयोग करते हैं और इसे चलाते हैं। पर लोगों की तरह

http://www.umiacs.umd.edu/~toaster/lvm-testing/

जैसा कि लगता है, केवल गति पर थोड़ा प्रभाव। बेंचमार्क चलाने वाले किसी और व्यक्ति के निष्कर्षों के साथ तालमेल से ऐसा लगता है:

"एक्सएम 4 एलवीएम के बिना, और अन्य फाइल सिस्टम बेंचमार्क के साथ तेज है" लिनक्स कर्नेल मेलिंग लिस्ट थ्रेड

लेकिन इसे अपने आप ही बेंचमार्क करें और देखें कि क्या आपका हार्डवेयर और ओएस आप एक ही व्यवहार करना चाहते हैं और यदि आप जटिलता की एक अतिरिक्त परत के प्रभाव (शायद थोड़ा) के प्रभाव को अनदेखा कर सकते हैं जो आपको लोचदार भंडारण देता है।

क्या आपको अतिथि OS में LVM जोड़ना चाहिए: यह इस बात पर निर्भर करता है कि क्या आपको अतिथि OS की आवश्यकता है, साथ ही लोचदार भंडारण की भी? आपकी जरूरतों को तय करना है कि आपको क्या करना है।

Comments

@ सिरिया, उफ़, यह स्थानांतरित हो गया है

— hildred

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

— mattdm 16

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

— अकीरा

जिस बिंदु पर मैं "ड्राइविंग कर रहा हूं" वह यह है कि " नोट: आप केवल काम जोड़ते हैं, न कि वे 'परिवर्तन' करते हैं जिस तरह से काम किया जाता है " यह एक तथ्यात्मक कथन नहीं है।

— Mattdm

@mattdm: यह स्पष्ट है, कि यदि आप कार्य करने के तरीके को बदलते हैं (जैसे, एक अन्य एल्गोरिथ्म, एक और fs आदि), तो आप फिर अलग परिणाम प्राप्त करेंगे। lvm fs के काम करने के तरीके को नहीं बदल रहा है। आप जानते हैं कि। और यही कारण है कि मैं सोच रहा हूं कि वास्तव में आपकी बात क्या है? "किसी चीज़ की एक परत जोड़ें" का अर्थ है "जोड़ना", न कि "दूसरी चीज़ को बदलना"। आप भी जानते हैं।

— अकीरा

Answer 4

क्या मुझे अतिथि OS पर LVM भी जोड़ना चाहिए?

होस्ट लॉजिकल वॉल्यूम के अंदर ext3 या ext 4 फ़ाइल-सिस्टम होने के कारण आपको पर्याप्त नहीं होना चाहिए। इसके अंदर एक और वॉल्यूम ग्रुप और फिजिकल वॉल्यूम और लॉजिकल वॉल्यूम जोड़ने की जरूरत नहीं है।

Answer 5

केवल lvm से बहुत अधिक प्रदर्शन नहीं होगा, लेकिन यदि आप इसे लेने के लिए तैयार हैं, तो इसके बजाय zfs का उपयोग करें। आपको वॉल्यूम प्रबंधन और पुनर्प्राप्ति और अन्य सभी शानदार सुविधाएँ मिलती हैं।

Comments

ZFS के साथ एक मुद्दा यह है कि यह विभिन्न गति और आकारों के भौतिक संस्करणों को अच्छी तरह से नहीं संभालता है।

— गेब्रियल फेयर

इसे संभाल नहीं है ... अभी तक। और यह तब होता है जब आप उन्हें उचित रूप से व्यवस्थित करते हैं। मैं नहीं देखता कि lvm किसी भी बेहतर कैसे करता है।

— stu

Answer 6

कोई भी उल्लेख lvm2 पढ़ने और लिखने की गति को गुणा नहीं कर सकता (raid0 के समान)। मैं व्यक्तिगत रूप से 3 समान डिस्क का उपयोग करता हूं और उन पर lvm2 को छीन लिया गया मोड में, पढ़ने और लिखने के संचालन में 1/3 समय लगता है, थैस एक बड़ा प्रभाव है, फाइलसिस्टम इसके ऊपर तीन ती तेज है। मुझे पता है: कोई भी डिस्क विफल है और उन पर सभी डेटा accesible नहीं होंगे; लेकिन इसका मतलब यह नहीं है कि कोई भी खोया हुआ नहीं है, क्योंकि BackUPs एक MUST हैं, RAID, LVM2, ZFS जैसा कुछ भी नहीं है, जो कि बैकयूपी होने से बचेंगे; इसलिए मैं कभी भी मिररिंग, छापे 5 और इस तरह का उपयोग नहीं करता, मैं एलीवेज़ स्ट्रिपिंग (सबसे अधिक प्रदर्शन पाने के लिए) का उपयोग करता हूं और पीयूपी को सिंक करता हूं। ZFS, ऑन-द-फ्लाई कम्प्रेशन के लिए बहुत अच्छा है, और कॉपियों के पैरामीटर एक से बड़ा है जैसा कि मिररिंग है, लेकिन एक चीज़ जो ZFS के पास है और किसी और के पास नहीं है वह है ऑटो-रिकवरी ऑन-द-फ्लाई बिट रोट (बिट्स जो अनायास बदल जाते हैं) डिस्क संचालित है),

फिर से शुरू करने के लिए: मैं बाहरी डिस्क पर मेरे बैकअप के लिए केवल ZFS का उपयोग करता हूं, कई (दो या तीन) ssd के साथ lvm2 ओएस के लिए धारीदार (aftwr उन्नयन मैं ओएस के क्लोन को फिर से परिभाषित करता हूं), मैं अयोग्य ओएस का उपयोग करता हूं; और मैं वर्चुअल मशीनों की तरह, डेटा के लिए छीनी गई lvm2 के साथ मल्टीपल (छह) स्पिनिन डिस्क का उपयोग करता हूं, फिर से किसी भी बदलाव को फिर से करता हूं I बैकअप; इसलिए किसी भी डिस्क के विफल होने के बाद मुझे केवल इसे बदलने और अंतिम बैकअप को पुनर्स्थापित करने की आवश्यकता है; अब मेरे पास 1.8GiB / s लिखने की गति है, इसलिए BackUP से एक वर्चुअल मशीन को पुनर्स्थापित करने में केवल 30 सेकंड (32GiB प्रति वर्चुअल मशीन डिस्क) से कम समय लगता है।

तो मेरा जवाब है: केवल एक चीज का उपयोग न करें, स्मार्ट बनें और प्रत्येक भाग का सर्वश्रेष्ठ उपयोग करें, lvm2 छीन लिया mdraid स्तर 0 की तुलना में तेज है, छह कताई डिस्क का उपयोग करते समय अधिक; स्ट्रिपिंग ssd के साथ एक चेतावनी, दो और तीन अच्छे हैं, चार ssd प्रदर्शन को कम कर सकते हैं (मेरे परीक्षणों ने कम लिखने की गति दी जब मैंने स्ट्रिप्ड मोड में चार समान ssd का उपयोग किया, तो कोई बात नहीं अगर lvm, mdraid0, आदि), SSD TRIM और ऐसा लगता है लिखने का प्रवर्धन, छीनी गई मात्रा में अधिक sdd जोड़ने का मुख्य कारण निम्न लेखन गति बना सकता है।

एसएसडी के साथ युद्ध करना, और किसी भी छापे (संस्करणों) को छीन लेना, चीजों को पूरी तरह से संरेखित करना, फाइल सिस्टम पर क्लस्टर आकार को सही ढंग से असाइन करना, आकार को आकार देना, आदि इसलिए कोई भी गिरावट का कारण नहीं बनता है; नमूना के रूप में: डिस्क सेक्टर 2048 है, इसलिए किसी भी रीड / राइट पर 2K को मिनिमन के रूप में पढ़ें, कभी भी एक फाइल सिस्टम का उपयोग न करें जो 512 बाइट्स क्लूसर का उपयोग करता है, उस पर, 2K या 4K क्लस्टर आकार का उपयोग करना बेहतर है; अब कल्पना कीजिए कि आप 3xHDD, 2K सेक्टरों में से प्रत्येक का उपयोग करते हैं, इसलिए किसी भी पढ़ने / लिखने के लिए ऑप्टिमन फाइल सिस्टम क्लस्टर 3x2K = 6K होगा, लेकिन यह कई फाइल सिस्टम पर संभव नहीं है, तो सोचें कि 64K क्लस्टर आकार, 64K / 6K = 32 का उपयोग करें तो क्या होगा / 3, जो असंतुलित का कारण बनता है, इसलिए इष्टतम नहीं है, और इसी तरह। इष्टतम क्लस्टर आकार प्राप्त करने के लिए गणित करें।

मेरे सबसे अच्छे परिणाम हैं: क्लस्टर आकार = स्ट्राइप पर * डिस्क की संख्या; इस तरह से प्रत्येक रीड / राइट सटीक आकार का है जो सभी डिस्क को काम करने का कारण बनता है, इसलिए गति में सुधार rrally बढ़िया है। 64K धारी आकार के साथ 3 डिस्क के लिए एक उदाहरण 192K क्लस्टर आकार; 32K धारी आकार के साथ 6 डिस्क के लिए एक और उदाहरण 192K क्लस्टर आकार।

और Allways 4K, 8K, 16K, 32K, 64K ब्लॉक में सिंगल डिस्क का परीक्षण करना याद रखता है; बहुत सारे डिस्क 4K की तरह कम संख्या के साथ वास्तव में खराब गति देते हैं, लेकिन 64K, 128K या अधिक होने पर दस गुना अधिक तेज समय देते हैं।

हां, बड़े क्लस्टर आकारों का उपयोग करने से प्रत्येक फ़ाइल के लास क्लस्टर पर जगह की बर्बादी का नुकसान हो सकता है (यदि आप केवल 1 बाइट प्रत्येक की लाखों फ़ाइलों का उपयोग करते हैं) बेहतर फ़ाइल / सिस्टम पर एक कॉम्पैक्ट / पैक ऑन-द-फ्लाई सिस्टम का उपयोग करें, एक नमूने के रूप में एक 4K क्लस्टर आकार के साथ एक 4TiB डिस्क में 1Byte प्रत्येक की 4TiB / 4K = 1073741824 से कम फ़ाइलें हो सकती हैं, यह केवल 1GiB है यदि सभी फाइलें 1Byte आकार (क्लस्टर आकार 4K), बड़े क्लस्टर आकार का सबसे खराब अनुपात है, लेकिन यदि फ़ाइलें बहुत बड़ी हैं, जैसे कि वर्चुअल मशीन (एक नमूने के रूप में 32GiB के पास, या बस कुछ मेगाबाइट्स) खो जाने पर केवल अंतिम क्लस्टर पर होता है; इतनी बड़ी फाइलें, बड़ा क्लस्टर आकार प्रदर्शन के लिए बहुत बेहतर है, लेकिन सावधान रहें कि वर्चुअल मशीन इसका उपयोग कैसे करती है।

कोई भी आपको यह रहस्य नहीं बताएगा: अतिथि के अंदर 4K क्लस्टर आकार का उपयोग नहीं करते हैं, उसी क्लस्टर आकार का उपयोग करें जैसे कि क्लस्टर आकार वर्चुअल डिस्क रहता है, या इसमें से एक से अधिक है।

हां, मैं अतिथि डिस्क के अंदर शीर्ष सबसे अधिक गति प्राप्त करने का उन्मत्त हूं, जैसा कि मैंने कहा कि 6 घूर्णन डिस्क के साथ मुझे 1.7GiB / s के पास मिलता है, SATA III बस की गति अड़चन है, डिस्क स्वयं नहीं। मैं उच्च अंत (सस्ते नहीं) डिस्क का उपयोग करता हूं, प्रत्येक 283MiB / s की गति के साथ 128MiB कैश।

आपके और सभी लोगों के लिए: यह सीखने के लिए सबसे अच्छा है कि किसी भी गति परीक्षण से पहले क्लस्टर आकार, पट्टी का आकार और ब्लॉक आकार कैसे संबंधित होना चाहिए, LVM2 या किसी अन्य RAID (ZFS) का परीक्षण भी FALSE निष्कर्ष दे सकता है।

इस तरह के लिए एक नमूना: मैं 2x60MiB / s 2.5 इंच 5400rpm के साथ अपने लिनक्स बूट समय का परीक्षण करता हूं, Sata II पोर्ट मेनबोर्ड पर Sata डिस्क, और फिर 2xSSD Sata III के साथ परीक्षण (वे 250MiB / s से अधिक लिख सकते हैं यदि प्रत्येक Sata III से जुड़ा हो बंदरगाहों), बूट समय केवल दो सेकंड कम लेता है, पांच मिनट बूट पर सिर्फ दो सेकंड, क्यों? क्योंकि अधिकांश बूट समय डिस्क का उपयोग नहीं किया जा रहा है, यह राम और सीपीयू पर काम कर रहा है, लेकिन मैं / ओ नहीं।

ऑलवेज परीक्षण वास्तविक दिन की चीज है जो आप करेंगे, न कि केवल क्रूड स्पीड (दूसरे शब्दों में, अधिकतम गति)।

अधिकतम गति बिट का प्रतिनिधित्व करने योग्य नहीं होने के लिए अच्छा है, आप अधिकतम गति 100% समय पर डिस्क का उपयोग नहीं कर सकते हैं, ओएस और एपीपी को I / O के बिना राम और सीपीयू पर चीजें करनी चाहिए, इसलिए उस समय डिस्क की गति नहीं होती है बात बिल्कुल।

सभी लोग कहते हैं कि एसएसडी बहुत सारे विंडोज बूट की गति में सुधार करता है, मेरे परीक्षणों पर यह भी FALSE है, यह केवल मैं एक ईगथ मिनट के करीब बूट समय पर 28 सेकंड साबित होता है।

इसलिए अगर आप मुझे पसंद करते हैं: बूट पर लिनक्स कॉपी-टू-रैम, SSD HDDs को घुमाने के बजाय दांव पर नहीं लगाया जाएगा, मैंने USB 3.1 Gen2 स्टिक (139MiB / s रीड) का भी परीक्षण किया था, बूट समय केवल कुछ सेकंड पर ही अंकित हो जाता है पांच मिनट का बूट, क्यों? आसान है, रीड तब ​​किया जाता है जब RAM पर कॉपी किया जाता है, डिस्क / ssd / usb- स्टिक की तुलना में फिर से बोल्ट के बाकी हिस्सों पर उपयोग नहीं किया जाता है, डेटा रैम पर होता है, जैसे RAM-ड्राइव।

अब मैं अपने सभी एसएसडी बेच रहा हूं, वे बूट पर लिनक्स कॉपी-ऑन-राम में सुधार नहीं करते हैं, लेकिन बेंचमार्किंग उन्हें कहते हैं कि वे 5x गुना तेज हैं ... देखें, बेंचमार्क FALSE निष्कर्ष देता है ... yest, परीक्षण और परीक्षण वास्तविक दिन का काम।

आशा है कि यह पुरुष चीजों को स्पष्ट कर सकता है ... खराब क्लस्टर और धारी के आकार वाले एलवीएम परत के ऊपर की तुलना में बहुत अधिक प्रभावित करते हैं।