سؤال جمهورية مقدونيا على دليل مع الملايين من الملفات


الخلفية: الخادم الفعلي ، حوالي عامين ، محركات أقراص SATA بسرعة 7200 دورة في الدقيقة متصلة ببطاقة RAID 3Ware ، و ext3 FS شنت noatime والبيانات = أمر ، وليس تحت الحمل المجنون ، kernel 2.6.18-92.1.22.el5 ، وقت التشغيل 545 يومًا . لا يحتوي الدليل على أي أدلة فرعية ، فقط ملايين الملفات الصغيرة (~ 100 بايت) ، مع بعض أكبر منها (عدد قليل من KB).

لدينا خادم ذهب قليلاً من الوقواق على مدار الأشهر القليلة الماضية ، ولكننا لاحظنا ذلك فقط في اليوم الآخر عندما بدأ غير قادر على الكتابة إلى دليل بسبب احتوائه على عدد كبير جدًا من الملفات. على وجه التحديد ، بدأت في عرض هذا الخطأ في / var / log / messages:

ext3_dx_add_entry: Directory index full!

يحتوي القرص المعني على الكثير من inodes المتبقية:

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

لذلك أنا أعتقد أن هذا يعني أننا وصلنا إلى الحد الأقصى لعدد الإدخالات في ملف الدليل نفسه. لا توجد فكرة عن عدد الملفات التي يمكن أن تكون ، ولكن لا يمكن أن يكون أكثر ، كما ترون ، من ثلاثة ملايين أو نحو ذلك. ليس هذا جيد ، مانعًا لك! لكن هذا جزء من سؤالي: بالضبط ما هو الحد الأعلى؟ هل هو الانضباطي؟ قبل الصراخ - أريد أن أضبطه أسفل. هذا الدليل الهائل تسبب في كل أنواع القضايا.

على أي حال ، لقد تتبعنا المشكلة في الشفرة التي تولد كل تلك الملفات ، وقمنا بتصحيحها. الآن أنا عالق مع حذف الدليل.

بعض الخيارات هنا:

  1. rm -rf (dir)

