लाखों फ़ाइलों को हटाना

Question

मैंने लाखों gif चित्रों के साथ एक dir भरा था। Rm कमांड के लिए बहुत सारे।

मैं इस तरह खोजने की कोशिश कर रहा हूँ:

find . -name "*.gif" -print0 | xargs -0 rm

समस्या यह है कि यह मेरी मशीन को वास्तव में खराब करता है, और ग्राहकों के लिए समय का कारण बनता है क्योंकि यह एक सर्वर है।

क्या कोई तरीका है जो इन सभी फ़ाइलों को हटाने के लिए तेज है ... मशीन को लॉक किए बिना?

Comments

मैं नीचे "अच्छा खोज" कमांड का उपयोग करके लगभग 6 gb / hr विलोपन दर पर हूँ। संभवतः सभी फ़ाइलों से छुटकारा पाने के लिए सीधे 48 घंटे लगेंगे। ऐसा होने का कारण b / ca scour script विफल रहा था। मैं इससे आगे निकल गया था। rm कमांड के साथ "इवेंट क्षितिज", फिर वह भाग गया।

पूरे डायर को हटाने से बहुत जल्दी नहीं होगा? बस "अच्छी" फ़ाइलों को बाहर निकालने से पहले बचे हुए लोगों को

— निकाल लें

खैर, हर फाइल अभी खराब है, क्योंकि इसे / dir_old में स्थानांतरित किया गया था, और मैंने / dir को रीमेक किया। लेकिन rmdir rm * के समान सीमा में नहीं चलेगा?

@Corepuncher: मैं उम्मीद होती है कि पूरी निर्देशिका (हटाने के साथ के रूप में rm -rfतेजी से हो सकता है यह एक कोशिश के लायक

— जेसन आर

मैं वर्तमान में dir पर "rm -rf" चला रहा हूं। यह 20 मिनट से अधिक समय से चल रहा है ... डिस्क आकार में अभी तक कोई बदलाव नहीं हुआ है। लेकिन यह भी स्वचालित रूप से "तर्क सूची बहुत लंबे समय तक" वापस नहीं आया। केवल समस्या यह है, यह वास्तव में मेरी मशीन को हथौड़ा दे रहा है और अन्य चीजों को धीमा / विफल बना रहा है। निश्चित नहीं है कि इसे कब तक चलने दिया जाए।

Answer 1

जल्दी जरूरी नहीं है कि आप क्या चाहते हैं। आप वास्तव में धीमी गति से चलाना चाह सकते हैं , इसलिए हटाते समय कम संसाधन कम हो जाता है।

कमांड की प्राथमिकता कम करने के लिए अच्छा (1) का उपयोग करें ।

nice find . -name "*.gif" -delete

I / O- बाउंड प्रक्रियाओं के लिए अच्छा (1) पर्याप्त नहीं हो सकता है। लिनक्स शेड्यूलर I / O को ध्यान में रखता है, न केवल CPU, लेकिन आप I / O प्राथमिकता पर बेहतर नियंत्रण चाहते हैं।

ionice -c 2 -n 7 find . -name "*.gif" -delete

यदि वह ऐसा नहीं करता है, तो आप वास्तव में इसे धीमा करने के लिए एक नींद भी जोड़ सकते हैं।

find . -name "*.gif" -exec sleep 0.01 \; -delete

Comments

वाह ... .1 s की नींद के साथ लाखों फाइलें ... 864000 फाइलों के लिए एक दिन चाहिए।

— ग्लोगल

@glglgl सब ठीक है, स्मार्ट गधा। मैंने टाइमआउट बदल दिया। :-P

— जॉन कुगेलमैन

नींद एक अच्छा विकल्प हो सकता है, लेकिन अच्छा नहीं होगा, क्योंकि यहां कार्य IO बाध्य है, सीपीयू बाध्य नहीं है; आप इसके बजाय आयनिस की कोशिश कर सकते हैं। ध्यान दें कि यदि नींद बहुत छोटी है तो यह बेकार हो जाएगा।

— मट्टियो इटालिया

@glglgl: बिंदु यह है कि यदि आप सर्वर पर सेवा व्यवधान पैदा नहीं करना चाहते हैं तो आपको धीरे-धीरे जाना होगा, जिस समय यह कोड सोता है वह सर्वर को डिस्क के साथ वास्तव में उपयोगी काम करने देता है।

— मट्टियो इटालिया

+1 करने के sleepअलावा - मुझे उपयोग करने के बावजूद IO पर चोक करने वाले सर्वरों से परेशानी हो रही थी ionice -c 3। यह फ़ाइलों को साफ़ करने में लगने वाले समय (निश्चित रूप से) के लिए महत्वपूर्ण रूप से जोड़ता है, लेकिन मैं आवेदन को नीचे लाने की अपेक्षा इंतजार

— करूंगा

Answer 2

चूंकि आप लिनक्स चला रहे हैं और यह कार्य संभवत: I / O- बाउंड है, मैं आपकी कमांड आइडल I / O शेड्यूलर प्राथमिकता का उपयोग करने की सलाह देता हूं ionice(1):

ionice -c3 find . -name '*.gif' -delete

आपके मूल आदेश की तुलना में, मुझे लगता है कि यह पाइप से बचकर कुछ और सीपीयू चक्रों को भी छोड़ सकता है xargs।

Comments

@Braiam तुम्हारा क्या मतलब है? यह वह जगह नहीं है, find ... -execजहां समझ में आता है।

ओह, हाँ, क्षमा करें। मेरी गलती। तुम्हें यकीन है कि कुशल है, यद्यपि?

— ब्रिएम

ठीक है, find(1)प्रलेखन ऐसा दावा करता है। :) और यह स्पष्ट होना चाहिए कि इसके लिए findएक rmकमांड को फोर्क करने की तुलना में खुद को फ़ाइलों को हटाने देना अधिक कुशल है ।

