I'm root, running Centos8 on bare mental and permissions on /proc/sys/kernel/perf_event_max_sample_rate are as follows
-rw-r--r--. 1 root root 0 Oct 3 14:00 perf_event_max_sample_rate
I want to change the sample rate by opening this file with vi, making the change and then writing it with either w or w!. When I do so it comes back with
perf_event_max_sample_rate" E667: Fsync failed
When I try to quit, it tells me
E37: No write since last change (add ! to override)
So I can't change the value with vi. However I can change the value with
echo 4000 > /proc/sys/kernel/perf_event_max_sample_rate
Is this simply because /proc is not a real file system and that all changes to things in /proc would have to be made using echo with a redirect, or maybe sed? Is this behavior documented somewhere?
Answer
This is because of the fsync
option of vi/vim:
fsync
fs
[…]
When on, the library functionfsync()
will be called after writing a file. This will flush a file to disk, ensuring that it is safely written even on filesystems which do metadata-only journaling. […]
(source)
Apparently procfs doesn't support this. It doesn't need to. As it's an interface to internal data structures in the kernel, there is neither cache nor journaling. Permanent config is stored in /etc/sysctl.conf
and few other locations related to sysctl
.
My tests indicate the issue is not as straightforward as "unsupported call after writing a file". The failure prevents the change. Anyway, to make vi
stop trying to fsync()
tell it to set nofsync
, then write with w
. This works for me on Ubuntu 18.04.2 LTS.
No comments:
Post a Comment