मुझे पार्टीशन बेचो


46

मैंने अक्सर सोचा है कि विशेष रूप से यूनिक्स OSes (/ usr, / var, et al) पर विभाजन के लिए ऐसा जुनून क्यों है। यह विंडोज इंस्टॉलेशन के साथ एक सामान्य विषय नहीं लगता है।

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

एक और तर्क मैंने सुना है कि यह बैकअप को सरल करता है। यह बैकअप को सरल कैसे करता है? मैंने यह भी सुना है कि यह विश्वसनीयता में सुधार करता है। फिर से, कैसे?

डिस्क स्टोरेज के साथ आई समस्याओं का लगभग 100% डिस्क की भौतिक विफलता के साथ है। क्या यह तर्क दिया जा सकता है कि विभाजन संभवत: हार्डवेयर विफलता को तेज कर सकता है, क्योंकि एक डिस्क से एक ही डिस्क पर डेटा को एक विभाजन से दूसरे में स्थानांतरित या कॉपी करते समय डिस्क को थ्रेशिंग करता है?

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


इंफ्रास्ट्रक्चर ए सर्विस क्लाउड के रूप में, विभाजन मूट होते हैं क्योंकि ड्राइव (आमतौर पर वॉल्यूम कहा जाता है) को इतनी लचीले रूप से संलग्न किया जा सकता है।
स्कैपरन

जवाबों:


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

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

क्या यह तर्क दिया जा सकता है कि विभाजन संभवत: हार्डवेयर विफलता को तेज कर सकता है, क्योंकि एक डिस्क से एक ही डिस्क पर डेटा को एक विभाजन से दूसरे में स्थानांतरित या कॉपी करते समय डिस्क को थ्रेशिंग करता है?

मुझे बहुत संदेह है कि एक अच्छी तरह से विभाजित प्रणाली विफलता की किसी भी संभावित संभावना-हुड होगी।


9
+1 सुरक्षा और आपदा दोनों तैयारियाँ परतों में की जाती हैं। मुझे एक जहाज में बुलहेड्स के समान विभाजन के बारे में सोचना पसंद है। वे वहां हैं ताकि अगर जहाज के एक सेगमेंट में कुछ भीषण तबाही होती है, तो जरूरी नहीं कि जहाज खतरे में हो। इसलिए जब फाइल सिस्टम में भ्रष्टाचार होता है तो नुकसान कुछ हद तक होता है। इसी तरह सुरक्षा के दृष्टिकोण से अगर / घरों को noexec के रूप में माउंट किया जाता है, तो यह कुछ प्रकार के हमलों को रोक सकता है यदि उपयोगकर्ता खाता उदाहरण के लिए एक कमजोर पासवर्ड से समझौता करता है।
3dinfluence

