কয়েক মিলিয়ন ফাইল সহ ডিরেক্টরিতে rm

104

পটভূমি: শারীরিক সার্ভার, প্রায় দুই বছর বয়সী, W২০০-আরপিএম সটা ড্রাইভ 3 ওয়্যার রেড কার্ডের সাথে সংযুক্ত, ext3 এফএস মাউন্ট করা নোয়াটিম এবং ডেটা = অর্ডার করেছে, পাগলের লোডের নীচে নয়, কার্নেল ২.6.১৮-৯২.২২.২৫.el5, আপটাইম ৫৫৫ দিন । ডিরেক্টরিতে কোনও বৃহত্তর (কয়েকটি কেবি) ফাইল সহ কয়েক মিলিয়ন ছোট (~ 100 বাইট) ফাইল থাকে না sub

আমাদের এমন একটি সার্ভার রয়েছে যা গত কয়েক মাস ধরে কিছুটা কোকিল করে চলেছে, তবে আমরা কেবলমাত্র এটি অন্য দিনেই লক্ষ্য করেছি যখন এটি খুব বেশি ফাইল রয়েছে বলে কোনও ডিরেক্টরিতে লিখতে অক্ষম হয়ে পড়েছিল। বিশেষত, এটি / var / লগ / বার্তাগুলিতে এই ত্রুটিটি ছুঁড়তে শুরু করে:

ext3_dx_add_entry: Directory index full!

প্রশ্নযুক্ত ডিস্কে প্রচুর পরিমাণে ইনোড বাকী রয়েছে:

Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/sda3            60719104 3465660 57253444    6% /

সুতরাং আমি অনুমান করছি এর অর্থ আমরা ডিরেক্টরি ফাইলটিতে কতগুলি এন্ট্রি হতে পারে তার সীমাটি হিট করেছি। কতগুলি ফাইল হবে সে সম্পর্কে ধারণা নেই তবে এটি ত্রিশ লক্ষ বা তারও বেশি হিসাবে আপনি দেখতে পারেন। এটা যে ভাল না, মনে মনে! তবে এটি আমার প্রশ্নের একটি অংশ: ঠিক ওপরের সীমাটি কী? এটা কি ট্যুরেবল? আমি চিৎকার করতে অ্যাট আমি এটা সুর করতে চান নিচে ; এই বিরাট ডিরেক্টরিটি বিভিন্ন ধরণের সমস্যার কারণ হয়ে দাঁড়িয়েছে।

যাইহোক, আমরা কোডটিতে এই সমস্যাটি সন্ধান করেছি যা এই সমস্ত ফাইল তৈরি করেছিল এবং আমরা এটি সংশোধন করেছি। এখন আমি ডিরেক্টরি মুছে ফেলার সাথে আটকে আছি।

কয়েকটি বিকল্প এখানে:

  1. rm -rf (dir)

    আমি প্রথমে চেষ্টা করেছিলাম। এটি দেড় দিনের জন্য কোনও তাত্পর্যপূর্ণ প্রভাব ছাড়াই চলে যাওয়ার পরে আমি তা ছেড়ে দিয়েছিলাম এবং হত্যা করেছি।

  2. ডিরেক্টরিতে আনলিংক (2): অবশ্যই বিবেচনার জন্য মূল্যবান, তবে প্রশ্নটি হল যে আনইলিংক (2) এর মাধ্যমে মুছে ফেলার চেয়ে ডিরেক্টরিটির ভিতরে থাকা ফাইলগুলি fsck এর মাধ্যমে মুছে ফেলা আরও দ্রুত হবে কি না question এটি হ'ল এক উপায় বা অন্যভাবে আমি এই ইনোডগুলিকে অব্যবহৃত হিসাবে চিহ্নিত করেছি। এটি অবশ্যই ধরে নিয়েছে যে আমি fsck কে বলতে পারি / হারিয়ে + পাওয়া ফাইলগুলিতে এন্ট্রি না ফেলে! অন্যথায়, আমি আমার সমস্যা সরিয়েছি। অন্যান্য সমস্ত উদ্বেগের পাশাপাশি, আরও কিছুটা পড়ার পরে, দেখা যাচ্ছে যে আমাকে সম্ভবত কিছু অভ্যন্তরীণ এফএস ফাংশন কল করতে হবে, কারণ আমি যে লিঙ্কযুক্ত লিঙ্ক (২) আবিষ্কার করতে পারি তার কোনওটিই আমাকে কেবল নির্লিপ্তভাবে মুছতে দেয় না এটিতে এন্ট্রি সহ একটি ডিরেক্টরি। ঘৃণা।
  3. while [ true ]; do ls -Uf | head -n 10000 | xargs rm -f 2>/dev/null; done )

    এটি আসলে সংক্ষিপ্ত সংস্করণ; আমি যে আসল তা চালিয়ে যাচ্ছি, যা ফাইলগুলি মুছে ফেলার জন্য শেষ হয়ে গেলে কেবল কিছু অগ্রগতি-প্রতিবেদন এবং একটি ক্লিন স্টপ যুক্ত করে:

    এক্সপোর্ট i = 0;
