Зависит ли скорость операций над файлом (копирование, перемещение, удаление )от прав доступа к этому файлу?

Does the speed of operations on a file (copy, move, remove) depend on permissions of that file? If so, then how?

Только в том, что операция будет отклонена (и, следовательно, может считаться занимающей бесконечное время ), если разрешения препятствуют операции.

Помимо этого крайнего случая, разрешения не будут влиять на скорость любой операции копирования/перемещения/удаления.

Меня попросили подтвердить мое утверждение, что вполне приемлемо для любого человека. Вот мое обоснование моего ответа. (И извините, если я плохо процитировал/интерпретировал вызов; это не мое намерение обходить стороной.)

What if you have a ton of ACL's for each of millions of small files? Parsing permissions in this case may take more time than actually reading these files from a disk (i.e. PCI-E gen4 SSD). Do you have access to PCI-E gen 4 NVMe drives which often have read speeds up to 10GB/sec?

Я не могу найти количественное максимальное количество ACL на файл. Тем не менее, некоторые исследования были проведены по этому поводу с загружаемым сценарием. При тестировании исследователя на файл приходилось около 500 списков ACL. В моем тестировании я достиг предела в 252 ACL для файловой системы ext4 на Raspbian. (Мы не учитываем скорости, только ограничения.)

При таком размере они либо будут упакованы в блок индексного дескриптора, либо не более чем в одном блоке от него. Это один дополнительный блок для чтения и разбора. Действительно маленькие файлы могут быть сохранены в inode ext4, поэтому нет необходимости читать дополнительный блок данных. С диском NVMe время чтения дополнительного блока ACL для каждого файла будет минимальным, а анализ 250 или около того записей ACL не будет чрезвычайно трудоемким с вычислительной точки зрения. И это при условии, что файлы действительно маленькие, и им не нужны дополнительные блоки.

Эмпирический? Конечно. Практичный? Я так считаю.

Does the speed of operations on a file (copy, move, remove) depend on permissions of that file? If so, then how?

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

Эта сложность должна быть одинаковой, независимо от разрешений. Но :разрешений больше, чем чтение/запись/выполнение для владельца, группы, других; есть также ACL и xattrs, и в особых случаях это может стать более сложным. Но это, скорее всего, не имеет для вас никакого значения.

Единственным случаем, когда разрешения могут иметь значение, является необходимость координации одновременного доступа к файлу (, например. в сетевой файловой системе, смонтированной по NFS ), но и тогда я такой разницы не увидел.

Итак, теперь, как правило, все "быстро", точка. То, что вы спрашиваете об этом, но даже не упоминаете фактическую файловую систему, которую вы используете, вероятно, означает, что вы беспокоитесь о неправильных вещах. Очень вероятно, что вы сможете найти различия между вашими файловыми системами. Например, если вы часто копируете файлы, то использование файловой системы, которая знает несколько -ссылок на экстенты, значительно ускорит работу. В настоящее время в Linux есть только два варианта :XFS и btrfs. Но даже между этими двумя вы обнаружите измеримую разницу в скорости при выполнении множества операций (, скажем, свыше 10000 в секунду ). Я склоняюсь к XFS, но делаю собственные тесты; с LVM действительно тривиально создавать и уничтожать файловые системы просто так.

Однако тот факт, что вы используете теги rm , cp и mv , может означать, что вы приравниваете время, необходимое инструменты оболочки с теми же именами, чтобы закончить. И это совсем другая проблема. :Вызов /usr/bin/rm¹ занимает намного больше времени, чем фактическое удаление этого файла. Если вы видите это узкое место в сценарии оболочки или в каком-то языке, где вам явно нужно вызывать эти инструменты для изменения файловой системы, вполне возможно, что создание вашего процесса является вашим узким местом -, а не сами операции с файлами.

¹ то есть,forkзапуская процесс, execve("/usr/bin/rm")в разветвлении, Linux загружает программу в ОЗУ, выделяет память для процесса, динамический компоновщик пытается открыть около 20 библиотек, затем загружает одну, выделяет гораздо больше памяти, делает много свойств файла, opening stdout и stderr... затем закрытие всего этого снова, прежде чем фактически unlinking файл... это 100-кратное усилие фактического запроса на удаление (, чтоunlink).