A critical look at sysfs attribute values [LWN.net]

A critical look at sysfs attribute values

Posted Mar 17, 2010 17:26 UTC (Wed) by adamgundy (subscriber, #5418)
Parent article: A critical look at sysfs attribute values

there's another issue with 'one value per file', which is consistency.

if you're trying to read for example the state of a device, having to read multiple files for different attributes is going to spread your 'snapshot' of the information across time - whereas having all the data in a single file allows for a consistent view of the data.

I'd guess that's the reason for the block device 'inflight' file having two numbers for read and write requests in it..

(Log in to post comments)

A critical look at sysfs attribute values

Posted Mar 18, 2010 7:47 UTC (Thu) by ptman (subscriber, #57271) [Link]

POSIX filesystems are not transactional (ACID) like many databases, but it
could probably be done if the user is willing to jump through some hoops.

For example, a sysfs directory might contain the separate files for separate
values and a file called "snapshot" which, when written to, would create a
subdirectory (which probably would need a unique name, and reading the
unique name from the snapshot-file would probably require file locking...)
with the separate files frozen to a specific point in time.

I'm probably missing something here and the idea is too complicated to
actually be used in the real world, I'm just trying to say that it might be
solved, but the solution wouldn't be very nice.

A critical look at sysfs attribute values

Posted Mar 18, 2010 14:47 UTC (Thu) by adamgundy (subscriber, #5418) [Link]

I would think that's an easy denial of service, unless you only allow root to take snapshots (which isn't very helpful). for example, just write a shell script that loops asking for as many snapshots as it can in as many sysfs directories as it can find.. chew up all the kernel memory.

it would probably be better to automatically provide a 'snapshot' file in every directory which can be read to get a consistent view of all files in the directory in some 'well known' format, eg 'key: value' per line like HTTP/SMTP etc.

inter-value consistency

Posted Mar 22, 2010 21:45 UTC (Mon) by neilbrown (subscriber, #359) [Link]

While this is certainly a theoretical limitation of the one-item-per-file approach, I'm not convinced that it is a practical limitation. That is, I'm not aware of any actual situations where the inability to read two attribute files at the same moment causes a real problem.
I don't think the 'inflight' numbers really need to be read concurrently, though I guess the total number in flight might be interesting...

Do you (or anyone) know of a clear example where lack of atomic consistency is a real issue?

inter-value consistency

Posted Mar 22, 2010 22:01 UTC (Mon) by adamgundy (subscriber, #5418) [Link]

I suspect all the cases of 'required consistency' have been shoved elsewhere (ie /proc or /debug) because of the 'one value per file' requirement of sysfs.

for example, /proc/interrupts, /proc/slabinfo etc etc.

without a sensible way of handling consistency, there will always be a demand for putting stuff in /proc or inventing new syscalls/ioctls etc to get the information...

inter-value consistency

Posted Mar 22, 2010 22:39 UTC (Mon) by neilbrown (subscriber, #359) [Link]

You may well be right. That is unfortunate as it is hard to solve problems when they are invisible.

As for your examples, I think both of those files (interrupts and slabinfo) pre-date /sys so they cannot have been put in /proc to avoid /sys rules.
Also I cannot see any atomic-consistency issues that might arise when accessing any of this information. In fact the contents of /proc/slabinfo appear to also exist in /sys/kernel/slab/*/* which does seem to suggest independent access to the values is OK.

If there are genuine cases where consistency is needed it would be really helpful to have them documented so we can work towards making sysfs receptive to such need.