1

I am writing a startup script for a daemon that runs inside an embedded Linux installation. That means that chmod is from BusyBox v1.24.2.

I don't want to cause any unnecessary write cycles on flash media.

That is why I am wondering whether issuing a chmod 03755 (with umask 022) on a directory will result in any disk write I/O.

In other words is it necessary to insert a check whether the directory permissions are already setup correct and only execute the chmod when the permissions are incorrect?

Or is a directory permissions check wasted effort because busybox chmod will not result in any disk write I/O when permissions don't need any change?

3 Answers 3

3

chmod 03755 is meant to do a chmod("file", 03755) on the file which in turn will check that you have the right to do so and perform it if possible (and return an error if not) which in turn will at least update the ctime of the file, may cause an audit record to be generated, etc.

If busybox went out of its way to check whether it's necessary or not, the ctime would not be updated and that would be a bug. It would also take away the atomic nature of the operation which would also be a bug.

So there will be some related writing to the storage device even if not done instantly.

So you'll have to do the check yourself.

If the stat applet was enabled in your build of busybox:

[ "$(stat -Lc%a file)" = 3755 ] || chmod 3755 file
0

My less optimal solution for now is to print the number of writes before and after the command.

First I disable disk write cache:

# hdparm -W 0 /dev/sda

Then I try to exclude disk writes of other processes by repeating the kernel disk stat command a few times:

# cat /sys/block/sda/stat | awk '{ print $5 }';chmod 03755 /opt/etc/tinydns;cat /sys/block/sda/stat | awk '{ print $5 }'
1725
1725
# cat /sys/block/sda/stat | awk '{ print $5 }';chmod 03755 /opt/etc/tinydns;cat /sys/block/sda/stat | awk '{ print $5 }'
1725
1725
# cat /sys/block/sda/stat | awk '{ print $5 }';chmod 03755 /opt/etc/tinydns;cat /sys/block/sda/stat | awk '{ print $5 }'
1725
1725

I would guess that in this case the chmod doesn't issue any disk output/write activity.

2
  • To truly verify it, you'd need a sync for all pending I/Os to be flushed to disk. Commented Dec 22, 2022 at 16:04
  • While this stops low level disk-caching, I don't think it prevents inodes themselves being cached. Mentioned here: unix.stackexchange.com/a/334263/20140 Commented Dec 22, 2022 at 16:10
-1

You can find out by using "strace chmod 03755" on the respective file". You might have add strace to your busybox image.

4
  • When alternating chmod 03755 with 03750 I don' see any differences except from the memory addresses and the 03755/03750. strace command doesn't seem to signal disk I/O. Commented Dec 7, 2016 at 17:51
  • You are already observing the disk io. A file permission is changed via the chmod syscall. The kernel will execute the syscall, changing the permissions in the respective inode of the file system. In the end it will be written out to the disk. Commented Dec 7, 2016 at 18:10
  • Sorry that I don't understand the output. Where in the strace results can I recognize that I/**O** output is written to disk? (One of my goals is to differentiate the reads (I) from the writes (O)) Commented Dec 7, 2016 at 18:28
  • 2
    Ah, I had to re-read your original question. I am sorry, but strace won't help you here. Commented Dec 7, 2016 at 18:40

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.