حاولت هذا أولا. استسلمت وقلت بعد أن ركضت لمدة يوم ونصف دون أي أثر واضح.

  • إلغاء الربط (2) في الدليل: بالتأكيد يستحق النظر ، ولكن السؤال هو ما إذا كان من الأسرع حذف الملفات داخل الدليل عبر fsck بدلاً من الحذف عبر إلغاء الربط (2). وهذا هو ، بطريقة أو بأخرى ، لقد حصلت على علامة تلك inodes كما غير المستخدمة. هذا يفترض ، بطبيعة الحال ، أنني يمكن أن أقول fsck لا لإسقاط إدخالات على الملفات في / فقدت + وجدت ؛ خلاف ذلك ، لقد انتقلت للتو مشكلتي. بالإضافة إلى جميع المخاوف الأخرى ، بعد القراءة عن هذا أكثر قليلاً ، اتضح أنه من المحتمل أن أستدعي بعض وظائف FS الداخلية ، حيث أن أياً من اختلافات (2) التي لا يمكنني العثور عليها ستسمح لي بحذفها بمنتهى السهولة. دليل مع الإدخالات في ذلك. بو.
  • while [ true ]; do ls -Uf | head -n 10000 | xargs rm -f 2>/dev/null; done )
  • هذا هو في الواقع نسخة مختصرة. النوع الحقيقي الذي أقوم بتشغيله ، والذي يضيف فقط بعض تقارير التقدم والتوقف النظيف عندما نفد الملفات لحذفها ، هو:

    تصدير i = 0 ؛
    الوقت (في حين [صحيح] ؛ القيام به
      ls -Uf | head -n 3 | grep -qF '.png' || استراحة؛
      ls -Uf | head -n 10000 | xargs rm -f 2> / dev / null؛
      export i = $ (($ i + 10000))؛
      صدى "$ i ..."؛
    فعله )

    يبدو أن هذا يعمل بشكل جيد. أثناء كتابتي هذا ، تم حذف 260،000 ملف في الثلاثين دقيقة الماضية أو ما شابه.


    97
    2017-09-22 23:57


    الأصل


    يحتوي rm (GNU coreutils) 8.4 على هذا الخيار: "-v ، --verbose أشرح ما يجري". سيعرض كل الملفات التي يتم حذفها. - Cristian Ciupitu
    في الواقع ، ستكون هذه طريقة رائعة للقيام بشريط تقدم: نظرًا لأن كل ملف سيكون بطول سبعة وثلاثين حرفًا (36 + a '\ n') ، يمكنني بسهولة كتابة المحلل اللغوي لذلك ، وبما أن printf () رخيصة وأمر RM بالفعل اسم الملف المحملة ، وليس هناك عقوبة الأداء الخاص. يبدو وكأنه غير بداية للقيام shebang كله ، لأنني لا يمكن أبدا الحصول على "RM" للقيام بأي شيء من هذا القبيل ، على أي حال. ولكن يمكن أن تعمل بشكل جيد كشريط تقدم داخل 10،000. ربما "." لكل مائة ملف؟ - BMDan
    rm -rfv | pv -l >/dev/null. ينبغي أن تكون متاحة pv في EPEL مستودع. - Cristian Ciupitu
    الكهروضوئية هو رائع بشكل ساحق. أترك درب من المنشآت الكهروضوئية في أعقابها. - BMDan
    كان لدي هذه المشكلة نفسها بالضبط في الآونة الأخيرة. شكرا جزيلا! - richo


    الأجوبة:


    ال data=writeback يستحق خيار التحميل ، من أجل منع تسجيل يوميات نظام الملفات. يجب القيام بذلك فقط أثناء وقت الحذف ، ولكن هناك مخاطرة إذا تم إيقاف تشغيل الملقم أو إعادة تشغيله أثناء عملية الحذف.

    بالنسبة الى هذه الصفحة،

    تُظهر بعض التطبيقات تحسينًا كبيرًا للسرعة عند استخدامها. على سبيل المثال ، يمكن رؤية تحسينات السرعة (...) عندما تقوم التطبيقات بإنشاء وحذف كميات كبيرة من الملفات الصغيرة.

    يتم تعيين الخيار إما في fstab أو أثناء عملية التحميل ، استبدال data=ordered مع data=writeback. يجب إعادة حساب نظام الملفات الذي يحتوي على الملفات المراد حذفها.


    30
    2017-09-26 05:49



    يمكنه أيضا زيادة الوقت من commit  اختيار: "هذه القيمة الافتراضية (أو أي قيمة منخفضة) ستؤذي الأداء ، ولكنها جيدة لسلامة البيانات. سيؤدي تعيينه إلى 0 إلى نفس التأثير مثل تركه في الوضع الافتراضي (5 ثوانٍ). سيتم تعيينه إلى قيم كبيرة جدًا تحسين الأداء". - Cristian Ciupitu
    الكتابة تبدو ممتازة ، باستثناء الوثائق التي كنت أبحث عنها (gentoo.org/doc/en/articles/l-afig-p8.xml#doc_chap4) يشير صراحة إلى أنه لا يزال يحتوي على بيانات وصفية ، والتي أفترض أنها تتضمن جميع البيانات التي أقوم بتغييرها (أنا بالتأكيد لا أغير أي بيانات في الملفات نفسها). هل فهمتي للخيار غير صحيح؟ - BMDan
    وأخيرًا ، لم يتم ذكر FYI في هذا الرابط أن البيانات = writeback قد تكون ثغرة أمنية كبيرة ، نظرًا لأن البيانات المشار إليها بواسطة إدخال معين قد لا تحتوي على البيانات التي تم كتابتها هناك من قبل التطبيق ، مما يعني أن حدوث عطل قد ينتج في البيانات القديمة ، وربما الحساسة / الخاصة التي يتم كشفها. لا يهم هنا ، لأننا لا نستخدمها إلا مؤقتًا ، ولكنني أردت تنبيه الجميع إلى هذا التحذير في حال لم تكن أنت أو غيرك ممن يديرون هذا الاقتراح على علم بذلك. - BMDan
    ارتكاب: هذا البقعة جميلة! شكرا على المؤشر. - BMDan
    data=writeback لا تزال البيانات الوصفية المجلات قبل كتابته في نظام الملفات الرئيسي. كما أفهمها ، إنها لا تفرض الأوامر بين أشياء مثل كتابة خريطة المدى وكتابة البيانات في هذه النطاقات. ربما هناك قيود ترتيب أخرى أنها ترتاح ، أيضا ، إذا كنت ترى مكاسب من هذا الكمال. بالطبع ، يمكن أن يكون التثبيت بدون المجلة على الإطلاق مستوى أداء أعلى. (قد يسمح بتغيير بيانات التعريف يحدث في ذاكرة الوصول العشوائي ، دون الحاجة إلى وجود أي شيء على القرص قبل اكتمال إلغاء ارتباط الرابط). - Peter Cordes


    في حين أن السبب الرئيسي لهذه المشكلة هو أداء ext3 مع الملايين من الملفات ، يختلف السبب الحقيقي لهذه المشكلة.

    عندما يحتاج الدليل إلى سرد يتم استدعاء readdir () على الدليل الذي ينتج قائمة بالملفات. readdir عبارة عن مكالمة posix ، ولكن استدعاء نظام Linux الحقيقي المستخدم هنا يسمى "getdents". إدخالات دليل قائمة Getdents عن طريق ملء مخزن مؤقت مع الإدخالات.

    المشكلة هي أساسا إلى حقيقة أن هذا readdir () يستخدم حجم مخزن مؤقت ثابت من 32 كيلوبايت لجلب الملفات. عندما يصبح الدليل أكبر وأكبر (يزيد الحجم كلما أضيفت الملفات) ، يصبح ext3 أبطأ وأبطأ في إدخال الإدخالات ، ويكون حجم المخزن المؤقت 32 كيلو بايت للقراءة فقط كافياً لتضمين جزء من الإدخالات في الدليل. هذا يسبب readdir لحلقة مرارا وتكرارا واستدعاء دعوة النظام باهظة الثمن مرارا وتكرارا.

    على سبيل المثال ، في دليل اختبار قمت بإنشائه بأكثر من 2.6 مليون ملف بالداخل ، يعرض تشغيل "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
    

    طريقة لجعل هذه العملية أكثر كفاءة هي استدعاء getdents يدويا مع مخزن مؤقت أكبر بكثير. هذا يحسن الأداء بشكل ملحوظ.

    الآن ، ليس من المفترض أن تتصل ب Getdents بنفسك يدويًا ، لذا لا توجد واجهة لاستخدامها بشكل طبيعي (تحقق من صفحة الرجل لكي ترى getdents!) ، يستطيع نسميها يدويًا واجعل طريقة الدعوة إلى استدعاء النظام أكثر كفاءة.

    هذا يقلل بشكل كبير من الوقت المستغرق لجلب هذه الملفات. لقد كتبت برنامجًا يقوم بذلك.

    /* 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);
    }
    

    في حين أن هذا لا يكافح المشكلة الأساسية الكامنة (الكثير من الملفات ، في نظام ملفات يعمل بشكل سيئ في ذلك). من المرجح أن يكون ذلك أسرع بكثير من العديد من البدائل التي يتم نشرها.

    ك a فكر ، واحد يجب أن يزيل الدليل المصاب ويعيد صنعه بعد. تزداد الدلائل من حيث الحجم فقط ويمكن أن تظل ضعيفة الأداء حتى مع وجود بعض الملفات داخلها نظرًا لحجم الدليل.

    تصحيح: لقد نظفت هذا قليلا جدا. إضافة خيار للسماح لك بحذف على سطر الأوامر في وقت التشغيل وإزالة مجموعة من الأشياء treewalk التي ، بصراحة ينظر إلى الوراء كان موضع شك في أحسن الأحوال. كما أظهر لإنتاج الفساد الذاكرة.

    يمكنك الآن القيام به dentls --delete /my/path

    نتائج جديدة. انطلاقا من دليل يحتوي على 1.82 مليون ملف.

    ## 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
    

    كان مندهشا من هذا لا يزال يعمل على ما يرام!


    73
    2017-11-06 19:06



    اهتمامات ثانوية بسيطة: واحد ، [256] يجب أن يكون على الأرجح [FILENAME_MAX]، واثنين ، بلدي لينكس (2.6.18 == CentOS 5.x) لا يبدو أن تشمل إدخال نوع d_type في ديرنت (على الأقل وفقا ل getdents (2)). - BMDan
    هل يمكن أن تشرح قليلاً عن إعادة التوازن btree ولماذا الحذف بالترتيب يساعد على منع ذلك؟ حاولت Googling لذلك ، للأسف دون جدوى. - ovgolovin
    لأنه يبدو لي الآن أنه إذا تم حذف الطلب ، فإننا نجبر إعادة التوازن ، حيث نزيل الأوراق من جهة ونتركها على الجانب الآخر: en.wikipedia.org/wiki/B-tree#Rebalancing_after_deletion - ovgolovin
    آمل ألا أزعجك بهذه الأمور. ولكن ما زلت بدأت سؤال حول حذف الملفات بالترتيب stackoverflow.com/q/17955459/862380والذي يبدو أنه لا يحصل على إجابة تشرح المشكلة بالمثال الذي سيكون مفهومًا للمبرمجين العاديين. إذا كان لديك الوقت وترغب في ذلك ، هل يمكن أن تنظر في الأمر؟ ربما يمكنك كتابة تفسير أفضل. - ovgolovin
    هذه قطعة مدهشة من التعليمات البرمجية. كانت الأداة الوحيدة التي تمكنت من العثور على قائمة وحذف حوالي 11،000،000 (11000000) من ملفات الجلسات التي تراكمت في دليل ، ربما على مدى عدة سنوات. لم تكن عملية Plesk التي كان من المفترض أن تبقيها تحت السيطرة باستخدام البحث والحيل الأخرى في إجابات أخرى هنا ، قادرة على إكمال عملية تشغيل ، لذلك ظلت الملفات تتراكم. وهو عبارة عن تكريم للشجرة الثنائية التي يستخدمها نظام الملفات لتخزين الدليل ، والتي تمكنت الجلسات من العمل على الإطلاق - يمكنك إنشاء ملف واسترجاعها بدون أي تأخير. مجرد قوائم كانت غير صالحة للاستعمال. - Jason


    هل من الممكن إجراء نسخ احتياطي لكافة الملفات الأخرى من نظام الملفات هذا إلى موقع تخزين مؤقت ، وإعادة تهيئة القسم ، ثم استعادة الملفات؟


    31
    2017-09-23 00:27



    أنا حقا أحب هذه الإجابة ، في الواقع. كمسألة عملية ، في هذه الحالة ، لا ، ولكنها ليست واحدة كنت قد فكرت في. برافو! - BMDan
    بالضبط ما كنت أفكر أيضا. هذا إجابة سؤال 3. مثالي إذا سألتني :) - Joshua


    لا يوجد حد لكل ملف في المجلد ext3 فقط الحد من inode نظام الملفات (أعتقد أن هناك حد على عدد من الدلائل الفرعية رغم ذلك).

    قد لا تزال تواجه مشاكل بعد إزالة الملفات.

    عندما يحتوي الدليل على ملايين الملفات ، يصبح إدخال الدليل نفسه كبيرًا جدًا. يجب فحص إدخال الدليل لكل عملية إزالة ، والتي تستغرق وقتًا مختلفًا لكل ملف ، حسب المكان الذي يوجد فيه الدخول. للأسف حتى بعد إزالة كافة الملفات ، يحتفظ إدخال الدليل بحجمه. لذلك ستستغرق العمليات الإضافية التي تتطلب فحص إدخال الدليل وقتًا طويلاً حتى إذا كان الدليل فارغًا الآن. الطريقة الوحيدة لحل هذه المشكلة هي إعادة تسمية الدليل ، وإنشاء واحدة جديدة بالاسم القديم ، ونقل أي ملفات متبقية إلى واحدة جديدة. ثم احذف إعادة تسمية واحدة.


    11
    2017-09-23 05:45



    في الواقع ، لقد لاحظت هذا السلوك فقط بعد حذف كل شيء. لحسن الحظ ، لقد قمنا بالفعل بإخراج الدليل من "خط النار" ، كما كان ، حتى أتمكن من تحديده. - BMDan
    ومع ذلك ، إذا لم يكن هناك حد للملف لكل دليل ، فلماذا أحصل على "ext3_dx_add_entry: فهرس الدليل ممتلئ!" عندما كان لا يزال هناك inodes المتاحة على هذا القسم؟ لم تكن هناك أدلة فرعية داخل هذا الدليل. - BMDan
    لقد قمت بعمل المزيد من الأبحاث ويبدو أن هناك حدًا لعدد الكتل التي يمكن أن يتناولها الدليل. يعتمد العدد الدقيق للملفات على بعض الأشياء مثل طول اسم الملف. هذه gossamer-threads.com/lists/linux/kernel/921942 يبدو أنه يشير إلى أنه مع كتل 4K يجب أن يكون لديك أكثر من 8 ملايين ملف في الدليل. هل كانت أسماء الملفات طويلة جدًا؟ - Alex J. Roberts
    كان كل اسم ملف 36 حرفًا. - BMDan
    حسنا هذا أنا من الأفكار :) - Alex J. Roberts


    لم أقم بقياسها ، لكن هذا الرجل فعل:

    rsync -a --delete ./emptyDirectoty/ ./hugeDirectory/
    

    5
    2018-06-04 11:52





    تجد ببساطة لم تنجح بالنسبة لي ، حتى بعد تغيير المعلمات ext3 خ م كما اقترح من قبل المستخدمين أعلاه. طريقة المستهلكة الكثير من الذاكرة. هذا البرنامج النصي PHP فعل خدعة - استخدام وحدة المعالجة المركزية بسرعة تافهة ، استخدام الذاكرة تافه:

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

    لقد نشرت تقريرًا عن الخطأ يتعلق بمشكلة العثور على: http://savannah.gnu.org/bugs/؟31961


    4
    2017-12-23 19:54



    هذا أنقذني !! - jestro


    لقد واجهت مؤخرًا مشكلة مماثلة ولم أتمكن من الحصول على ring0 data=writeback اقتراح للعمل (ربما يرجع ذلك إلى حقيقة أن الملفات موجودة على القسم الرئيسي الخاص بي). أثناء البحث عن الحلول التي تعثرت عليها:

    tune2fs -O ^has_journal <device>
    

    سيؤدي هذا إلى إيقاف عمل اليومية تمامًا ، بغض النظر عن data الخيار يعطي ل mount. أنا جمعت هذا مع noatime وكان حجم dir_index مجموعة ، ويبدو أنها تعمل بشكل جيد. انتهى الحذف فعليًا دون الحاجة لقتله ، واستمر النظام في الاستجابة ، وأصبح الآن جاهزًا للعمل (مع إعادة تشغيل دفتر اليومية) بدون أية مشكلات.


    3
    2018-04-23 22:29



    كنت سأقترح تركيبه كـ ext2 بدلاً من ext3 ، لتجنب تسجيل يومية بيانات التعريف. هذا يجب أن تفعل الشيء نفسه. - Peter Cordes


    تأكد من القيام:

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

    والتي يجب أن تسرع الأمور قليلاً أيضًا.


    3
    2017-09-27 02:03



    مكالمة جيدة ، ولكن تم تحميلها بالفعل noatime ، كما ذكرت في العنوان على السؤال. و nodiratime هو زائدة عن الحاجة. نرى lwn.net/Articles/245002 . - BMDan
    PPL تكرار هذا الشعار "noatime ، nodiratime ، nodevatime ، noreadingdocsatime" - poige


    ليرة سورية بطيئة جدا. محاولة:

    find /dir_to_delete ! -iname "*.png" -type f -delete
    

    2
    2017-09-23 04:04



    ركض rm -rf لمدة يوم ونصف ، وأخيراً قمت بقتلها ، دون أن أعرف ما إذا كانت قد أنجزت أي شيء. كنت بحاجة إلى شريط التقدم. - BMDan
    إلى rm يجري بطيئة جدا ، "العثور على الوقت. حذف" على ملفات 30K: 0m0.357s / 0m0.019s / 0m0.337s حقيقي / المستخدم / تميز الكلية. "time (ls –1U | xargs rm -f)" على نفس الملفات: 0m0.366s / 0m0.025s / 0m0.340s. وهو في الأساس إقليم هامش الخطأ. - BMDan
    هل يمكن أن يكون مجرد تشغيل strace -r -p <pid of rm> لتعلق على عملية RM قيد التشغيل بالفعل. ثم يمكنك أن ترى مدى السرعة unlink يتم تمرير مكالمات النظام الماضي. (-r يضع الوقت منذ مكالمة النظام السابقة في بداية كل سطر.) - Peter Cordes