मैंने एक उत्पादन सर्वर पर 4 मिलियन फ़ाइलों के साथ एक फ़ोल्डर पर कई सुझाए गए संस्करणों की कोशिश की है और यह केवल एक ही है जो सिस्टम को चोक नहीं करता है। ionice -c3प्रियो को बस चलाने के लिए कम करता है जब आईओ बेकार है अन्यथा यह एकदम सही है। ध्यान दें कि चूंकि -deleteखोज के लिए मानक नहीं है, आप इस कमांड का उपयोग करके (फीडबैक सहित यह काम करता है) एक ही कर सकते हैं: ionice -c 3 find . -name '*.gif' -exec echo {} \; -exec rm {} \;- धीमी लेकिन महत्वपूर्ण प्रक्रियाओं का कोई iowaits नहीं।

— क्रिस्टोफर लोर्केन

Answer 3

नहीं।

कोई तेज़ तरीका नहीं है, डिस्क के सॉफ्ट-फॉर्मेट से। फाइलें एक बार में आरएम को दी जाती हैं (कमांड लाइन की सीमा तक, यह भी सेट किया जा सकता है xargs) जो प्रत्येक फाइल पर आरएम को कॉल करने से बेहतर है। तो नहीं, निश्चित रूप से कोई तेज़ तरीका नहीं है।

उपयोग करना nice(या reniceएक चालू प्रक्रिया पर) केवल आंशिक रूप से मदद करता है, क्योंकि यह सीपीयू संसाधन को शेड्यूल करने के लिए है , न कि डिस्क पर! और CPU का उपयोग बहुत कम होगा। यह एक लिनक्स की कमजोरी है - अगर एक प्रक्रिया डिस्क को "खाती है" (यानी इसके साथ बहुत काम करती है), तो पूरी मशीन फंस जाती है। वास्तविक समय के उपयोग के लिए संशोधित कर्नेल एक समाधान हो सकता है।

मैं सर्वर पर क्या करूंगा अन्य प्रक्रियाओं को मैन्युअल रूप से अपना काम करने देना है - सर्वर को "सांस लेने" के लिए रोकें शामिल हैं:

