| |||||||||||||
"one file per block would be silly""one file per block would be silly"Posted Mar 18, 2010 2:00 UTC (Thu) by glikely (subscriber, #39601)In reply to: "one file per block would be silly" by HelloWorld Parent article: A critical look at sysfs attribute values
Not inefficient. A sufficiently large number of bad blocks would cause an overrun of the 4k limit for sysfs attributes.
(Log in to post comments)
"one file per block would be silly" Posted Mar 18, 2010 7:49 UTC (Thu) by ptman (subscriber, #57271) [Link]
I think he actually meant separate files, otherwise, why the directory?
"one file per block would be silly" Posted Mar 18, 2010 9:49 UTC (Thu) by HelloWorld (guest, #56129) [Link]
Yes indeed. The first bad block goes in a file named 0, the second goes in a file called 1, ... the n-th bad block goes in a file called n-1.
"one file per block would be silly" Posted Mar 18, 2010 13:10 UTC (Thu) by nix (subscriber, #2304) [Link]
... or have a bunch of empty files whose names are block numbers.
Still, this would definitely have to be dynamically-generated at lookup time: one kobject/dentry for every bad block throughout the lifetime of the /sys mountpoint would be madness.
"one file per block would be silly" Posted Mar 18, 2010 20:10 UTC (Thu) by smurf (subscriber, #17840) [Link]
So if you have 1000 bad blocks, you need 3000+ system calls to read the list.
Sorry, but I don't think that this makes much sense.
Where does that silly 4k limit come from, anyway? debugfs does much better. So provide a symlink to the "real" list which lives somewhere else?
"one file per block would be silly" Posted Mar 19, 2010 14:00 UTC (Fri) by nix (subscriber, #2304) [Link]
Uh, the syscall underlying readdir() (getdents()) reads a whole bunch of entries at once, so you don't need 3000 syscalls to readdir() through 3000 names. If you want to stat() them, then you're right: but all you need to do in this case is get their names, which is much faster.
|
|||||||||||||