সময় (যখন [সত্য]; কর
  ls -Uf | মাথা -n 3 | grep -qF '.png' || বিরতি;
  ls -Uf | মাথা -n 10000 | xargs rm -f 2> / dev / নাল;
  রফতানি i = ((($ i + 10000));
  প্রতিধ্বনি "$ i ...";
সম্পন্ন )

    এটি বরং ভাল কাজ করছে বলে মনে হচ্ছে। আমি যখন এটি লিখছি, এটি গত ত্রিশ মিনিট বা তারও বেশি সময় ধরে 260,000 ফাইল মুছে ফেলেছে।

এখন, প্রশ্নের জন্য:
  1. উপরে উল্লিখিত হিসাবে, প্রতি ডিরেক্টরি এন্ট্রি সীমা টিউনযোগ্য?
  2. কেন "রিয়েল 7m9.561s / ব্যবহারকারীর 0m0.001s / ss 0m0.001s" কেন এমন একটি ফাইল মুছে ফেলা হয়েছে যা তালিকার মধ্যে প্রথমটি ছিল যা ফিরে এসেছিল ls -Uএবং এটির সাথে প্রথম 10,000 এন্ট্রি মুছতে দশ মিনিট সময় লেগেছিল # 3 এ কমান্ড, কিন্তু এখন এটি বেশ আনন্দের সাথে চলছে? এই বিষয়টির জন্য, এটি প্রায় ত্রিশ মিনিটের মধ্যে 260,000 মুছে ফেলেছিল, তবে এখন আরও 60,000 মুছতে আরও পনের মিনিট সময় লেগেছে। গতিতে বিশাল দোল কেন?
  3. এই ধরণের কাজ করার আরও ভাল উপায় আছে? কোনও ডিরেক্টরিতে কয়েক মিলিয়ন ফাইল সঞ্চয় করবেন না; আমি জানি এটি নির্বোধ, এবং এটি আমার ঘড়িতে হত না। সমস্যাটি গুগল করা এবং এসএফ এবং এসও-এর মাধ্যমে সন্ধান করা বিভিন্ন প্রকারের findপ্রস্তাব দেয় যা বেশ কয়েকটি স্ব-স্পষ্ট কারণে আমার পদ্ধতির চেয়ে উল্লেখযোগ্যভাবে দ্রুত হতে চলেছে না। তবে মুছুন-দিয়ে-fsck ধারণার কোনও পা আছে? না পুরোপুরি অন্য কিছু? আমি বাক্সের বাইরে (বা খুব ভাল-বক্সের ভিতরে-এর বাইরে) চিন্তাভাবনা শুনতে আগ্রহী।
ছোট উপন্যাস পড়ার জন্য ধন্যবাদ; প্রশ্ন জিজ্ঞাসা নির্দ্বিধায় এবং আমি জবাব দিতে ভুলবেন না। আমি ফাইলের চূড়ান্ত সংখ্যা এবং আমার কাছে একবার মুছে ফেলার স্ক্রিপ্টটি কতক্ষণ চালিয়েছে তা নিয়ে প্রশ্নটি আপডেট করব।

চূড়ান্ত স্ক্রিপ্ট আউটপুট !:

2970000...
2980000...
2990000...
3000000...
3010000...

real    253m59.331s
user    0m6.061s
sys     5m4.019s

সুতরাং, তিন মিলিয়ন ফাইল চার ঘন্টার মধ্যে কিছুটা মুছে ফেলা হয়েছে।

kernel  ext3  rm  directory 
— BMDan
সূত্র
1
আরএম (জিএনইউ কোর্টিলস) 8.4-এ এই বিকল্প রয়েছে: "-v, --verbose কী করা হচ্ছে তা ব্যাখ্যা করুন" । এটি মুছে ফেলা হচ্ছে এমন সমস্ত ফাইল প্রদর্শন করবে।
— ক্রিশ্চিয়ান সিউপিতু
2
প্রকৃতপক্ষে, এটি একটি প্রগতি বার করার মতো ঝুঁকিপূর্ণ উপায়: যেহেতু প্রতিটি ফাইলই পঁয়ত্রিশটি বর্ণের দীর্ঘ হবে (৩ + + এ '\ n'), তাই আমি সহজেই তার জন্য একটি পার্সার লিখতে পারি, এবং যেহেতু মুদ্রণ () সস্তা এবং আরএম কমান্ডটিতে ইতিমধ্যে ফাইলটির নাম লোড হয়েছে, কোনও বিশেষ পারফরম্যান্স পেনাল্টি নেই। পুরো শেবাংটি করার জন্য একটি অ-স্টার্টারের মতো মনে হচ্ছে, যেহেতু আমি কখনই এর মতো কিছু করতে "আরএম" পাই না। তবে এটি একটি ইন্টার-10,000 প্রগতি বারের মতো বেশ ভালভাবে কাজ করতে পারে; সম্ভবত একটি "।" প্রতি শত ফাইলের জন্য?
— বিএমডান
8
rm -rfv | pv -l >/dev/null। পিভি ইপেল সংগ্রহস্থলে উপলব্ধ থাকতে হবে ।
— ক্রিশ্চিয়ান সিউপিতু
5
পিভি অপ্রতিরোধ্যভাবে দুর্দান্ত। আমি আমার জাগে পিভি ইনস্টলেশনগুলির একটি ট্রেইল রেখেছি।
— বিএমডান
আমি সম্প্রতি এই একই একই সমস্যা ছিল। ধন্যবাদ!
— সমৃদ্ধ

উত্তর:

30

data=writebackমাউন্ট বিকল্প, বিচার হওয়া করার ফাইল-সিস্টেমের জার্নালিং প্রতিরোধ করার জন্য যোগ্য। এটি কেবল মোছার সময় করা উচিত, মুছে ফেলা অপারেশনের সময় সার্ভারটি বন্ধ হয়ে বা পুনরায় বুট করা হচ্ছে তবে ঝুঁকি রয়েছে।

এই পৃষ্ঠা অনুসারে ,

কিছু অ্যাপ্লিকেশন এটি ব্যবহার করা হয় যখন খুব উল্লেখযোগ্য গতির উন্নতি দেখায়। উদাহরণস্বরূপ, অ্যাপ্লিকেশনগুলি যখন ছোট বড় ফাইলগুলি বড় পরিমাণে তৈরি এবং মুছে দেয় তখন গতি উন্নতি (...) দেখা যায়।

বিকল্প পারেন সেট করা হয় fstabপ্রতিস্থাপন, অথবা মাউন্ট অপারেশনের সময় data=orderedসঙ্গে data=writeback। মুছে ফেলার জন্য ফাইলগুলি থাকা ফাইল সিস্টেমটি পুনরায় মাউন্ট করতে হবে।

— রিং
সূত্র
1
তিনি commit বিকল্পটি থেকে সময়টি বাড়িয়ে দিতে পারেন : "এই ডিফল্ট মান (বা কোনও নিম্ন মানের) পারফরম্যান্সের ক্ষতি করবে, তবে এটি তথ্য-সুরক্ষার পক্ষে ভাল 0 0 এ সেট করা ডিফল্ট অবস্থায় রেখে দেওয়ার মতোই প্রভাব ফেলবে (৫ সেকেন্ড) )। এটি খুব বড় মান হিসাবে সেট করা কর্মক্ষমতা উন্নত করবে "।
— ক্রিশ্চিয়ান সিউপিতু
1
রাইটব্যাকটি তাত্পর্যপূর্ণ দেখায়, আমি যে ডকুমেন্টেশনটি দেখছিলাম তা বাদ দিয়ে ( ভদ্রলু.আর / ডক /en/articles/l-afig-p8.xML#doc_chap4 ) স্পষ্টভাবে উল্লেখ করেছে যে এটি এখনও মেটাডেটা জার্নাল করে, যা আমি অনুমান করি যে সমস্ত ডেটা আমি অন্তর্ভুক্ত করেছি পরিবর্তন করা হচ্ছে (আমি অবশ্যই ফাইলগুলিতে কোনও ডেটা পরিবর্তন করছি না)। বিকল্পটি সম্পর্কে আমার বোঝাটি কি ভুল?
— BMDan
শেষ অবধি, এফওয়াইআই, সেই লিঙ্কটিতে উল্লিখিত না হ'ল তথ্য = রাইটব্যাক একটি বিশাল সুরক্ষা গর্ত হতে পারে, যেহেতু প্রদত্ত এন্ট্রি দ্বারা নির্দেশিত ডেটাতে সেই অ্যাপ্লিকেশন দ্বারা সেখানে লেখা ডেটা নাও থাকতে পারে, যার অর্থ একটি ক্র্যাশ হতে পারে পুরানো, সম্ভবত সংবেদনশীল / ব্যক্তিগত ডেটা প্রকাশ করা হচ্ছে। এখানে কোনও উদ্বেগের বিষয় নয়, যেহেতু আমরা কেবল এটি অস্থায়ীভাবে চালু করছি, তবে আপনি বা সেই পরামর্শের বাইরে চলে যাওয়া অন্য কেউ যদি অবগত না হন তবে আমি সবাইকে সেই সতর্কতার জন্য সতর্ক করতে চেয়েছিলাম।
— বিএমডান
প্রতিশ্রুতিবদ্ধ: এটা খুব চতুর! পয়েন্টারের জন্য ধন্যবাদ।
— বিএমডান
2
data=writebackমেইনডাটা মূল ফাইল সিস্টেমে লেখার আগে এখনও জার্নালগুলি। যেহেতু আমি এটি বুঝতে পারি, এটি কেবলমাত্র সীমিত মানচিত্র লেখার মতো বিষয়গুলির মধ্যে অর্ডার প্রয়োগ করে না those আপনি যদি এ থেকে নিখুঁত লাভ দেখেন তবে অন্যান্য ক্রম সীমাবদ্ধতাগুলিও শিথিল হয়। অবশ্যই জার্নাল ছাড়াই মাউন্ট করা আরও উচ্চতর পারফরম্যান্স হতে পারে। (এটি লিঙ্ক লিখিতকরণ সম্পূর্ণ হওয়ার আগে ডিস্কে কিছু না রাখার পরিবর্তে র‌্যামে মেটাডেটা পরিবর্তন হতে পারে)।
— পিটার কর্ডেস
80

যদিও এই সমস্যার একটি প্রধান কারণ লক্ষ লক্ষ ফাইল সহ ext3 পারফরম্যান্স, এই সমস্যার আসল মূল কারণটি আলাদা।

যখন ডিরেক্টরিতে তালিকার তালিকা তৈরি করা দরকার তখন ডিরেক্টরিতে রিডডির () কল করা হয় যা ফাইলগুলির একটি তালিকা দেয়। রিডডির একটি পিক্সিক কল, তবে এখানে ব্যবহার করা আসল লিনাক্স সিস্টেম কলটিকে 'গেটডেন্টস' বলা হয়। Getdents এন্ট্রি সহ একটি বাফার পূরণ করে ডিরেক্টরি এন্ট্রি তালিকা।

সমস্যাটি মূলত নীচে রয়েছে যে রিড্ডির () ফাইল আনতে 32Kb এর একটি নির্দিষ্ট বাফার আকার ব্যবহার করে। ডিরেক্টরিটি বৃহত্তর এবং বৃহত্তর হওয়ার সাথে সাথে (ফাইলগুলি যুক্ত হওয়ার সাথে সাথে আকার বাড়তে থাকে) এক্সট্রি 3 এন্ট্রিগুলি আনতে ধীর এবং ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে প্রবেশদ্বারগুলিকে অন্তর্ভুক্ত করার জন্য অতিরিক্ত রেডডিরের 32 কেবি বাফার আকারটি যথেষ্ট। এর ফলে রিডডিয়ার বারবার লুপ করে এবং ব্যয়বহুল সিস্টেম কলটি বার বার শুরু করে।

উদাহরণস্বরূপ, একটি টেস্ট ডিরেক্টরিতে আমি ভিতরে ভিতরে ২. million মিলিয়ন ফাইল দিয়ে তৈরি করেছি, "ls -1 | wc-l" চালানো অনেকগুলি getdent সিস্টেম কলগুলির একটি বৃহত স্ট্রেস আউটপুট দেখায়।

$ strace ls -1 | wc -l
brk(0x4949000)                          = 0x4949000
getdents(3, /* 1025 entries */, 32768)  = 32752
getdents(3, /* 1024 entries */, 32768)  = 32752
getdents(3, /* 1025 entries */, 32768)  = 32760
getdents(3, /* 1025 entries */, 32768)  = 32768
brk(0)                                  = 0x4949000
brk(0x496a000)                          = 0x496a000
getdents(3, /* 1024 entries */, 32768)  = 32752
getdents(3, /* 1026 entries */, 32768)  = 32760
...

অতিরিক্তভাবে এই ডিরেক্টরিতে ব্যয় করা সময়টি উল্লেখযোগ্য ছিল।

$ time ls -1 | wc -l
2616044

real    0m20.609s
user    0m16.241s
sys 0m3.639s

এটিকে আরও কার্যকর প্রক্রিয়া করার পদ্ধতিটি হ'ল অনেক বড় বাফার দিয়ে ম্যানুয়ালি কল করা ents এটি কর্মক্ষমতা উল্লেখযোগ্যভাবে উন্নতি করে improves

এখন, আপনাকে নিজেকে নিজে নিজে কল করার কথা নয়, সুতরাং এটিকে সাধারণত ব্যবহার করার জন্য কোনও ইন্টারফেসের অস্তিত্ব নেই (গেটডেন্টদের দেখার জন্য ম্যান পেজটি দেখুন!) তবে আপনি নিজে এটি কল করতে পারেন এবং আপনার সিস্টেম কল আহ্বানের উপায়টিকে আরও দক্ষ করে তুলতে পারেন ।

এটি এই ফাইলগুলি আনতে যে সময় নেয় তা হ্রাস করে। আমি একটি প্রোগ্রাম লিখেছি যা এটি করে।

/* I can be compiled with the command "gcc -o dentls dentls.c" */

#define _GNU_SOURCE

#include <dirent.h>     /* Defines DT_* constants */
#include <err.h>
#include <fcntl.h>
#include <getopt.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/stat.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <unistd.h>

struct linux_dirent {
        long           d_ino;
        off_t          d_off;
        unsigned short d_reclen;
        char           d_name[256];
        char           d_type;
};

static int delete = 0;
char *path = NULL;

static void parse_config(
        int argc,
        char **argv)
{
    int option_idx = 0;
    static struct option loptions[] = {
      { "delete", no_argument, &delete, 1 },
      { "help", no_argument, NULL, 'h' },
      { 0, 0, 0, 0 }
    };

    while (1) {
        int c = getopt_long(argc, argv, "h", loptions, &option_idx);
        if (c < 0)
            break;

        switch(c) {
          case 0: {
              break;
          }

          case 'h': {
              printf("Usage: %s [--delete] DIRECTORY\n"
                     "List/Delete files in DIRECTORY.\n"
                     "Example %s --delete /var/spool/postfix/deferred\n",
                     argv[0], argv[0]);
              exit(0);                      
              break;
          }

          default:
          break;
        }
    }

    if (optind >= argc)
      errx(EXIT_FAILURE, "Must supply a valid directory\n");

    path = argv[optind];
}

int main(
    int argc,
    char** argv)
{

    parse_config(argc, argv);

    int totalfiles = 0;
    int dirfd = -1;
    int offset = 0;
    int bufcount = 0;
    void *buffer = NULL;
    char *d_type;
    struct linux_dirent *dent = NULL;
    struct stat dstat;

    /* Standard sanity checking stuff */
    if (access(path, R_OK) < 0) 
        err(EXIT_FAILURE, "Could not access directory");

    if (lstat(path, &dstat) < 0) 
        err(EXIT_FAILURE, "Unable to lstat path");

    if (!S_ISDIR(dstat.st_mode))
        errx(EXIT_FAILURE, "The path %s is not a directory.\n", path);

    /* Allocate a buffer of equal size to the directory to store dents */
    if ((buffer = calloc(dstat.st_size*3, 1)) == NULL)
        err(EXIT_FAILURE, "Buffer allocation failure");

    /* Open the directory */
    if ((dirfd = open(path, O_RDONLY)) < 0) 
        err(EXIT_FAILURE, "Open error");

    /* Switch directories */
    fchdir(dirfd);

    if (delete) {
        printf("Deleting files in ");
        for (int i=5; i > 0; i--) {
            printf("%u. . . ", i);
            fflush(stdout);
            sleep(1);
        }
        printf("\n");
    }

    while (bufcount = syscall(SYS_getdents, dirfd, buffer, dstat.st_size*3)) {
        offset = 0;
        dent = buffer;
        while (offset < bufcount) {
            /* Don't print thisdir and parent dir */
            if (!((strcmp(".",dent->d_name) == 0) || (strcmp("..",dent->d_name) == 0))) {
                d_type = (char *)dent + dent->d_reclen-1;
                /* Only print files */
                if (*d_type == DT_REG) {
                    printf ("%s\n", dent->d_name);
                    if (delete) {
                        if (unlink(dent->d_name) < 0)
                            warn("Cannot delete file \"%s\"", dent->d_name);
                    }
                    totalfiles++;
                }
            }
            offset += dent->d_reclen;
            dent = buffer + offset;
        }
    }
    fprintf(stderr, "Total files: %d\n", totalfiles);
    close(dirfd);
    free(buffer);

    exit(0);
}

যদিও এটি অন্তর্নিহিত মৌলিক সমস্যার সাথে লড়াই করে না (প্রচুর ফাইল, একটি ফাইল সিস্টেমে যা এতে খারাপ কাজ করে)। এটি অনেকগুলি হতে পারে, পোস্ট করা বিকল্পগুলির অনেকের চেয়ে অনেক দ্রুত।

পূর্বাভাস হিসাবে, একজনকে প্রভাবিত ডিরেক্টরিটি সরিয়ে ফেলা উচিত এবং এর পরে এটি পুনরায় তৈরি করা উচিত। ডিরেক্টরিগুলি কেবল আকারে বৃদ্ধি পায় এবং ডিরেক্টরি আকারের কারণে কিছু ফাইল ভিতরে থাকা সত্ত্বেও দুর্বল সম্পাদন করতে পারে।

সম্পাদনা: আমি এটি বেশ খানিকটা পরিষ্কার করেছি। রানটাইমের সময় আপনাকে কমান্ড লাইনে মুছে ফেলার অনুমতি দেওয়ার জন্য একটি বিকল্প যুক্ত করা হয়েছে এবং গাছের হাঁড়ের জিনিসপত্রের একটি গোছা সরিয়ে নিয়েছে, যা সত্যই পিছনে ফিরে তাকানো সেরা ছিল সন্দেহজনক। স্মৃতি দুর্নীতি উত্পাদন করতে দেখানো হয়েছিল।

আপনি এখন করতে পারেন dentls --delete /my/path

নতুন ফলাফল। ১.২২ মিলিয়ন ফাইল সহ একটি ডিরেক্টরি ভিত্তিক।

## Ideal ls Uncached
$ time ls -u1 data >/dev/null

real    0m44.948s
user    0m1.737s
sys 0m22.000s

## Ideal ls Cached
$ time ls -u1 data >/dev/null

real    0m46.012s
user    0m1.746s
sys 0m21.805s


### dentls uncached
$ time ./dentls data >/dev/null
Total files: 1819292

real    0m1.608s
user    0m0.059s
sys 0m0.791s

## dentls cached
$ time ./dentls data >/dev/null
Total files: 1819292

real    0m0.771s
user    0m0.057s
sys 0m0.711s

এটি এখনও এত ভাল কাজ করে এক ধরনের অবাক হয়েছিল!

— ম্যাথু ইফ
সূত্র
1
দুটি ছোটখাটো উদ্বেগ: একটি, [256]সম্ভবত হওয়া উচিত [FILENAME_MAX]এবং দ্বিতীয়টি, আমার লিনাক্স (২.6.১৮ == CentOS 5.x) ডাইরেক্টে কোনও d_type এন্ট্রি অন্তর্ভুক্ত বলে মনে হচ্ছে না (অন্তত getdents অনুযায়ী (2))।
— বিএমডান
1
আপনি দয়া করে বিটিরি পুনরায় ভারসাম্য রক্ষার জন্য কিছুটা বিশদ বর্ণনা করতে পারেন এবং কেন মুছে ফেলা এই প্রতিরোধে সহায়তা করে? দুর্ভাগ্যক্রমে এর জন্য আমি গুগলিংয়ের চেষ্টা করেছি।
— ovgolovin
1
কারণ এটি এখন আমার মনে হচ্ছে আমরা যদি অর্ডারে মুছছেন, আমরা rebalancing জোর হিসাবে আমরা একপাশে পাতার মুছে ফেলুন এবং অন্য ছেড়ে: en.wikipedia.org/wiki/B-tree#Rebalancing_after_deletion
— ovgolovin
1
আমি আশা করি আমি আপনাকে এই বিষয়গুলি নিয়ে বিরক্ত করব না। তবে তবুও আমি অর্ডার স্ট্যাকওভারফ্লো.com / q / 17955459 / 862380 ফাইলগুলি মুছে ফেলার বিষয়ে একটি প্রশ্ন শুরু করেছি , যা এমন কোনও উত্তর পেয়েছে বলে মনে হচ্ছে না যা এই সমস্যাটির উদাহরণ দিয়ে ব্যাখ্যা করবে, যা সাধারণ প্রোগ্রামারদের জন্য বোধগম্য হবে। আপনার যদি সময় থাকে এবং এমনটি মনে হয় তবে আপনি কি এটি সন্ধান করতে পারেন? আপনি আরও ভাল ব্যাখ্যা লিখতে পারে।
— ovgolovin
2
এটি একটি আশ্চর্যজনক কোড piece এটিই কেবলমাত্র একমাত্র সরঞ্জাম যা আমি প্রায় 11,000,000 (এগারো মিলিয়ন) সেশন ফাইলগুলি তালিকাভুক্ত করতে এবং মুছে ফেলার সক্ষম খুঁজে পেয়েছি যা সম্ভবত কয়েক বছর ধরে একটি ডিরেক্টরিতে তৈরি হয়েছিল। এখানে অন্য উত্তরে খোঁজ এবং অন্যান্য কৌশলগুলি ব্যবহার করে তাদের নিয়ন্ত্রণে রাখার কথা ছিল প্ল্লেস্ক প্রক্রিয়া, কোনও রান সম্পূর্ণ করতে অক্ষম, সুতরাং ফাইলগুলি কেবল বিল্ডিংয়েই রইল। ডিরেক্টরি সিস্টেম সংরক্ষণের জন্য ফাইল সিস্টেম ব্যবহার করে এমন বাইনারি গাছের জন্য এটি একটি শ্রদ্ধাঞ্জলি, সেশনগুলি আদৌ কাজ করতে সক্ষম হয়েছিল - আপনি কোনও ফাইল তৈরি করতে এবং দেরি না করে পুনরুদ্ধার করতে পারেন। কেবল তালিকাটি ব্যবহারের অযোগ্য ছিল।
— জেসন
31

এই ফাইল সিস্টেম থেকে অন্য সমস্ত ফাইলকে অস্থায়ী স্টোরেজ অবস্থানে নিয়ে যাওয়া, পার্টিশনটির পুনরায় ফর্ম্যাট করা এবং তারপরে ফাইলগুলি পুনরুদ্ধার করা সম্ভব হবে?

— jftuga
সূত্র
3
আমি আসলে এই উত্তরটি সত্যিই পছন্দ করি। ব্যবহারিক বিষয় হিসাবে, এক্ষেত্রে না, তবে এটি আমি ভাবিনি would বলিহারি!
— বিএমডান
ঠিক আমিও কি ভাবছিলাম। এটি 3 প্রশ্নের উত্তর। আপনি আমাকে জিজ্ঞাসা করুন আদর্শ :)
— জোশুয়া
12

Ext3 তে কোনও ফাইল ডিরেক্টরি সীমা নেই কেবলমাত্র ফাইলসিস্টেমের ইনোড সীমা (আমার মনে হয় যদিও উপ-ডিরেক্টরিগুলির সংখ্যার সীমা আছে)।

ফাইলগুলি সরানোর পরে আপনার এখনও সমস্যা হতে পারে।

যখন কোনও ডিরেক্টরিতে মিলিয়ন ফাইল থাকে, ডিরেক্টরি এন্ট্রি নিজেই খুব বড় হয়ে যায়। ডিরেক্টরি মুছে ফেলা প্রতিটি অপসারণ অপারেশন জন্য স্ক্যান করতে হবে, এবং এটি প্রতিটি ফাইলের জন্য বিভিন্ন পরিমাণ সময় নেয়, যেখানে এটি প্রবেশ করানো হয় তার উপর নির্ভর করে। দুর্ভাগ্যক্রমে সমস্ত ফাইল সরানোর পরেও ডিরেক্টরি এন্ট্রি তার আকার ধরে রাখে। ডিরেক্টরি ক্রমটি ফাঁকা থাকা সত্ত্বেও আরও ক্রিয়াকলাপগুলির জন্য যে ডিরেক্টরিতে এন্ট্রি স্ক্যান করা প্রয়োজন এখনও দীর্ঘ সময় নিতে পারে। এই সমস্যাটি সমাধান করার একমাত্র উপায় হ'ল ডিরেক্টরিটির নতুন নামকরণ, পুরানো নাম সহ একটি নতুন তৈরি করা এবং বাকী যে কোনও ফাইল নতুনটিতে স্থানান্তর করা। তারপরে নাম পরিবর্তন করা মুছুন।

— অ্যালেক্স জে রবার্টস
সূত্র
আসলে, আমি সবকিছু মুছে ফেলার পরে কেবল এই আচরণটি লক্ষ্য করেছি। ভাগ্যক্রমে, আমরা ইতিমধ্যে ডিরেক্টরিটিকে "ফায়ার লাইনের" বাইরে এমভিড করেছি, সুতরাং আমি এটি আরএমডিআর করতে পারলাম।
— বিএমডান
2
এটি বলেছে, যদি প্রতি ডিরেক্টরি ফাইলের সীমা না থাকে তবে আমি কেন "ext3_dx_add_entry: ডিরেক্টরি সূচক পূর্ণ!" সেই পার্টিশনে এখনও যখন ইনোড উপলব্ধ ছিল? এই ডিরেক্টরিটির ভিতরে কোনও উপ-ডিরেক্টরি ছিল না।
— বিএমডান
3
হুম আমি আরও কিছু গবেষণা করেছি এবং দেখে মনে হচ্ছে যে কোনও ডিরেক্টরি নিতে পারে এমন ব্লকের একটি সীমা রয়েছে। ফাইলের সঠিক সংখ্যাটি কয়েকটি বিষয়ের উপর নির্ভর করে যেমন ফাইলের নাম দৈর্ঘ্য। এই gossamer-threads.com/lists/linux/kernel/921942 ইঙ্গিত দেয় যে 4k ব্লকের সাহায্যে আপনার একটি ডিরেক্টরিতে 8 মিলিয়নেরও বেশি ফাইল থাকতে হবে। তারা বিশেষত দীর্ঘ ফাইলের নাম ছিল?
— অ্যালেক্স জে রবার্টস
প্রতিটি ফাইলের নাম হুবহু 36 অক্ষর দীর্ঘ।
— বিএমডান
ভাল যে ধারনা থেকে বের :) আমি
— অ্যালেক্স জে রবার্টস
4

