On Jun 23, 2011, at 23:19 , Michael van Elst wrote:
> s...@cs.columbia.edu (Steven Bellovin) writes:
>
>> The point is that when dealing with raw devices, you take what the hardware
>> gives you. 6th Edition could have detected this and copied the user data
>> into a properly-aligned buffer, with the corresponding performance hit.
>> Instead, it said "this is the way the hardware works; adapt".
>
> I bet at that time block devices were still usuable...
Define "unusable"?
They worked just fine for what they were at the time. There was no mmap(2), so
no unified buffer cache coherency issues, and the big win of the block
interface was the buffer cache. Didn't always have to try and read that data
off those slow SMD (or XSMD if you were lucky enough to have Fujitsu Eagles)
disk drives for every silly read(2) or write(2). And as long as /etc/update was
running (always in multiuser mode), sync(2) got called every 30 seconds, so
your changes (plus inode updates) would get written back out ... reasonably
soon.
Oh, and as noted before, through the block interface, you could do arbitrary
(up to ... was it 64KB?) byte I/O. That sort of thing was a lot more fiddly
than the raw interface.
Of course, if you want to talk about really slow I/O with massive latency,
let's talk about random access to DECtapes ...
Erik <f...@netbsd.org>