1
वहाँ जाना जाता है काम कर कारनामे कर रहे हैं केवल पर विभाजन noexec या ro के साथ रखा होगा। असली सुरक्षा विभाजन के उद्देश्य से नहीं है, लेकिन विभाजन नुकसान को सीमित करने में मदद कर सकता है (उदाहरण के लिए (लॉग लॉग बाढ़ आक्रमण)
drAlberT

19

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

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


/ घर की जुदाई एक डेस्कटॉप चीज की तरह लगता है। सर्वर पर डेटा अक्सर किसी अन्य स्थान जैसे / var / www, / srv पर होता है। मैं तर्क दूंगा कि आपका विचार उपयोगकर्ता-डेटा को अलग करने के बारे में अधिक होना चाहिए, जहां यह संग्रहीत है, न कि यदि यह / घर में है।
Zoredache

शेल के खाते रखने के लिए लोगों की एक महत्वपूर्ण संख्या के लिए वैज्ञानिक प्रसंस्करण के लिए इस्तेमाल की जाने वाली मशीनों पर। इस मामले में एक अलग / घर विभाजन काफी उपयोगी हो सकता है।
jay_dubya

यदि आपको मशीनों की एक महत्वपूर्ण संख्या मिल गई है, तो यह अक्सर होता है कि / होम एक फाइलर से एक एनएफएस माउंट है, जो उपर्युक्त मुद्दों के कारण, तार्किक रूप से अपने विभाजन पर / घर है।
मैट सिमंस

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

मुझे लगता है कि डिस्क कोटा और लॉग रोटेशन अंतरिक्ष समस्या का एक बेहतर समाधान है, लेकिन अलग विभाजन एक अच्छा अंतिम उपाय सुरक्षा तंत्र बनाते हैं
अर्ध

13
  • बैकअप को सरल बनाना

आप उन चीज़ों का बैकअप बना सकते हैं, जिन्हें आप चाहते हैं, न कि वे चीज़ें जो आप नहीं करते हैं। डंप (1) टार (1) की तुलना में बेहतर बैकअप सिस्टम है।

  • विभाजन भरना

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

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


9

मुझे हमेशा एक अलग विभाजन पर रखने / var करने के लिए सिखाया गया है ताकि यदि आप नियंत्रण लॉग फ़ाइल से बाहर निकलते हैं तो आप एक ही विभाजन को पूरा ड्राइव नहीं करेंगे। यदि यह बाकी सिस्टम के समान स्थान पर है और आप 100% अपनी पूरी डिस्क को भरते हैं, तो यह दुर्घटनाग्रस्त हो सकता है और एक बुरा पुनर्स्थापना के लिए बना सकता है।


1
मैं अपने 15 साल के एक हाथ पर भरोसा कर सकता हूं (क्या? कहो तो ऐसा नहीं है!) कैरियर की संख्या मैंने एक प्रणाली खो दी है क्योंकि एक रन-वे लॉग फ़ाइल (या जो भी) एक मशीन को नीचे लाया। दूसरी ओर, मैं इस वर्ष अब तक जितनी बार मैंने स्तब्ध किया है, उतनी बार गिन सकता हूं क्योंकि किसी ने निर्णय लिया था कि / var को कभी भी 1GB से बड़ा होने की आवश्यकता नहीं होगी और गलत होगा, जिसने मुझे '00 के दशक' की ओर देखना छोड़ दिया जीबी इन / ऑप्ट, जिनमें से सभी चंद्रमा पर हो सकते हैं सभी अच्छे के लिए यह मुझे करता है। (मैं विभाजन का विरोध कर रहा हूँ। :)
डेविड मैकिन्टोश

मैं डेविड के साथ सहमत हूं, लिनक्स और विंडोज दोनों मशीनों के साथ बिल्कुल एक जैसा अनुभव था। जब तक अन्यथा करने के लिए एक भारी कारण नहीं है अन्यथा प्रत्येक डिस्क (या RAID सरणी) को एक विभाजन मिलता है।
जॉन गार्डनियर्स

खैर, इस हफ्ते यह एक विंडोज सिस्टम पर हुआ। McAfee ने एक बड़ा अपडेट दिया। हमारे पास लगभग 5-10 सिस्टम थे जो इसे पसंद नहीं करते थे। एंटी-वायरस 35MB लॉग फ़ाइल बनाने, और फिर से स्थापित करने का प्रयास करेगा। 1,500 बार बाद में मेरे पास 0KB फ्री था और एक सिस्टम जिसे लॉग इन नहीं किया जा सकता था।
13

8

ज़ॉर्दाचे ने जो तर्क दिए हैं, वे सभी मान्य हैं; एक सा विवरण के साथ वक्रोक्ति कर सकते हैं (एक मशीन तेजी से ऊपर तो आप अन्य चीजें कर सकते हैं, जबकि अन्य फाइल सिस्टम fsck'ing आपको बहुत अच्छा नहीं करता है अगर सिस्टम का कारण पहले स्थान पर मौजूद है, अन्य फाइल सिस्टम पर है) ; हालांकि वे सभी औचित्य के बाद के तथ्य हैं।

वास्तव में पुराने स्कूल के दिनों में, आपके पास अलग-अलग विभाजन पर फाइल सिस्टम नहीं थे - आपने उन्हें अलग-अलग डिस्क पर रखा था, क्योंकि डिस्क वास्तव में बहुत छोटी थी। 10MB सोचो। (1) इसलिए आपके पास एक छोटा / विभाजन, एक / var डिस्क, एक / usr डिस्क, एक / tmp डिस्क, और एक / होम डिस्क है। यदि आपको अधिक स्थान की आवश्यकता है, तो आपने एक और डिस्क खरीदी।

तब "बड़े" 50MB डिस्क पर चंद्रमा कार्यक्रम की तुलना में कम लागत लगने लगी, और अचानक एक स्थान पर एक संपूर्ण सिस्टम को उपयोगकर्ता की उपयोगी राशि के साथ रखना संभव हो गया।

फिर भी, कंप्यूटर को जनरेट करने, अलग-अलग / var और / ऑप्ट और / होम की तुलना में डिस्क के आकार छोटे होने के कारण ताकि भरने के लिए कंप्यूटर नीचे न आए, तब भी यह एक अच्छा विचार था।

आज, एक उद्यम की स्थिति में, मैं ओएस का विभाजन नहीं करता हूं। डेटा का विभाजन हो जाता है, खासकर अगर यह उपयोगकर्ता द्वारा उत्पन्न होता है; लेकिन अक्सर ऐसा इसलिए होता है क्योंकि यह हाई-स्पीड और / या निरर्थक डिस्क सरणियों पर होता है। हालांकि / var और / usr सभी एक ही पार्टीशन में रहते हैं जैसे /।

एक घर के वातावरण में, एक ही चीज़ - / घर शायद एक अलग डिस्क / सरणी पर होना चाहिए, ताकि जो कुछ भी ओएस जायके वांछित हो उसे स्थापित / अपग्रेड / ब्रेक / फिक्स कर सके।

इसका कारण यह है कि कोई फर्क नहीं पड़ता कि आप कितना बड़ा अपने / var या / usr या जो भी पेड़ मिल सकता है - आप या तो प्रफुल्लित करने वाले गलत होंगे या आप हास्यास्पद रूप से अधिक प्रतिबद्ध होंगे। मेरे पुराने (एर) -स्कूल कॉलीग में से एक विभाजन द्वारा कसम खाता है, और मुझे हमेशा उससे दुःख होता है जब वह एक सिस्टम पर 180-दिन-फ़स्क के माध्यम से बैठकर समाप्त होता है जिसे मैंने बनाया है। लेकिन मैं अपने पूरे करियर में किसी एक चीज़ पर भरोसा कर सकता हूं कि किसी चीज के भरे जाने की संख्या कितनी है / और सिस्टम को नीचे लाया, जबकि मैं इस साल अब तक के एक हाथ की गिनती कर सकता हूं कि मैं ऐसे सिस्टम को घूर रहा हूं जहां किसी का तय / var को 1GB से अधिक (कहने) की ज़रूरत नहीं होगी और गलत होगा, जिससे मुझे सिस्टम पर कहीं और पूर्ण / var और el 00s की मुफ्त GB मिल रही है, जो सभी के लिए चाँद पर भी हो सकता है अच्छा वे मुझे करते हैं।

आज बड़े डिस्क की दुनिया में, मैं नहीं देखता कि ओएस ट्री को विभाजित करने का कोई वास्तविक कारण है। उपयोगकर्ता डेटा, हाँ। लेकिन / var / / usr और / var / स्पूल आदि आदि के लिए अलग विभाजन? नहीं।


(1) = और मैं सिर्फ उस आकार को चुनकर जानता हूं, मैं 10 एमबी कहे जाने वाले टिप्पणियों में किसी को प्राप्त करने जा रहा हूं ? विलासिता। हमारे डिस्क केवल क्यों थे ...


वास्तव में 10 एमबी डिस्क का आकार था जब मैंने पहली बार किसी को "XXX FooBytes: मैंने कभी ज़रूरत से ज़्यादा मेमोरी सुनाई थी !"। हालांकि मैं एक नौजवान हूं, इसलिए यह 1982 का था। अन्य मूल्य 40 एमबी, 320 एमबी, 2.5 जीबी, 40 जीबी रहे हैं, ... उपलब्ध संग्रहण को भरने के लिए डेटा का विस्तार होता है।
dmckee

5

प्रतिउत्तर में :

ऐसा लगता है कि विभाजन से एक विभाजन को भरने की संभावना बढ़ जाती है, जबकि अन्य में खाली स्थान का एक बड़ा सौदा होता है।

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

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

उदाहरण के लिए: / dev / sda1 पर एक बूट पार्टीशन बनाएं दूसरा (unformatted) पार्टीशन / dev / sda2 बनाएं

pvcreate /dev/sda2 # add the partition to LVM
vgcreate vg /dev/sda2 # create a volume group with sda2 in it
lvcreate -n root -L5G vg
lvcreate -n home -L10G vg
lvcreate -n downloads -L100G vg

mkfs.ext3 /dev/vg/root
mkfs.ext4 /dev/vg/home
mkfs.xfs /dev/vg/downloads

mount /dev/vg/root /
mount /dev/vg/home /home
mount /dev/vg/downloads /downloads

जब आपको फ़ाइल / सिस्टम चालू होने पर / डाउनलोड पर अधिक स्थान की आवश्यकता हो:

lvresize -L+50G /dev/vg/downloads
xfs_growfs /dev/vg/downloads

और अब आपके पास 150GB डाउनलोड पार्टीशन है। घर के लिए भी ऐसा ही है। वास्तव में मैंने आज एक ext4 lvm "पार्टीशन" का आकार बदला। दूसरी ओर, तार्किक वॉल्यूम वास्तव में विभाजन नहीं हैं और आप जो विभाजन के बारे में कहते हैं वह मेरे व्यक्तिगत अनुभव के साथ गलत आकार में रहता है (वे जितना लायक हैं उससे अधिक परेशानी)।


4

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

अच्छे पुराने दिनों में मेरे विश्वविद्यालय में, यूनिक्स समूहों में मानक यूनिक्स टूल्स के साथ केवल-फाइल सिस्टम थे, और ऐड-ऑन एप्लिकेशन / यूएसआर / स्थानीय थे, जो एक एनएफएस और बाद में एएफएस फाइल सिस्टम था। उस हिस्से में सुविधा थी ... जो क्लस्टर में एक दर्जन बक्से पर सॉफ्टवेयर को फिर से जोड़ना चाहते थे, जब आप एक उच्च गति, 4 एमबी या 10 एमबी नेटवर्क पर ऐप चला सकते थे? आज, सभ्य पैकेज मैनेजर और बहुत सारे सस्ते डिस्क के साथ, यह एक बड़ी बात नहीं है।

मुझे लगता है कि 1999 के आसपास वेरिटास वॉल्यूम मैनेजर के साथ सन बॉक्स पर मेरे लिए प्रक्रियाओं को बदलना शुरू हो गया, जिसने लगभग डिस्क को हिलाने के लिए दर्द की सीमा को कम कर दिया।

आज, जब मैं विभाजन के बारे में सोचता हूं, तो मैं डेटा सुरक्षा और प्रदर्शन के संदर्भ में सोच रहा हूं। उदाहरण उदाहरण:

  • टियर 1 सैन बहुत तेज है, बहुत उपलब्ध है (5 9), दोहराया और बहुत महंगा है। मिशन महत्वपूर्ण डेटाबेस या लेन-देन लॉग वहाँ रहते हैं।
  • टियर 2 सैन तेज, उपलब्ध (4 9) महंगा है। एप्लिकेशन या निम्न प्राथमिकता डेटा यहां रहता है।
  • टियर 3 सैन उपलब्ध है (4 9), सस्ता। सामान जो संवेदनशील जीवन का प्रदर्शन नहीं करता है।

ये विचार विंडोज पर भी लागू होते हैं। हमारे पास एक SCCM सर्वर है जो लगभग 40k क्लाइंट का प्रबंधन करता है। डेटाबेस और लॉग मेगा-हिरन IBM DS8000 डिस्क पर हैं। सॉफ्टवेयर पैकेज बड़े, धीमे SATA डिस्क वाले EMC Celerra पर हैं, जिनकी लागत प्रति जीबी 60% कम है।


2

मैं समझता हूं कि यह सवाल ओएस-विशिष्ट नहीं है, है ना?

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

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

मैंने और अधिक पक्षपात करने की कोशिश की है (जैसे कि GAMES, MUSIC, MOVIES, इत्यादि), लेकिन इसके परिणामस्वरूप उनमें से कुछ दूसरों में बह निकले, जो क्रम से अधिक गड़बड़ पैदा कर रहे थे।


यह सर्वरों पर करते समय और भी अधिक लागू होता है।
SpaceManSpiff

2

(मान लें कि एक बड़ी डिस्क उपलब्ध है,) मैंने "नियंत्रण से बाहर [उपयोगकर्ता | लॉग फ़ाइल] को नियंत्रित करने के लिए अलग-अलग विभाजन पर रखा homeऔर varसभी स्थान को भरने" समस्या, और घर को छूने के बिना आसान ओएस उन्नयन की अनुमति देने के लिए, लेकिन छोड़ दें एक साथ आराम करो।

पुराने हार्डवेयर पर यह bootबीमा करने के लिए एक अलग विभाजन होना आवश्यक था कि कर्नेल छवि बूट लोडर के लिए सुलभ थी।


2

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

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

विश्वसनीयता के लिए, केवल एक चीज जिसके बारे में मैं सोच सकता हूं, वह है निगरानी - मैं अधिक आसानी से देख सकता हूं कि किसी दिए गए विभाजन का विकास उससे अधिक होना चाहिए, और मुझे इसे देखने का कारण दें।

... अब, कहा जा रहा है कि, हम प्रत्येक उपयोगकर्ता के दिनों से बहुत दूर हैं, एक साझा मशीन पर उनके छोटे 20MB कोटा दिया जा रहा है। कुछ पुरानी आदतें समझ में नहीं आती हैं - लेकिन जब आपके पास एक प्रक्रिया होती है, तो पागल हो जाते हैं और भरें / var, जो बदले में / भरता है, और चीजें रुक जाती हैं, यह उत्पादन मशीनों पर होने वाली सुरक्षा का बुरा नहीं है। ।

घर के लिए, मेरे पास विभाजन हैं, लेकिन यह केवल स्थापित ओएस को प्रबंधित करना आसान बनाने के लिए है।


1

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

एक उद्यम वातावरण में मैंने विभाजन के लिए एक सम्मोहक तर्क नहीं सुना है।


1

मॉडरेशन में सब कुछ एक अच्छी बात है - यह एक गलती होने पर समस्याओं को अलग करने का एक अच्छा उपकरण हो सकता है - जैसे डिस्क भरना या फाइलसिस्टम भ्रष्टाचार।

इसे हार्डवेयर विफलता के साथ न मिलाएं - जिन्हें हार्डवेयर अतिरेक (RAID) द्वारा नियंत्रित किया जाना चाहिए

यह कहते हुए कि, इन दिनों फाइल सिस्टम कम बार विफल हो जाता है - यहां तक ​​कि ऑनलाइन अखंडता जांच (जैसे ZFS) भी करते हैं। तो उम्मीद है कि ऑफलाइन fsck कुछ बिंदु पर दूर हो जाएगा ...

दूसरी ओर, ऐसा करने का मतलब केवल अंत में अधिक काम (आपके और आपकी टीम के लिए) है - बस इसे संयम में करें और जब यह समझ में आए ...

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.