উপরের ব্যবহারকারীদের পরামর্শ অনুসারে ext3 fs এর পরামিতিগুলি পরিবর্তনের পরেও কেবল আমার জন্য কার্যকর হয়নি। প্রচুর স্মৃতি গ্রাহ্য। এই পিএইচপি স্ক্রিপ্টটি কৌশলটি করেছে - দ্রুত, তুচ্ছ সিপিইউ ব্যবহার, তুচ্ছ মেমরির ব্যবহার:

<?php 
$dir = '/directory/in/question';
$dh = opendir($dir)) { 
while (($file = readdir($dh)) !== false) { 
    unlink($dir . '/' . $file); 
} 
closedir($dh); 
?>

আমি এই সমস্যাটি সম্পর্কিত অনুসন্ধানের সাথে একটি বাগ রিপোর্ট পোস্ট করেছি: http://savannah.gnu.org/bugs/?31961

— আলেক্সান্ডার
সূত্র
এই আমাকে বাঁচায় !!
— জেস্ট্রো
3

আমি সম্প্রতি একটি অনুরূপ সমস্যার মুখোমুখি হয়েছি এবং রিং0 এর data=writebackকাজ করার পরামর্শটি পেতে অক্ষম (সম্ভবত ফাইলগুলি আমার প্রধান পার্টিশনে রয়েছে এই কারণে)। কর্মক্ষেত্রগুলি গবেষণা করার সময় আমি এটিকে হোঁচট খেয়েছি:

tune2fs -O ^has_journal <device>

এটি dataবিকল্পটি দেওয়া না করেই পুরোপুরি জার্নালিং বন্ধ করে দেবে mount। আমি এটির সাথে একত্রিত হয়েছি noatimeএবং ভলিউমটি dir_indexসেট হয়ে গেছে এবং দেখে মনে হচ্ছে এটি বেশ ভালভাবে কাজ করবে। মুছে ফেলার জন্য আমাকে এটি হত্যা করার প্রয়োজন ছাড়াই আসলে শেষ করা হয়েছে, আমার সিস্টেমটি প্রতিক্রিয়াশীল থেকেছে, এবং এটি এখন ব্যাক আপ এবং চলমান (জার্নালিংয়ে ফিরে) কোনও সমস্যা ছাড়াই।

— ম্যাথু পড়ুন
সূত্র
মেটাডেটা অপ্সকে জার্নি করতে এড়াতে আমি এটিকে এক্স 3 এর পরিবর্তে এক্স 2 হিসাবে মাউন্ট করার পরামর্শ দিতে যাচ্ছি। এটি একই কাজ করা উচিত।
— পিটার কর্ডেস
3

আপনি নিশ্চিত হন:

mount -o remount,rw,noatime,nodiratime /mountpoint

যা কিছুটা গতি বাড়িয়ে তুলবে।

— karmawhore
সূত্র
4
ভাল কল, কিন্তু এটি ইতিমধ্যে noatime মাউন্ট করা হয়েছে, আমি প্রশ্নের শিরোনামে উল্লেখ হিসাবে। এবং নোডিরটাইম অপ্রয়োজনীয়; দেখতে lwn.net/Articles/245002 ।
— বিএমডান
1
পিপিএল এই মন্ত্রটির পুনরাবৃত্তি করুন "নোটিম, নোডিরামটাইম, নোডাভাটাইম, নোরিয়াডডোকস্যাটিম"
— পোজ
2

ls খুব ধীর কমান্ড। চেষ্টা করুন:

find /dir_to_delete ! -iname "*.png" -type f -delete
— bindbn
সূত্র
আরএম-আরএফ দেড় দিন দৌড়েছিল এবং আমি আসলে এটি কিছু সম্পাদন করেছিলাম কিনা তা না জেনে অবশেষে আমি এটি মেরে ফেলেছিলাম। আমার একটি প্রগতি বার দরকার ছিল।
— বিএমডান
4
আরএম খুব ধীর হয়ে যাওয়ার জন্য 30k ফাইলগুলিতে "টাইম সন্ধান করুন--মোছা": 0 মি0.357 এস / 0 এম0.019 এস / 0 এম0.337 আসল / ইউজার / সিএস। "সময় (ls -1U | xargs rm -f)" একই ফাইলগুলিতে: 0m0.366s / 0m0.025s / 0m0.340s। যা মূলত মার্জিন-অফ-ত্রুটি অঞ্চল।
— BMDan
1
আপনি strace -r -p <pid of rm>ইতিমধ্যে চলমান আরএম প্রক্রিয়াটি সংযুক্ত করার জন্য দৌড়াতে পারতেন । তারপরে আপনি দেখতে পাচ্ছেন কীভাবে দ্রুত unlinkসিস্টেম কলগুলি অতীতের স্ক্রল করছে। ( -rপ্রতিটি লাইনের শুরুতে পূর্ববর্তী সিস্টেম কল করার পরে সময় রাখে))
— পিটার কর্ডেস
2

