Оптимизация скрипта очистки хранилища архивов

Запускай каждые сутки по расписанию

По идее можно читать через tar —list | while read. Как только нашёл два вхождения — обрываешь цикл.

программирую на HTML.

какой то новый язык программирования?

А Модест устал ждать(((

смени HTML на CSS.

Модест должен добавить кеширование

Модест должен с каждым .tgz архивом фоток держать .meta файл с описанием содержимого архива

У Модеста должно получиться что-то в духе

dir1/dir2/dir3 
   alice.tar.gz
   alice.tar.gz.meta
   bob.tar.gz
   bot.tar.gz.meta

В файле <name>.tar.gz.meta должны содержаться строчки в формате:

<filename.fits> md5sum
<filename2.fits> md5sum 

В этом случае Модесту нужно будет awk/grep/sed парсить .meta файлы и делать необходимые операции на лету.

Для этого модесту нужно добавить поддержку .meta файлов в свои кодец, но Модест HTML программист и ничего не поймет что я ему написал

А не надо работать с доисторическими технологиями. На более интересных инструментах всё элементарно решается:

(defn has-n-lins? [n start line]
  (if (= 0 n) true ;; нашли нужное количество файлов и остановились
      (let [end (str/index-of line "\n" start)] ;; нашли ещё одно вхождение и продолжили
        (when end (recur (dec n ) (inc end) line)))))

user> (->> "/tmp/enc/enc.tar" (shell {:out :string} "tar --list -f ") :out (has-n-lins? 2 0))
true
user> (->> "/tmp/enc/enc.tar" (shell {:out :string} "tar --list -f ") :out (has-n-lins? 22 0))
nil

я так понимаю что основная проблема - это время на запуск tar list -f, а не на то каким образом его запускать

Тут у меня оптимизируется часть, которая сначала пересчитывает все файлы, а потом сравнивает их количество с заданным пределом. Теоретически можно и это ускорить, но тут нужно свой tar --list писать, а это несколько многовато.

Без этого единственное серьёзное ускорение даст паралельная обработка архивов. Понятно, тут babashka тоже лучше баша.

vas199228, попробуйте для начала вот такую конструкцию

ВАЖНО тестируйте в изолированной песочнице!

cat ${ARCHI_LIST} | xargs -P$(nproc) -I% sh -c 'tar --list --file=% --wildcards "*.fits" | awk "(NR == 2) { print \"%\"; exit }"' | tee ${RM_LIST} 

Единственный момент, что «множество» запущенных параллельно процессов могут написать в stdout одновременно и получится «кашица», для этого нужно немного переделать скрипт:

cat ${ARCHI_LIST} | xargs -P$(nproc) -I% sh -c 'tar --list --file=% --wildcards "*.fits" | awk "(NR == 2) { exit 1 }" || echo % > %.rm' && find . -type f -iname "*.rm" -exec sh -c 'cat {}; rm {}' \; | tee ${RM_LIST}

ugoday как это будет на барабашке?

(defn has-n-files? [archive-file n]
"true если в архиве есть больше n файлов"
  (-> (shell {:out :string}
              "tar --list -f"
              archive-file)
       :out
       (str/split #"\n")
       count
       (> n)))

(->> archives  ;; по архивам
     (pmap #(when (has-n-files? % 2) %)) ;; параллельно пробегаемся
     (remove nil?)) ;; убираем негодные (последовательно, потому как всё одно быстро).

Ключевая функция тут pmap, которая как map только работает параллельно для каждого элемента коллекции, а потом склеивает результат.

Очень хорошо, я проглядел «вскользь» документацию, как задается количество параллельных потоков?

В данном случае — никак, pmap стандартно использует количество ядер + 2 потока. А вообще, babashka — это clojure, который весь построен вокруг плясок с конкурентностью и паралелизмом, так что можно сделать что угодно, смотря где у нас тормоза, в диске или в цпу. Но это чуть больше кода, а для демонстрации pmap и выглядит кратко и разумное значение по умолчанию предоставляет.

В данном случае — никак, pmap стандартно использует количество ядер + 2 потока

Это печально, это не позволяет использовать барабаршку в ряде случаев, когда нужно точно контролировать количество параллельных потоков

так что можно сделать что угодно

я так понимаю что лимитировать количество параллельных потоков можно, но нужны «специальные» упражнения

pmap и выглядит кратко и разумное значение по умолчанию предоставляет.

выглядит красиво, и выразительнее, но на условном, абстрактном, «удаленном хосте» барабашка проигрывает oneliner с xargs

Вы забываете, что babashka — это гораздо более выразительный язык.

(defn my-pmap [f n coll]
  (let [rets (map #(future (f %)) coll)
        step (fn step [[x & xs :as vs] fs]
               (lazy-seq
                (if-let [s (seq fs)]
                  (cons (deref x) (step xs (rest s)))
                  (map deref vs))))]
    (step rets (drop n rets))))

И теперь у нас есть параллельное отображение, с точно контролируемым (параметр n) количеством исполнительных потоков. А захочется, можно использовать core.async чтобы асинхронно задачи по каналам гонять или напрямую использовать Java Executor Framework.

Собственно, недостаток и серьёзный у бабашки один, вытекающий из достоинств — нужна java машина для работы. Но раз уж у нас она уже есть, то ограничений в принципе никаких нет.

очень хорошо, я спокоен, за 20+ лет использования онлайнеров с xargs они все еще в тренде ;-)

Модест устал ждать...

И чо?