OpenSolaris के तहत कोई फ़ाइल निकालते समय डिवाइस पर कोई स्थान नहीं है

Question

क्लाइंट बॉक्स पर एक NFS शेयर (एक OpenIndiana सर्वर से निर्यात ) माउंट करने का प्रयास करते समय , OI सर्वर क्रैश हो गया। मुझे मौत की काली स्क्रीन मिल गई, जो लॉग डंप की तरह लग रहा था, फिर सिस्टम ने आराम किया। यह कभी वापस नहीं आया और बूट बंद करने के बाद मुझे निम्न त्रुटि संदेश मिला:

svc.startd[9] Could not log for svc:/network/dns/mulitcast:default: write(30) failed with No space left on device?

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

$ rm filename
cannot remove 'filename' : No space left on device 

मैं "रखरखाव मोड" में लॉगिन कर सकता हूं लेकिन मानक उपयोगकर्ता संकेत नहीं।

का आउटपुट dfहै:

rpool/ROOT/openindiana-baseline    4133493    4133493          0    100%   /
swap                              83097900      11028  830386872      1%   /etc/svc/volatile
/usr/lib/libc/libc_hwcap1.so.1     4133493    4133493          0    100%   /lib/libc.so.1

का आउटपुट mountहै:

/ on rpool/ROOT/openindiana-baseline read/write/setuid/devices/dev:2d9002 on Wed Dec 31 16:00:00 1969
/devices on /devices read/write/setuid/devices/dev:8b40000 on Fri Jul 8 14:56:54 2011
/dev on /dev read/write/setuid/devices/dev:8b80000 on Fri Jul 8 14:56:54 2011
/system/contract on ctfs read/write/setuid/devices/dev:8c40001 on Fri Jul 8 14:56:54 2011
/proc on proc read/write/setuid/devices/dev:8bc0000 on Fri Jul 8 14:56:54 2011
/etc/mnttab on mnttab read/write/setuid/devices/dev:8c80001 on Fri Jul 8 14:56:54 2011
/etc/svc/volatile on swap read/write/setuid/devices/xattr/dev:8cc0001 on Fri Ju8 14:56:54 2011
/system/object on objfs read/write/setuid/devices/dev:8d00001 on Fri Jul 8 14:6:54 2011
/etc/dfs/sharetab on sharefs read/write/setuid/devices/dev:8d40001 on Fri Jul 14:56:54 2011
/lib/libc.s0.1 on /usr/lib/libc/libc_hucap1.s0.1 read/write/setuid/devices/dev:d90002 on Fri Jul 8 14:57:06 2011 

'Zfs सूची -t सब' का आउटपुट है:

rpool                                                       36.4G   0       47.5K   /rpool
rpool/ROOT                                                  4.23G   0         31K   legacy
rpool/ROOT/openindiana                                      57.5M   0       3.99G   /
rpool/ROOT/openindiana-baseline                             61K     0       3.94G   /
rpoo1/ROOT/openindiana-system-edge                          4.17G   0       3.98G   /
rpool/ROOT/openindiana-system-edge@install                  19.9M   -       3 38G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-06-20:45:08      73.1M   -       3.57G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-06-20:48:53      75.9M   -       3 82G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-07-02:14:04      61K     -       3.94G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-07-02:15:14      61K     -       3.94G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-07-02:28:14      61K     -       3.94G   -
rpool/ROOT/openindiana-system-stable                        61K     0       3.94G   /
rpoo1/ROOT/pre_first_update_07.06                           108K    0       3 82G   /
rpool/ROOT/pre_second_update_07.06                          90K     0       3.57G   /
rpool/dump                                                  9.07G   0       9.07G   -
rpool/export                                                3.85G   0       32K     /export
rpool/export/home                                           3.85G   0       32K     /export/home
rpool/export/home/admin                                     3.85G   0       3.85G   /export/home/admin
rpool/swap                                                  19.3G   19.1G   126M    -

Comments

यह फाइलसिस्टम या पूल की तरह दिखता है जहाँ लॉग लिखे जा रहे हैं। सर्वर पर फाइलसिस्टम और डिस्क संगठन क्या है? क्या आप अभी भी सर्वर में लॉग इन कर सकते हैं (आप ऐसा कहते हैं कि नहीं, लेकिन फिर आप कहते हैं कि आपने फ़ाइलों को हटाने की कोशिश की है)? "जब मैं कोशिश करता हूं और कुछ भी डिलीट करता हूं, तो यह मुझे कोई स्थान नहीं देता है" से आपका क्या मतलब है: क्या कमांड आपने ठीक-ठीक टाइप किया है, और आपको क्या सटीक त्रुटि संदेश मिला है?

— गिल्स का SO- बुराई पर रोक '21

आपके सवालों के जवाब देने के लिए अपडेटेड पोस्ट

— निक फैराडे

ठीक। तो कृपया dfऔर का उत्पादन पोस्ट करें mount। आप उस सर्वर के विन्यास के बारे में क्या जानते हैं? विशेष रूप से, इसके लॉगिंग कॉन्फ़िगरेशन के बारे में?

— गाइल्स का SO- बुराई पर रोक '22

अद्यतन और अनुरोधित आउटपुट डेटा को जोड़ा ... एक नज़र लेने के लिए धन्यवाद!

— निक फैराडे

कृपया के उत्पादन में जोड़ेंzfs list -t all

