chmod рекурсивное разрешение на тысячах файлов

найдите / chmod оптимизация

Оба find и chmod должны читать

1. все записи каталога
2. inodes для всех этих записей

Вы, вероятно, получаете повышение производительности первым чтением все записи и затем весь inodes (на вращающемся диске), потому что затем головка диска не перемещается между каталогом и inodes). Как chmod глупо (как один из других ответов объясняет), это нужно назвать через find только. Но даже затем это может помочь считать весь inodes, прежде чем первое будет записано (предположение, что у Вас есть достаточно свободной RAM для дискового кэша). Я предлагаю это:

find . -printf "" # reading the file names only
find . ! -perm 775 -printf "" # reading all the inodes (file names are cached)
find . ! -perm 775 -exec chmod 775 + # writing to the cache without reading from disk

Хорошее решение: ACLs

Хорошее решение может полностью отличаться: Если файлы созданы в этом каталоге (и не перемещены от где-то в другом месте), затем, ACLs может сделать задание на лету. Просто необходимо установить ACLs по умолчанию на родительском каталоге.

Дальнейшее совершенствование может быть достигнуто оптимизацией файловой системы. Если это - ext3/ext4 затем, можно работать e2fsck -D время от времени. Возможно, это помогает поместить этот каталог на отдельный объем. Можно попробовать различные файловые системы или настройки файловой системы (например, различные inode размеры).

Принятие использования chmod от GNU coreutils пакет на Ubuntu 12.10.

chmod 775 . -R выполняется fchmodat системный вызов каждого файла, который это находит независимо от того, нужно ли для полномочий изменение или нет. Я подтвердил это и осмотром кода и использованием strace chmod 775 . -R (отрывок ниже) для списка фактического поведения.

newfstatat(4, "d", {st_mode=S_IFREG|0666, st_size=0, ...}, AT_SYMLINK_NOFOLLOW) = 0
fchmodat(4, "d", 0775)                  = 0
newfstatat(4, "c", {st_mode=S_IFREG|0666, st_size=0, ...}, AT_SYMLINK_NOFOLLOW) = 0
fchmodat(4, "c", 0775)                  = 0
newfstatat(4, "a", {st_mode=S_IFREG|0666, st_size=0, ...}, AT_SYMLINK_NOFOLLOW) = 0
fchmodat(4, "a", 0775)                  = 0
newfstatat(4, "b", {st_mode=S_IFREG|0666, st_size=0, ...}, AT_SYMLINK_NOFOLLOW) = 0
fchmodat(4, "b", 0775)                  = 0

Существует несколько недостатков выполнения fchmodat на каждом файле

• Дополнительный системный вызов, вероятно, станет значительным, если большое количество файлов будет изменено. find/xargs/chmod метод, упомянутый другими, вероятно, будет более быстрым, только изменяя файлы то изменение потребности.
• Вызов к fchmodat изменяет модификацию состояния файла (ctime) каждого файла. Это заставит каждый file/inode изменяться каждый раз и вероятно вызовет избыточные записи на диск. Могло бы быть возможно использовать, монтируют опции остановить эти избыточные записи.

Простой эксперимент показывает изменения ctime, происходящие для прямо chmod

auser@duncow:/tmp/blah.test$ ls -lc
total 0
-rwxrwxr-x 1 laptop laptop 0 Jun 18 18:17 a
-rwxrwxr-x 1 laptop laptop 0 Jun 18 18:17 b
-rwxrwxr-x 1 laptop laptop 0 Jun 18 18:17 c
-rwxrwxr-x 1 laptop laptop 0 Jun 18 18:17 d
auser@duncow:/tmp/blah.test$ chmod 775 . -R
auser@duncow:/tmp/blah.test$ ls -lc
total 0
-rwxrwxr-x 1 laptop laptop 0 Jun 18 18:25 a
-rwxrwxr-x 1 laptop laptop 0 Jun 18 18:25 b
-rwxrwxr-x 1 laptop laptop 0 Jun 18 18:25 c
-rwxrwxr-x 1 laptop laptop 0 Jun 18 18:25 d

Но это не изменяется для find/xargs/chmod несколько минут спустя

auser@duncow:/tmp/blah.test$ date
Tue Jun 18 18:27:27 BST 2013
auser@duncow:/tmp/blah.test$ find . ! -perm 775 -print0 | xargs -0 -I {} chmod 775 {}
auser@duncow:/tmp/blah.test$ ls -lc
total 0
-rwxrwxr-x 1 laptop laptop 0 Jun 18 18:25 a
-rwxrwxr-x 1 laptop laptop 0 Jun 18 18:25 b
-rwxrwxr-x 1 laptop laptop 0 Jun 18 18:25 c
-rwxrwxr-x 1 laptop laptop 0 Jun 18 18:25 d

Я был бы всегда склонен использовать find/xargs/chmod версия, потому что находят, дает больше контроля выбором вещей.

Вы рассмотрели изменение процесса (процессов), которые создают файл, чтобы создать их с 0775 режимами? Посмотрите на значение umask в среде - 0002, может помочь.

[Источник] (1) показывает, что chmod(1) всегда пытается установить режим а затем снова проверяет с помощью [fstatat(2)] (2).

Файлы обрабатываются через [fts(3)] (3), который должен "статистизировать" все пройденные объекты файловой системы заранее, чтобы построить свое дерево данных.

В Unixlore есть [хорошая статья] (4), где chmod(1) указано время против подхода find / xargs: последний выигрывает по величине.

Здесь командная строка адаптирована к первоначальному вопросу:

find . -print0 | xargs -0 chmod 775

Две причины:

1. Обход файловой системы отделен от операций с файлами через канал между двумя процессами, который может даже работать на разные ядра.

   2. fts(3) операция сведена к минимуму, потому что xargs(1) "сглаживает" дерево каталогов.

Итак, да: вам определенно следует использовать find / xargs. для простого решение.

Другие варианты:

• Играть с [umask] (5) и исходным кодом процесса(ов) записи новые файлы.

• Если вы используете Linux, скорее всего, в вашей системе inotify подсистема ядра. В этом случае вы можете написать сценарий эффективное решение через [inotifywait(1)] (6).

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

find . -type f -print0 | xargs -0 chmod 664
find . -type d -print0 | xargs -0 chmod 775

Примечание для редакторов: мне не разрешено добавлять более двух ссылок в пост, а также комментировать другие посты. Я оставляю URL-адреса здесь и надеюсь, что какой-нибудь добросердечный пользователь с достаточной репутацией вернет их в текст и удалит этот абзац.

Прокомментируйте заполнение кэша диска с помощью find . -printf "":

Это может ускорить выполнение следующих операций chmod, однако зависит от доступной памяти и загрузки ввода-вывода. Так что может получится, а может и нет. Операция обхода развязки (find) и chmod уже обеспечивает кэширование, поэтому заполнение кэша может быть излишним.

1. https+lingrok.org/xref/coreutils/src/chmod.c#process_file
2. https+linux.die.net/man/2/fstatat
3. https+linux.die.net/man/3 /fts
4. http+www.unixlore.net/articles/speeding-up-bulk-file-operations.html
5. https+en.wikipedia.org/wiki/Umask
6. https+linux.die.net /man/1/inotifywait