On Tue, Jan 19, 2010 at 10:14:09AM -0800, Linus Torvalds wrote:
> The sb-buffer code makes the first 68kB special, and uses the logic that
> even if you want to read just 1kB, we'll read the whole beginning of disk
> up to the point you needed. So no wonder we always end up reading lots of
> data off those disks - the whole logic seems to assume that it's totally
> free to read a single big area.
Yes, I agree with you. I thought about it tomorrow when I tried to
improve the logic for small devices. (As I said to Kay, I hate this
kind of programming where we need exceptions to the basic design of
the code -- then it seems the design is bad...)
The special 68kB buffer is legacy from original Ted's libblkid (and
old udev libvolume_id used almost the same thing). I think the reason
for this buffer is that you have all important data in memory and
the next blkid_probe_get_buffer() call does not overwrite the data.
(Note that the logic is pretty old and blkid has never been used for
floppies or so.)
> (Btw, you could just remove the whole BLKID_SB_BUFSIZ logic in the first
Yes. I'm thinking about it last few days, but I have to check all
probing functions, because at some places we need to work with more
buffers at a time. Maybe we need something like
buf = blkid_probe_get_buffer();
....
blkid_probe_release_buffer(buf);
> place, but I didn't do that. I intentionally went for "smallest possible
> patch" rather than "get rid of the user-level caching entirely").
Yes, I understand. Thanks for your comments.
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