হয় dir_indexফাইলসিস্টেম জন্য সেট? ( tune2fs -l | grep dir_index) না থাকলে এটি সক্ষম করুন। এটি সাধারণত নতুন আরএইচইএল-এর জন্য চালু থাকে।

— স্যাম
সূত্র
1
হ্যাঁ, এটি সক্ষম, তবে দুর্দান্ত পরামর্শ!
— বিএমডান
2

কয়েক বছর আগে, আমি ফাইল সিস্টেমে 16 মিলিয়ন এক্সএমএল ফাইল সহ একটি ডিরেক্টরি পেয়েছি /। সার্ভারের সমালোচনা করার কারণে আমরা নিম্নলিখিত কমান্ডটি ব্যবহার করেছি যা শেষ করতে প্রায় 30 ঘন্টা সময় নিয়েছে:

perl -e 'for(<*>){((stat)[9]<(unlink))}'

এটি একটি পুরাতন 7200 আরপিএম এইচডি, এবং আইও বাধা এবং সিপিইউ স্পাইক সত্ত্বেও, পুরানো ওয়েবসারভারটি তার পরিষেবা চালিয়ে গেছে।

— a_foaley
সূত্র
1

আমার পছন্দসই বিকল্প হ'ল নতুনfs পদ্ধতির, ইতিমধ্যে প্রস্তাবিত। মূল সমস্যাটি আবার যেমনটি ইতিমধ্যে উল্লিখিত হয়েছে, মুছে ফেলার জন্য হ্যান্ডেল করতে রৈখিক স্ক্যান সমস্যাযুক্ত।