— jlliagre

Answer 1

ठीक है, यह एक अजीब है ... एक फ़ाइल को निकालने के लिए पर्याप्त जगह नहीं है!

यह ZFS के साथ एक अपेक्षाकृत आम मुद्दा है, हालांकि यह संभवतः किसी भी फाइल सिस्टम पर उत्पन्न हो सकता है जिसमें स्नैपशॉट हैं ।

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

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

कुछ स्नैपशॉट को निकालने के लिए अधिक सामान्य रूप से लागू फ़िक्सेस है। आप के साथ स्नैपशॉट सूचीबद्ध कर सकते हैं zfs list -t snapshot। अगर आप किसी विशेष स्नैपशॉट को नष्ट कर देते हैं, तो यह अनुमान लगाने का एक आसान तरीका नहीं है कि कितना स्थान फिर से प्राप्त किया जाएगा, क्योंकि यह जो डेटा स्टोर करता है वह अन्य स्नैपशॉट द्वारा आवश्यक हो सकता है और इसलिए यदि आप उस स्नैपशॉट को नष्ट कर देते हैं तो यह लाइव होगा। इसलिए यदि आवश्यक हो, तो अपने डेटा को किसी अन्य डिस्क पर बैकअप करें, एक या अधिक स्नैपशॉट की पहचान करें जिनकी आपको अब आवश्यकता नहीं है, और चलाएं zfs destroy name/of/snap@shot।

इस OpenSolaris फ़ोरम थ्रेड में इस समस्या की विस्तारित चर्चा है ।

Comments

स्नैपशॉट क्षमता समस्या का कारण नहीं है - नीचे मेरा उत्तर देखें। लेकिन एक स्नैपशॉट जारी करने में सक्षम होने से इसे हल करने में चमत्कार काम कर सकता है, जैसा कि आपने सही तरीके से वर्णित किया है :)

— तातजाना हेसर

Answer 2

कॉपी-ऑन-राइट फाइलसिस्टम के साथ यह एक जाना-माना मुद्दा है: किसी फाइल को डिलीट करने के लिए, फाइलसिस्टम को सबसे पहले ब्लॉक को आवंटित करने और नई स्थिति को ठीक करने से पहले इसे फाइल के भीतर मौजूद स्पेस के धन को जारी करने में सक्षम करने की जरूरत है।

(यह स्नैपशॉट के साथ फाइल सिस्टम की समस्या नहीं है, क्योंकि इन्हें लागू करने के अन्य तरीके कॉपी-ऑन-राइट से अधिक हैं)

निचोड़ के तरीके:

• एक स्नैपशॉट जारी करें (मामले में एक है ...)
• पूल को विकसित करें (यदि कोई अतिरिक्त छोड़ दिया जाए तो आप इसे असाइन कर सकते हैं)
• पूल में एक और फाइल सिस्टम को नष्ट करें, फिर तंग फाइल सिस्टम को विकसित करें
• फ़ाइल को काटें, फिर इसे हटा दें (हालांकि एक बार जब मैं बहुत अधिक तंग हो गया था, तब भी ऐसा करने में सक्षम होने के लिए, ZFS चर्चा में धागा देखें )
• फ़ाइल को अनलिंक करें। (ऊपर की तरह)

मैं कुछ साल पहले एक ही जाल में चला गया, और मुझे मुक्त करने के लिए जारी किए गए किसी भी स्नैपशॉट नहीं थे। जेडएफएस पर थ्रेड देखें जहां इस समस्या पर गहराई से चर्चा की गई थी।

Answer 3

4.Z3G (रुल / रूट USED कॉलम) संदिग्ध है।

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

Comments

फिर जो होना चाहिए था एक '2' नहीं az (OCR'd img)। क्या अजीब है जब मैं cd / rpool करने के लिए वहाँ कुछ भी नहीं है? मुझे नहीं लगता कि "रखरखाव मोड" उचित लिंक बनाते हैं! कुछ भी नहीं / निर्यात में।

— निक फैराडे

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

— जुलैग्रे

Answer 4

मेरे पास वह था और यह जानने की कोशिश में कुछ समय बिताया कि क्या चाहिए। मेरा समाधान फ़ाइलों को हटाने की कोशिश करने से पहले उनकी जगह खाली करना था।

हमारे पास कुछ गलत प्रक्रियाएं हैं जो कभी-कभार पागल हो जाती हैं और डिस्क को कोर फाइलों (एक संख्या में समाप्त) के साथ भर देती हैं इसलिए मैंने एक स्क्रिप्ट तैयार की जिसमें एक कॉपी रखने के लिए कुछ ऐसा होता है।

for file in core*[0-9]
do
    coreFile=${file%.[0-9]*}

    mv $file $coreFile
    if [[ $? == 0 ]]
    then
        chmod 644 $coreFile
    else
        truncate -s 0 $file # we can't just delete if disk is full so zero out first
        rm $file
    fi
done

जब मैंने अपनी स्क्रिप्ट चलाई, तो इसने एक त्रुटि उत्पन्न की:

mv: cannot rename core.200000 to core: No space left on device

और फाइलों को साफ करने के लिए कार्यात्मक था।

इसका परीक्षण करने के लिए मैंने डिस्क को इसके साथ भरा:

for ((ii=0; ii<100000; ii++))
do
    mkfile 1m core.$ii
done