कितना ओवरहेड (%) स्थान को फोटो लाइब्रेरी के लिए एक iPhoto पुस्तकालय की ओर पलायन की आवश्यकता होती है?


5

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

हालाँकि, माइग्रेटिंग वास्तविक चित्रों को साझा कर सकता है लेकिन प्रत्येक कार्यक्रम में विशिष्ट अतिरिक्त संरचना होती है। यह थंबनेल, सूचकांक और अन्य कैश्ड जानकारी से हो सकता है।

उदाहरण के लिए, बाहरी ड्राइव में और 150Gb iPhoto लाइब्रेरी के लिए मुझे कितने अतिरिक्त स्थान की आवश्यकता है?

यह जानना महत्वपूर्ण है कि क्या iPhoto लाइब्रेरी वॉल्यूम में है, आइए 170Gb के साथ कहें। क्या शेष 20Gb फोटो ऐप इंडेक्स के लिए पर्याप्त होगा?

कई मैकबुक एयर उपयोगकर्ताओं के लिए स्थिति विशेष रूप से महत्वपूर्ण है, जिनमें से कई में एसएसडी डिस्क होती है, एक बाहरी ड्राइव में अपने चित्रों को संग्रहीत करते हैं।


जब आप फोटो लिखते हैं, तो क्या आपका मतलब फोटो ऐप है?
jaume

हाँ। मैं इसे संपादित करूँगा।
हेक्टरपाल

अंतरिक्ष आवश्यकताएँ इस बात पर निर्भर करेंगी कि आप कितने फ़ोटो माइग्रेट करने और उनके रिज़ॉल्यूशन की योजना बनाते हैं। वर्तमान iPhotos पुस्तकालय का आकार क्या है?
टोनी एडम्स

जवाबों:


1

ओवरहेड बिल्कुल नहीं।

माइग्रेट करके बनाई गई फ़ोटो लाइब्रेरी "हार्ड लिंक" का उपयोग करती है जो वास्तविक फ़ाइलों की ओर इशारा करती है। इसका कारण यह प्रभावी रूप से ठीक उसी फाइलों को इंगित करता है जो iPhoto लाइब्रेरी में निहित है।

मेरे मामले में, मेरी iPhoto लाइब्रेरी 40 जीबी थी। तो मेरी तस्वीरें पुस्तकालय है। लेकिन मेरे पास केवल 10 जीबी मुफ्त जगह थी। माइग्रेशन करने के बाद, मेरे पास अभी भी 10 जीबी खाली जगह है।

(ध्यान दें कि आप बाद में iPhoto लाइब्रेरी को सुरक्षित रूप से हटा सकते हैं, फ़ाइल सिस्टम काफी स्मार्ट है। https://apple.stackexchange.com/a/182799/172153 देखें ।)


आपका मतलब था कि iPhoto से फ़ोटो में माइग्रेशन के बाद, iPhoto लाइब्रेरी को हटाने से पहले, खाली स्थान की मात्रा में परिवर्तन नहीं हुआ था। क्या तुम नहीं?
हेक्टरपाल

सही बात। लेकिन इसके बाद भी नहीं जब मैंने iPhoto लाइब्रेरी को डिलीट किया।
विम लेर्स

0

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

आप क्या करेंगे देखते हैं - परेशान लग रहे हो सकता है, लेकिन वास्तव में चिंता का विषय नहीं है - कि एक 200GB विभाजन पर जानकारी प्राप्त करें फ़ाइल सामग्री दिखाएगा 270GB होने के लिए ... ड्राइव की तुलना में अधिक के लिए जगह है है!

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

उसके बाद, को हटाने या तो पुस्तकालय स्पष्ट आकार नहीं लेकिन वास्तविक आकार कम हो जाएगा। केवल जब दोनों पुस्तकालयों को हटा दिया जाता है तो पूरे 135GB को खारिज कर दिया जाएगा।


हाँ धन्यवाद। मुझे पता है कि यह कठिन लिंक का उपयोग कर रहा है। (मैं प्रश्न को तदनुसार संपादित करूँगा)। लेकिन आश्चर्य है कि प्रवास के दौरान यह कैसा व्यवहार करता है। शायद कैशिंग इंडेक्स या अन्य संरचनाएं ओवरहेड जोड़ देती हैं। वह कितना है?
hectorpal

प्रवास के दौरान यह कठिन लिंक बनाने में व्यस्त है ... ओवरहेड 'डबल डेटा' जैसा कुछ नहीं होगा
Tetsujin

हां, ओवरहेड डेटा को दोगुना नहीं करेगा। लेकिन अलग-अलग इंडेक्सिंग सिस्टम में अलग-अलग ओवरहेड होते हैं। ज्यादा जगह नहीं होने से वॉल्यूम में माइग्रेट होने पर यह समस्या हो सकती है। सवाल यह है कि कितना पर्याप्त है?
hectorpal

उदाहरण के लिए इस चर्चा को एफएटी से एनटीएफएस में प्रवासन पर पड़ने वाले प्रभाव पर लें। support.microsoft.com/en-us/kb/156560 । वह एक फाइल सिस्टम है। लेकिन इस मामले में चित्रों की अनुक्रमणिका भी है।
हेक्टरपाल

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