rm -rfস্থানীয় ফাইল সিস্টেমের জন্য অনুকূলের কাছাকাছি হওয়া উচিত (এনএফএস পৃথক হবে)। তবে কয়েক মিলিয়ন ফাইলে, ফাইলের নাম অনুসারে 36 বাইট এবং 4 ইনোডে (একটি অনুমান, এক্সট্রি 3 এর জন্য মান পরীক্ষা করা হয় না), যা 40 * মিলিয়ন, কেবলমাত্র ডিরেক্টরিতে র‌্যামে রাখতে হবে।

অনুমান হিসাবে, আপনি লিনাক্সে ফাইল সিস্টেমের মেটাডেটা ক্যাশে মেমরিটি ছড়িয়ে দিচ্ছেন, যাতে আপনি যখন অন্য অংশটি ব্যবহার করছেন তখন ডিরেক্টরি ফাইলের একটি পৃষ্ঠার ব্লকগুলি কেটে ফেলা হবে, কেবল যখন পরবর্তী পৃষ্ঠায় পুনরায় আঘাত করতে হবে ফাইল মুছে ফেলা হয়। লিনাক্স পারফরম্যান্স টিউনিং আমার অঞ্চল নয়, তবে / proc / sys / {vm, fs} / সম্ভবত প্রাসঙ্গিক কিছু রয়েছে।

আপনি যদি ডাউনটাইম সহ্য করতে পারেন তবে আপনি dir_index বৈশিষ্ট্যটি চালু করার বিষয়ে বিবেচনা করতে পারেন। এটি বৃহত্তর ডিরেক্টরিতে (হ্যাশ বি-ট্রি) মুছে ফেলার জন্য লিনিয়ার থেকে সূচিকাগুলির থেকে আরও সর্বোত্তম কিছুতে স্যুইচ করে। tune2fs -O dir_index ...এর পরে e2fsck -Dকাজ করবে। যাইহোক, যদিও আমি আত্মবিশ্বাসী হওয়ার পরে সমস্যা হওয়ার আগে এটি সাহায্য করবে , আমি জানি না -Dকোন বিদ্যমান v.large ডিরেক্টরিতে কাজ করার সময় রূপান্তর (ই 2fsck এর সাথে ) কীভাবে সম্পাদন করে। ব্যাকআপগুলি + এটি স্তন্যপান এবং দেখুন।

