Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 8BIT
Subject: RE: Disk write cache (Was: Hyper-Threading Vulnerability)
Date: Thu, 19 May 2005 06:11:59 +0800
Message-ID: <26A66BC731DAB741837AF6B2E29C10171E55EB@xmb-hkg-413.apac.cisco.com>
Thread-Topic: Disk write cache (Was: Hyper-Threading Vulnerability)
Thread-Index: AcVbsFjpLqL9Y5eWS+2Zc9ha7F80dwAQewhA
From: "Lincoln Dale \(ltd\)" <ltd@cisco.com>
To: "John Stoffel" <john@stoffel.org>
Cc: "Eric D. Mudama" <edmudama@gmail.com>, "Robert Hancock" <hancockr@shaw.ca>,
       "linux-kernel" <linux-kernel@vger.kernel.org>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2980
Lines: 89

 
> -----Original Message-----
> From: John Stoffel [mailto:john@stoffel.org] 
> 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/