find . -name "*.gif" > files
split -l 100 files files.
for F in files.* do
    cat $F | xargs rm
    sleep 5 
done

यह हर 100 फ़ाइलों के बाद 5 सेकंड तक प्रतीक्षा करेगा। इसमें बहुत अधिक समय लगेगा, लेकिन आपके ग्राहकों को किसी देरी की सूचना नहीं देनी चाहिए।

Comments

"फाइलें एक बार में आरएम को दी जाती हैं (कमांड लाइन की सीमा तक)" - जब शेल को आदेश दिया जाता है rm *, तो यह *सभी फ़ाइल नाम के साथ लाइन में फैलता है और इसे पास करता है rm? यह अविश्वसनीय रूप से बेवकूफ है। शेल क्यों होगा वाइल्डकार्ड का विस्तार करें?

:-D @Joker_vD, क्या आप मजाक कर रहे हैं, जैसा कि आपका नाम बताता है? :-)

— टॉमस

@ जोकर_vD: 1970 या उसके बाद यूनिक्स के निर्णय के साथ संगतता। विंडोज यह नहीं करता है। वहां, प्रोग्राम वाइल्डकार्ड को फाइंडनेक्स्ट फ़ील / फाइंडनेक्स्ट फ़ील में पास कर सकते हैं, इसलिए उन्हें एक समय में एक ही परिणाम मिलता है।

— MSalters

@ टोमस इस मामले में नहीं। ईमानदारी से, मैं तुरंत इस तरह के डिजाइन के साथ 2 समस्याएं देख सकता हूं: पहला, कमांड लाइन रबर नहीं है; दूसरा, कार्यक्रम यह नहीं बता सकता है कि क्या उसे उपयोगकर्ता के ऐसे निर्णय के साथ बुलाया गया था *या /*नहीं।

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

— जॉन कुगेलमैन

Answer 4

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

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

कुछ डाउनटाइम होगा, लेकिन यह लगातार खराब प्रदर्शन और सेवा व्यवधान से बेहतर हो सकता है।

यह आपके सिस्टम और स्थिति में अव्यावहारिक हो सकता है, लेकिन स्पष्ट मामलों की कल्पना करना आसान है जहां यह जाने का रास्ता है।

उदाहरण के लिए, मान लें कि आप किसी फ़ाइल सिस्टम की सभी फ़ाइलों को हटाना चाहते हैं । एक-एक करके हटने और हटने का क्या मतलब होगा? बस इसे अनमाउंट करें और एक खाली फाइल सिस्टम बनाने के लिए विभाजन के ऊपर "mkfs" करें।

या मान लें कि आप आधा दर्जन महत्वपूर्ण को छोड़कर सभी फाइलों को हटाना चाहते थे? आधा दर्जन वहाँ से निकल जाओ और ... शीर्ष पर "mkfs"।

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

Answer 5

आपने कोशिश की है:

find . -name "*.gif" -exec rm {} +

अंत में + साइन के कारण एकल rm कमांड को निष्पादित करने के लिए और अधिक फ़ाइलों को शामिल करना पड़ेगा। अधिक विवरण के लिए इस प्रश्न की जाँच करें ।

Comments

यह बहुत तेजी से निष्पादित -प्रिंट0 | xargs का समाधान क्योंकि rm प्रक्रिया हर फाइल के लिए नहीं बल्कि उनके बड़े सेट के लिए मंगाई जाती है और इसलिए यह कम लोड का कारण बनती है।

@JohnKugelman आप सही हैं, लेकिन यह एक GNU एक्सटेंशन है जो हमेशा देशी खोज कमांड के साथ उपलब्ध नहीं है ।

— कोडगोमन नोव

ठीक है, दिलचस्प है, लेकिन यह काफी नई बात है (साथ ही -delete) जो हमेशा वहाँ नहीं होती है ..

— टॉमस

हालांकि यह निश्चित रूप से ओपी के समाधान की तुलना में बेहतर कुछ नहीं लाता है।

— टॉमस