— ফিল পি
সূত্র
1
pubbs.net/201008/squid/… পরামর্শ দেয় যে /proc/sys/fs/vfs_cache_pressureএটি ব্যবহারের মান হতে পারে তবে ডিরেক্টরিটি নিজেই পৃষ্ঠা ক্যাশে (কারণ এটি যা তাই) বা ইনোড ক্যাশে (কারণ এটি না হওয়া সত্ত্বেও) গণনা করে কিনা তা আমি জানি না ইনোড, এটি এফএস মেটাডেটা এবং সেই কারণেই এটিতে বান্ডিল হয়েছে)। আমি যেমন বলেছি, লিনাক্স ভিএম টিউনিং আমার অঞ্চল নয়। খেলুন এবং দেখুন কী সাহায্য করে।
— ফিল পি
1

স্পষ্টতই আপেলগুলিতে আপেল না, তবে আমি একটি সামান্য পরীক্ষা সেটআপ করেছি এবং নিম্নলিখিতগুলি করেছি:

ডিরেক্টরিতে ( ddএবং /dev/urandomএকটি লুপে) 100,000 512-বাইট ফাইল তৈরি করেছেন ; এটি সময় দিতে ভুলে গিয়েছিলেন, তবে এই ফাইলগুলি তৈরি করতে প্রায় 15 মিনিট সময় লেগেছে।

নীচের ফাইলগুলিকে মুছে ফেলার জন্য চালান:

ls -1 | wc -l && time find . -type f -delete

100000

real    0m4.208s
user    0m0.270s
sys     0m3.930s

এটি একটি পেন্টিয়াম 4 2.8GHz বাক্স (কয়েকশ জিবি আইডিই 7200 আরপিএম আমার মনে হয়; EXT3)। কার্নেল ২.6.২7।

— gravyface
সূত্র
আকর্ষণীয়, তাই সম্ভবত দীর্ঘ সময় ধরে ফাইলগুলি তৈরি হচ্ছিল তা কি প্রাসঙ্গিক? তবে তাতে কিছু আসে যায় না; ব্লক ক্যাশে সমস্ত প্রাসঙ্গিক মেটাডেটা ব্লক র‌্যামে থাকা উচিত। সম্ভবত এটি আনলিংক (2) লেনদেনের কারণে? আপনার অনুমানে, আরএম এর সময়কালের জন্য জার্নালিং বন্ধ করা কি কোনও সম্ভাব্য (যদিও স্বীকার করা কিছুটা বিপজ্জনক) সমাধান হতে পারে? দেখে মনে হচ্ছে না আপনি কেবল একটি টিউন 2 এফ / fsck / রিবুট ছাড়াই একটি মাউন্ট করা ফাইল সিস্টেমে পুরোপুরি জার্নালিং বন্ধ করতে পারেন যা কিছুটা উদ্দেশ্যকে পরাস্ত করে।
— বিএমডান
আমি এ সম্পর্কে মন্তব্য করতে পারি না, তবে উপাখ্যানগতভাবে (কয়েক বছর ধরে বিভিন্ন এনআইএক্স আলোচনায়), আমি সর্বদা শুনেছি যে rmবিপুল সংখ্যক ফাইলে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে সেগুলিও কম রয়েছে find -delete। শেলটিতে একটি ওয়াইল্ডকার্ডের সাথে এটি প্রতিটি ফাইলের সাথে মিলিত ফাইলের নাম প্রসারিত করবে এবং আমি ধরে নিচ্ছি যে এর জন্য একটি সীমাবদ্ধ মেমরি বাফার রয়েছে, যাতে আপনি দেখতে পেলেন কীভাবে এটি অকার্যকর হবে।
— গ্রাফেসফেস
1
আরএম ধীর হবে কারণ এটি নাম অনুসারে একটি ফাইল সন্ধান করছে, যার অর্থ ডিরেক্টরিটি পুনরাবৃত্তি করা এটি একে একে না পাওয়া পর্যন্ত ডিরেক্টরিতে প্রবেশ করে। এক্ষেত্রে, যেহেতু প্রতিটি এন্ট্রি হস্তান্তর করা হচ্ছে (সেই সময়ে) তালিকার প্রথমটি (ls -U / ls -f), তাই এটি প্রায় তত দ্রুত হওয়া উচিত । এটি বলেছিল, rm -rf <dir>, যা চ্যাম্পের মতো চালানো উচিত ছিল, ধীর ছিল was সম্ভবত এখন মুছে ফেলার গতি বাড়ানোর জন্য কোর্টিলগুলিতে প্যাচ লেখার সময় এসেছে? সম্ভবত এটি আরএম-আরএফ বাস্তবায়নের জন্য গোপনে কিছু recursive উপায়ে গ্লোবালিং / বাছাই করা হয়? এর মতো অনিশ্চয়তা কেন আমি প্রশ্ন জিজ্ঞাসা করেছি। ;)
— বিএমডান
1
আপনি তৈরির পদক্ষেপটি চালানোর পরে মেশিনটি পুনরায় বুট করুন। আপনার লক্ষণীয়ভাবে ধীর মুছে ফেলা উচিত।
— ম্যাট
1

কখনও কখনও পার্ল এই জাতীয় ক্ষেত্রে বিস্ময়করভাবে কাজ করতে পারে। আপনি কি ইতিমধ্যে চেষ্টা করেছেন যদি এর মতো কোনও ছোট স্ক্রিপ্ট বাশ এবং বেসিক শেল কমান্ডগুলিকে কার্যকর করতে পারে?

#!/usr/bin/perl 
open(ANNOYINGDIR,"/path/to/your/directory");
@files = grep("/*\.png/", readdir(ANNOYINGDIR));
close(ANNOYINGDIR);

for (@files) {
    printf "Deleting %s\n",$_;
    unlink $_;
}

বা অন্য, সম্ভবত আরও দ্রুত, পার্ল পদ্ধতির:

#!/usr/bin/perl
unlink(glob("/path/to/your/directory/*.png")) or die("Could not delete files, this happened: $!");

সম্পাদনা: আমি আমার পার্ল স্ক্রিপ্টগুলি একবার ব্যবহার করে দেখেছি। আরও ভার্বোস একটি সঠিক কিছু করে। আমার ক্ষেত্রে আমি 256 এমবি র‌্যাম এবং অর্ধ মিলিয়ন ফাইল সহ ভার্চুয়াল সার্ভার দিয়ে চেষ্টা করেছি।

time find /test/directory | xargs rm ফলাফল:

real    2m27.631s
user    0m1.088s
sys     0m13.229s

তুলনা করা 

time perl -e 'opendir(FOO,"./"); @files = readdir(FOO); closedir(FOO); for (@files) { unlink $_; }'

