Сложность поиска дубликатов файлов в bash

я постараюсь качественно ответить, насколько быстры тесты существования файлов на tmpfs, а затем я могу предложить, как вы можете заставить всю вашу программу работать быстрее.

во-первых, поиск каталогов tmpfs полагается (в ядре) на поиск хэш-таблицы кэша записей каталогов, которые не так чувствительны к количеству файлов в вашем каталоге. Они затронуты, но сублинейно. Это связано с тем, что правильный поиск хэш-таблицы занимает некоторое постоянное время,O(1), независимо от количество элементов в хэш-таблице.

объяснить, мы можем посмотреть на работы test -f или [ -f X ], из coreutils (gitweb будет):

case 'e':
   unary_advance ();
   return stat (argv[pos - 1], &stat_buf) == 0;
... 
case 'f':                   /* File is a file? */
   unary_advance ();
   /* Under POSIX, -f is true if the given file exists
      and is a regular file. */
   return (stat (argv[pos - 1], &stat_buf) == 0
           && S_ISREG (stat_buf.st_mode));

поэтому он использует stat() на имя напрямую. Никакой список каталогов не выполняется явно test, но и время выполнения stat может зависеть от количества файлов в каталоге. Время завершения для stat вызов будет зависеть от unterlying файловой системы реализация.

для каждой файловой системы stat разделит путь на компоненты каталога и проведет его вниз. Например, для пути /tmp/hashes/the_md5: во-первых /, получает свой индекс, затем смотрит вверх tmp внутри него, получает этот индекс (это новая точка монтирования), затем получает hashes inode, и, наконец, затем тестовое имя файла и его индекс. Вы можете ожидать, что inodes полностью /tmp/hashes/ кэшироваться, потому что они повторяются на каждой итерации, поэтому эти поиски являются быстрыми и вероятно, не требуется доступ к диску. Каждый поиск будет зависеть от файловой системы, в которой находится родительский каталог. После /tmp/ часть, поиск происходит на tmpfs (что все в памяти, за исключением случаев, когда у вас заканчивается память и вам нужно использовать swap).

tmpfs в linux полагается на simple_lookup для получения индекса файла в каталоге. tmpfs находится под своим старым именем в дереве linux mm / shmem.c . tmpfs, как и ramfs, похоже, не реализует данные собственные структуры для отслеживания виртуальных данных он просто полагается на кэши записей каталога VFS (под Кэш Записей Каталога).

поэтому я подозреваю, что поиск индекса файла в каталоге так же прост, как поиск хэш-таблицы. я бы сказал, что пока все ваши временные файлы помещаются в вашу память, и вы используете tmpfs/ramfs, не имеет значения, сколько файлов есть-это O(1) Поиск каждый раз.

другие файловые системы как и Ext2 / 3, однако, будет нести линейный штраф с количеством файлов, присутствующих в каталоге.

хранение их в

как предлагали другие, вы также можете хранить MD5 в памяти, сохраняя их в переменных bash, и избегать штрафов файловой системы (и связанных syscall). Сохранение их в файловой системе имеет то преимущество, что вы можете возобновить с того места, где вы оставили, если вы должны были прервать цикл (ваш md5 может быть символической ссылкой на файл, дайджест которого соответствует, на который вы могли бы положиться, при последующих запусках), но медленнее.

MD5=d41d8cd98f00b204e9800998ecf8427e
let SEEN_${MD5}=1
...
digest=$(md5hash_of <filename>)
let exists=SEEN_$digest
if [[ "$exists" == 1 ]]; then
   # already seen this file
fi

более быстрые тесты

и вы можете использовать [[ -f my_file ]] вместо [ -f my_file ]. Команда [[ является встроенным bash и намного быстрее, чем нерест нового процесса (/usr/bin/[) для каждого сравнения. Это будет иметь еще большее значение.

что такое / usr/bin / [

/usr/bin/test и /usr/bin/[ два разных программы, но исходный код для [ (lbracket.c) это то же самое, что и тест.c (снова в coreutils):

#define LBRACKET 1
#include "test.c"

таким образом, они взаимозаменяемы.