> -----Original Message-----
> From: John Stoffel [mailto:[email protected]]
> Sent: Wednesday, 18 May 2005 11:49 PM
> To: Lincoln Dale (ltd)
> Cc: Eric D. Mudama; Robert Hancock; linux-kernel
> Subject: RE: Disk write cache (Was: Hyper-Threading Vulnerability)
>
> >>>>> "Lincoln" == Lincoln Dale \(ltd\) <Lincoln> writes:
>
> Lincoln> why don't drive vendors create firmware which reserved a
> Lincoln> cache-sized (e.g. 2MB) hole of internal drive space
> somewhere
> Lincoln> for such an event, and a "cache flush caused by hard-reset"
> Lincoln> simply caused it to write the cache to a fixed (contiguous)
> Lincoln> area of disk.
>
> Well, if you're losing power in the next Xmilliseconds, do
> you have the time to seek to the cache holding area and
> settle down the head (since you could have done a seek from
> the edge of the disk to the middle), start writing, etc?
I believe its possible.
rationale:
[1] ATX power specification, (google finds this for me at
http://www.formfactors.org/developer%5Cspecs%5CATX12V_1_3dg.pdf)
section 3.2.11 (Voltage Hold-up time) states:
The power supply should maintain output regulation per Section
3.2.1 despite a loss of input
power at the low-end nominal range-115 VAC / 57 Hz or 230 VAC /
47 Hz-at maximum
continuous output load as applicable for a minimum of 17 ms.
the assumption here is that T6 in figure 5 does de-assert the
POWER_OK signal early in that "minimum of 17ms".
the spec (unfortunately) only calls for >=1msec.
once again, i see that there could be a market for a combination of
p/s & peripherals that could make use of it.
lets say that we DO have 17msec.
[2] Hard drive response times
picking a 'standard' high-end hard drive (Maxtor Atlas 10K V scsi
disk):
average seek + rotional latency is measured at 7.6msec.
transfer rates at beginning of disk are 89.5MB/s at end of disk
are 53.9MB/s.
(source
http://www.storagereview.com/articles/200411/200411028D300L0_2.html)
allowing 8msec for seek time, and writing at the 'slow' side of the
disk, writing 2MB
could take ~37msec (2 / 53.9). allow 50% overhead here - and we
have 55msec.
55 + 8 = 63 msec.
ok - 63msec doesn't fit into 17msec -
but as i say, a combination of p/s and/or larger caps (and/or more
innovative design by a case or p/s manufactuer which creates a dedicated
peripheral power bus)
> Seems better to have a cache sized flash ram instead where
> you could just keep the data there in case of power loss.
>
> But that's expensive, and not something most people need...
indeed, and that is what MS have been targeting. (flash isn't that
expensive, but flash write times are..).
cheers,
lincoln.
>
> John
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]