real    0m59.042s
user    0m0.888s
sys     0m18.737s
— জানে পিক্করাইনে
সূত্র
আমি গ্লোব () কলটি কি করবে তা ভাবতে দ্বিধা করি; আমি ধরে নিলাম এটি একটি স্ক্যান্ডির () করে। যদি তাই হয়, এটি ফিরতে ফোরভার নিতে চলেছে। প্রথম পরামর্শটির একটি পরিবর্তন যা সমস্ত দির এন্ট্রিগুলিকে প্রাক-পঠিত না করে তার কিছু পা থাকতে পারে; তবে, এটির বর্তমান আকারে, এটি একবারে সমস্ত ডিরেক্টরি এন্ট্রিগুলি পড়ার জন্য একটি অপরিষ্কার পরিমাণ সিপিইউ ব্যবহার করবে। এখানে লক্ষ্যটির অংশটি হ'ল বিভাজন এবং জয় করা; এই কোডটি 'আরএম-ফ * .png' থেকে মূলত আলাদা নয়, শেল প্রসারণ নিয়ে সমস্যাগুলি সত্ত্বেও। যদি সাহায্য করে, সেখানে যে ডিরেক্টরি আমি কিছুই নেই হয়নি মুছে ফেলতে চাই।
— বিএমডান
আমি কাজ পাওয়ার সাথে সাথে আরও চেষ্টা করব। আমি কেবল একটি একক ডিরেক্টরিতে 100,000 ফাইল তৈরি করার চেষ্টা করেছি এবং + xargs + rm সংমিশ্রণটি 7.3 সেকেন্ড সময় নিয়েছে, পার্ল + আনলিংক (গ্লোব) ... মিশ্রণটি 2.7 সেকেন্ডের মধ্যে শেষ হয়েছে। সেই দু'বার চেষ্টা করেছিলেন, ফলাফল সবসময় একই রকম ছিল। কর্মক্ষেত্রে আমি আরও ফাইল দিয়ে এটি চেষ্টা করব।
— জান্নে পিক্কারাইনেন
আমি এটি পরীক্ষা করার সময় নতুন কিছু শিখেছি। অন্তত ext3 এবং ext4 দিয়ে ডিরেক্টরি এন্ট্রি নিজে থেকে সেখান থেকে সমস্ত ফাইল মোছার পরেও বিশাল থেকে যায়। বেশ কয়েকটি পরীক্ষার পরে আমার / টিএমপি / পরীক্ষার ডিরেক্টরিতে 15 এমবি ডিস্কের জায়গা লাগছিল taking ডিরেক্টরি মুছে ফেলা এবং এটি পুনরুদ্ধার করা ছাড়া কি পরিষ্কার করার অন্য কোনও উপায় আছে?
— জান্নে পিক্কারাইনেন
2
না, আপনাকে এটি পুনরায় তৈরি করতে হবে। আমি কোনও মেল-সিস্টেম এবং ফোল্ডার-প্রতি-প্রাপক এবং ক্লিনআপগুলির সাথে উল্লেখযোগ্য সমস্যাগুলির পরে যখন বিষয়টি নিয়ে কাজ করি তখন আমি এটিকে আঘাত করি: একটি নতুন ডিরেক্টরি তৈরি করা এবং ডিরেক্টরিগুলি বদলানো, তারপরে পুরানোটিকে স্তব্ধ করে তোলা ছাড়া উপায় নেই। সুতরাং যখন কোনও ডিরেক্টরি নেই তখন আপনি সময় উইন্ডো হ্রাস করতে পারবেন, তবে এটি সরিয়ে ফেলবেন না।
— ফিল পি
নোট করুন যে গ্লোব () ফলাফলগুলি শর্ট করবে, শেল গ্লোব্বিং সাধারণত যেমন করে, তাই আপনার কাছে কেবল 100k ফাইল রয়েছে তাই সমস্ত কিছু সহজেই ফিট হয় এবং সাজানো দ্রুততর হয়। অনেক বড় ডিরেক্টরি সহ, আপনি কেবল বাছাই এড়াতে ওপেনডির () / রিডডির () / ক্লোডির () রাখতে চান। [আমি সাধারণত শেলের জন্যই বলি , যেহেতু zsh এর বাছাইয়ের ক্রমটিকে অকার্যকর করতে করতে একটি গ্লোব সংশোধক রয়েছে, যা বিপুল সংখ্যক ফাইলের সাথে ডিল করার সময় কার্যকর; *(oN)]
— ফিল পি
1

আমি ext ফাইল সিস্টেমে ইনোডগুলি মুছে ফেলার বিষয়টি মনে রাখি সেগুলি হ'ল ও (এন ^ 2), সুতরাং আপনি যত বেশি ফাইল মুছবেন তত দ্রুত বিশ্রামগুলি চলে যাবে।

একসময় আমি একই ধরণের সমস্যার মুখোমুখি হয়েছিলাম (যদিও আমার অনুমানটি মুছে ফেলার সময়টি ~ 7h ডলারে দেখে) তবে শেষ পর্যন্ত জাফতুগা প্রথম মন্তব্যে পথের পরামর্শ দিল ।

— হুবার্ট করিও
সূত্র
0

ঠিক আছে, এটি আসল উত্তর নয়, তবে ...

ফাইল সিস্টেমটি এক্সট 4 এ রূপান্তর করা এবং জিনিসগুলি পরিবর্তন হচ্ছে কিনা তা কি সম্ভব?

— marcoc
সূত্র
দেখা যাচ্ছে যে এই "লাইভ" করার জন্য একটি মাউন্ট করা ফাইল সিস্টেমে একটি fsck প্রয়োজন, যা ... উদ্বেগজনক। একটি ভাল উপায় পেয়েছেন?
— বিএমডান
রূপান্তরকরণের আগে, অর্থাৎ প্রয়োজনীয় টিউনফস কমান্ডের আগে ফাইল সিস্টেমটি আনমাউন্ট করতে হবে।
— marcoc
0

ঠিক আছে, বাকি থ্রেডে এটি বিভিন্ন উপায়ে আচ্ছাদিত হয়েছে তবে আমি ভেবেছিলাম যে আমি আমার দুটি সেন্ট ফেলে দেব। আপনার ক্ষেত্রে পারফরম্যান্স অপরাধী সম্ভবত রিডডির। আপনি এমন কোনও ফাইলের তালিকা ফিরে পেয়ে যাচ্ছেন যে কোনওভাবেই ডিস্কের অনুক্রমিক নয় যা আপনি লিঙ্কমুক্ত করার সময় সমস্ত জায়গায় ডিস্ক অ্যাক্সেসের কারণ হয়ে থাকে। ফাইলগুলি এত ছোট যে আনলিংক অপারেশন সম্ভবত খুব বেশি জায়গা শূন্যের বাইরে লাফিয়ে উঠবে না। আপনি যদি রডডির এবং তার পরে আরোহণের ইনোড অনুসারে বাছাই করেন তবে আপনি সম্ভবত আরও ভাল পারফরম্যান্স পাবেন। সুতরাং র‌্যামডিয়ারে র‌্যামে প্রবেশ করুন (ইনোড অনুসারে বাছাই করুন) -> লিঙ্কমুক্ত করুন -> লাভ।

আইনোড এখানে মোটামুটি অনুমান হিসাবে মনে হয় .. তবে আপনার ব্যবহারের ক্ষেত্রে ভিত্তি করে এটি মোটামুটি সঠিক হতে পারে ...

— MattyB
সূত্র
1
আমি ভুল হলে আমাকে সংশোধন করুন, তবে আনলিংক করুন (২) ইনোডকে শূন্য করে না, এটি কেবল ডিরেক্টরি থেকে এটির উল্লেখটি সরিয়ে দেয়। যদিও আমি এই পদ্ধতির চুটজপাহ পছন্দ করি। কিছু সময়-ট্রায়াল চালানোর জন্য যত্নশীল এবং দেখুন এটি সত্য কিনা?
— বিএমডান
0

আমি সম্ভবত একটি সি সংকলক বেত্রাঘাত এবং আপনার স্ক্রিপ্ট এর নৈতিক সমতুল্য কাজ করতে হবে। এটি হ'ল opendir(3)ডিরেক্টরি হ্যান্ডেলটি ব্যবহার করুন, তারপরে readdir(3)ফাইলগুলির নাম পেতে ব্যবহার করুন , তারপরে ফাইলগুলি আনলিঙ্ক করার সাথে সাথে ট্যালি আপ করুন এবং একবারে "% d ফাইলগুলি মুছুন" (এবং সম্ভবত বিচ্ছিন্ন সময় বা বর্তমান সময়ের স্ট্যাম্প) মুদ্রণ করুন।

আমি শেল স্ক্রিপ্ট সংস্করণের তুলনায় এটি দ্রুত গতিযুক্ত হওয়ার প্রত্যাশা করি না, এটি কেবলমাত্র আমাকে বারবার সংকলকটি ছিঁড়ে ফেলার জন্য ব্যবহার করা হয়েছিল, কারণ শেল থেকে আমার যা করার তা করার কোনও পরিষ্কার উপায় নেই কারণ বা শেলটি করতে পারার সময়, এটি অনুন্নতভাবে সেভাবে ধীর করে দেয়।

— Vatine
সূত্র
তিনি কমপক্ষে কোর্টিলস থেকে আরএমের উত্স কোডটি পরিবর্তন করে শুরু করতে পারেন ।
— ক্রিশ্চিয়ান সিউপিতু
0

আপনি সম্ভবত ডিরেক্টরিটি নিয়ে পুনরায় লেখার সমস্যাগুলিতে চলেছেন। প্রথমে নতুনতম ফাইলগুলি মুছতে চেষ্টা করুন। মাউন্ট বিকল্পগুলি দেখুন যা ডিস্কের লিখনবাক স্থিত করবে।

একটি অগ্রগতি বার জন্য কিছু চালানোর চেষ্টা করুন rm -rv /mystuff 2>&1 | pv -brtl > /dev/null

