Why do you say that putting every block in one file is inefficient? It makes a lot of sense to me. Create a directory called bad_blocks or whatever and put the n-th bad block in a file called n-1. Voila, problem solved. Or is that too inefficient?
Posted Mar 18, 2010 2:00 UTC (Thu) by glikely (subscriber, #39601)
[Link]
Not inefficient. A sufficiently large number of bad blocks would cause an overrun of the 4k limit for sysfs attributes.
"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.