Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.
Sign up to join this community
Does the speed of operations on a file (copy, move, remove) depend on permissions of that file? If so, then how?
Reason: need to constantly perform mentioned operations on many files. Will these operations be completed faster if the files will have a certain permissions? For example, "read only" permission.
Does the speed of operations on a file (copy, move, remove) depend on permissions of that file? If so, then how?
Only in that the operation will be denied (and therefore could be considered to take infinite time) if the permissions prevent the operation.
Aside from that extreme edge case, permissions will have no effect on the speed of any copy/move/remove operation.
I've been asked to validate my statement, which is a perfectly acceptable thing for someone to do. Here's my reasoning for my answer. (And apologies if I've poorly quoted/interpreted the challenge; it's not my intention to sidestep.)
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?
I cannot find a quantitative maximum on the number of ACLs per file. However, there was some research done on this, with a downloadable script. In the researcher's testing there were around 500 ACLs per file. In my testing I hit the limit at 252 ACLs for an ext4 filesystem on Raspbian. (We're not considering speeds, just limits.)
At this size they're either going to be packed in the inode's block or at most one block away. That's one extra block to read and parse. Really small files can be stored in an ext4 inode, so there's no extra data block to read. With an NVMe drive the read time for an extra ACLs block per file is going to be minimal, and parsing 250 or so ACL entries is not going to be stunningly computationally hard. And that's assuming really small files that don't need extra blocks.
Empirical? Sure. Practical? I believe so.
Does the speed of operations on a file (copy, move, remove) depend on permissions of that file? If so, then how?
Speed is something that is wholly defined by the file system: For example, a move within the same file system will only be changing entries in the file system data structures and hence doesn't touch the actual file contents. Therefore, the time this takes will be dominated by the time it takes for your system to switch from your program to the kernel to do that, and the complexity of operations on these data structures.
That complexity should be the same, no matter the permissions. But: there's more to permissions than read/write/execute for owner,group,others; there's ACLs and xattrs, too, and that can get more complex in special cases. But these very likely don't matter to you at all.
The only case where permissions might matter is if concurrent access to the file needs to be coordinated (e.g. on a network file system mounted via NFS), but even then I've yet to see such a difference.
So, now, normally, things are "fast", full stop. The point that you're asking this, but do not even mention the actual file system you're using probably means you're worrying about the wrong things. It's very likely you can find differences between your file systems. For example, if you're often copying files, then using a file system that knows multiply-referenced extents will greatly speed up things. Currently, under Linux, there's only two choices there: XFS and btrfs. But even between these two, you'll find measurable speed differences when doing a lot of operations (say, upwards of 10000 per second). I tend towards XFS, but do your own benchmarking; with LVM it's really trivial to make and destroy file systems just for the heck of it.
The fact that you're using the tags rm, cp, and mv, however, might mean that you're equating the time it takes the shell tools of the same names to finish. And that's a very different problem: Calling /usr/bin/rm¹ takes way, way, way longer than the actual deletion of that file. If you're seeing this bottleneck from a shell script, or from some language where you explicitly have to call these tools to modify the file system, it's quite possible that your process creation is your bottleneck - and not your file operations themselves.
¹ that is, forking the starting process, execve("/usr/bin/rm") in the fork, Linux loading the program into RAM, allocating memory for the process the dynamic linker trying to open about 20 libraries, then actually loading one, allocating way more memory, doing a lot of file properties, opening stdout and stderr... then closing all this again, before actually unlinking the file... that's 100× the effort of the actual deletion request (that unlink).