— BillThor
সূত্র
প্রথমে সর্বাধিক নতুন ফাইলগুলি মুছে ফেলার ক্ষেত্রে: ls -Ur? আমি নিশ্চিত যে দির এন্ট্রিগুলি লোড করতাম, তারপরে তাদের বিপরীত করুন; আমি বিশ্বাস করি না যে এলএস দির এন্ট্রি তালিকার শেষে শুরু করার এবং পর্যায়ে ফিরে যেতে শুরু করতে যথেষ্ট স্মার্ট। "ls -1" সম্ভবত কোনও দুর্দান্ত ধারণা নয়, যেহেতু এটি চালাতে 50+ এমবি কোর এবং কয়েক মিনিট সময় লাগবে; আপনি "ls -U" বা "ls -f" চান।
— বিএমডান
ফাইলের নামগুলি অনুমানযোগ্য প্যাটার্নে বৃদ্ধি পেলে এটি সম্ভবত ব্যবহারিক। তবে আপনি আমার চেষ্টা করেছেন ls -1 বিপরীত করতে পাইপ করেছেন, এবং xargs এ পাইপ করেছেন। আপনি যদি নিজের মধ্যবর্তী ফলাফলগুলি দেখতে চান তবে পাইপের পরিবর্তে ফাইলগুলি ব্যবহার করুন। আপনি ফাইলের নামকরণ সম্পর্কিত কোনও তথ্য সরবরাহ করেন নি। আপনি বিপরীতে প্যাটার তৈরি করতে এবং প্যাটার্নটি ব্যবহার করে ফাইলগুলি মুছবেন। আপনার অনুপস্থিত ফাইল এন্ট্রিগুলি পরিচালনা করতে হতে পারে। প্রয়োজনীয় মেমরির বিষয়ে আপনার মন্তব্য দেওয়া, আপনাকে ডিরেক্টরিটি আবারও লিখতে হবে I / O সম্পর্কে একটি ধারণা রয়েছে।
— বিলথোর
0

এখানে আমি লক্ষ লক্ষ ট্রেস ফাইলগুলি কীভাবে মুছে ফেলি যা মাঝে মাঝে একটি বড় ওরাকল ডাটাবেস সার্ভারে সংগ্রহ করতে পারে:

for i in /u*/app/*/diag/*/*/*/trace/*.tr? ; do rm $i; echo -n . ;  done

আমি দেখতে পেয়েছি যে এটির ফলে সার্ভারের পারফরম্যান্সের উপর কম প্রভাব ফেলেছে মোটামুটি ধীর মুছে ফেলার ক্ষেত্রে, সাধারণত "টিপিকাল" 10,000 আইওপিএস সেটআপে মিলিয়ন ফাইল প্রতি এক ঘন্টার লাইন ধরে something

ডিরেক্টরিগুলি স্ক্যান করার আগে, প্রাথমিক ফাইল তালিকা তৈরি করা হয় এবং প্রথম ফাইলটি মুছে ফেলা হতে প্রায় বেশ কয়েক মিনিট সময় লাগবে। সেখান থেকে এবং ক। মুছে ফেলা প্রতিটি ফাইলের জন্য প্রতিধ্বনিত হয়।

টার্মিনালে প্রতিধ্বনিত হওয়ার কারণে যে বিলম্ব হয়েছে তা মুছে ফেলার প্রক্রিয়া চলাকালীন কোনও উল্লেখযোগ্য লোড রোধ করতে যথেষ্ট বিলম্ব প্রমাণিত হয়েছে।

— রায়
সূত্র
আপনি গ্লোব করে জীবিত খাওয়া হচ্ছে। কিভাবে আরো ভালো কিছু সম্পর্কে: find /u* -maxdepth 3 -mindepth 3 -type d -path '*/app/*' -name diag -print0 | xargs -0I = find = -mindepth 4 -maxdepth 4 -type d -name 'trace' -print0 | xargs -0I = find = -mindepth 1 -maxdepth 1 -name '*.tr'? -deleteজিনিসগুলি মুছতে সর্বশেষে যুক্ত করুন ; লিখিত হিসাবে, এটি কেবল এটি মুছে ফেলবে তা তালিকাভুক্ত করে। নোট করুন যে আপনার নিকটবর্তী ডিরেক্টরিতে প্রচুর উদ্বেগজনক জিনিস রয়েছে এমন পরিস্থিতিতে এটি অনুকূলিত হয়েছে; যদি এটি না হয় তবে আপনি যুক্তিটিকে অনেক সহজ করে তুলতে পারেন।
— বিএমডান
ফাইন্ড-ডিলিট প্রচুর পরিমাণে I / O তৈরি করে এবং সহজেই উত্পাদন কর্মক্ষমতাকে প্রভাবিত করে। সম্ভবত আয়নিস দিয়ে।
— রায়
এটি কেবলমাত্র আরও দক্ষ হয়েই I / O এর সমস্ত কারণ ঘটায়! Globbing সব ফ্রন্ট লোড আপনার উদাহরণস্বরূপ (যেমন, ফাইল সম্পূর্ণ তালিকা আগে প্রথম উৎপন্ন হয় rmঘটবে) সুতরাং আপনি যে থেকে প্রারম্ভে অপেক্ষাকৃত দক্ষ ইনপুট / আউটপুট আছে, দ্বারা বেদনাদায়ক, আউট-অফ-অর্ডার অনুসৃত rmগুলি এটি সম্ভবত খুব বেশি I / O সৃষ্টি করে না, তবে scandirবার বার ডিরেক্টরি চালানো জড়িত (এটি I / O এর কারণ নয় কারণ এটি ইতিমধ্যে ব্লক ক্যাশে লোড হয়েছে; এছাড়াও দেখুন vfs_cache_pressure)। আপনি যদি জিনিসগুলি ধীর করতে চান ioniceতবে এটি একটি বিকল্প, তবে আমি সম্ভবত ভগ্নাংশ-দ্বিতীয় sleepসেকেন্ড ব্যবহার করব ।
— বিএমডান
find /u*/app/*/diag -path '*/trace/*.tr' -execdir rm {} +rmডিরেক্টরি প্রতি এক চালানো হবে , যাতে আপনার কম CPU ওভারহেড থাকে। যতক্ষণ না আপনার হাতে প্রচুর পরিমাণ সিপিইউ সময় থাকে, ডিস্ক আইও থ্রোল্টলিং rmপ্রতিটি unlinkকাজের জন্য একটি সম্পূর্ণ প্রক্রিয়া তৈরি করে আমার ধারণা, তবে এটি কুৎসিত। লিঙ্কপ্রতিতে একটি ঘুম সহ পার্ল ভাল হবে যদি rmএকসাথে পুরো ডিরেক্টরিগুলির মধ্যে ঘুমানো খুব ফেটে যায়। ( -execdir sh -c ...সম্ভবত)
— পিটার কর্ডেস
-1

আপনি 'xargs' সমান্তরাল বৈশিষ্ট্য ব্যবহার করতে পারেন:

ls -1|xargs -P nb_concurrent_jobs -n nb_files_by_job rm -rf
— জেরেমি
সূত্র
1
এই সাহায্য করবে না। বাধা হ'ল ড্রাইভে থাকা দুর্বল র্যান্ডম I / O। সমান্তরাল মুছে ফেলাগুলি এটি আরও খারাপ করতে পারে এবং কেবল সিপিইউ লোড বাড়িয়ে তুলতে পারে।
— উইম কেরখফ
-2 
ls|cut -c -4|sort|uniq|awk '{ print "rm -rf " $1 }' | sh -x
— karmawhore
সূত্র
1
কি দারুন. আমার ধারণা, "বিড়ালের চামড়ার একাধিক উপায়ে" ক্যাম্পে দৃ firm়ভাবে পড়ে যায় falls মারাত্মকভাবে, যদিও, বাছাই এবং uniq সঙ্গে? "ls" ডিফল্টরূপে, যাইহোক, বাছাই করুন এবং আমি নিশ্চিত যে ফাইলের নামগুলি অনন্য। : /
— বিএমডান
-2

আসলে, আপনি যদি শেলটি ব্যবহার করেন শেলটি কমান্ড লাইনটি প্রসারিত করে তবে এটি একটু ভাল one

ls|cut -c -4|sort|uniq|awk '{ print "echo " $1 ";rm -rf " $1 "*"}' |sh
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.