| |||||||||||||
"one file per block would be silly""one file per block would be silly"Posted Mar 18, 2010 9:49 UTC (Thu) by HelloWorld (guest, #56129)In reply to: "one file per block would be silly" by ptman Parent article: A critical look at sysfs attribute values
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.
(Log in to post comments)
"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.
|
|||||||||||||