This message is from the T13 list server.
> I asked about this originally, Hi, thanks for sharing your personal history of pain. > > The natural implicit result is then a maximally accelerated test til > > failure: read, park, repeat, indefinitely. > > ... that is exactly what these drives do, with "advanced power > management" enabled (which it is by default) ... > > the implications ... are making me (and many other people) blue. I haven't yet heard these devices are operating out of spec. Yes, if operating within spec actually promises short life in a system, then naturally I see first the customers of that system, then the vendor of that system, then the supplier of the devices, will feel pain. Just now I again reviewed the posts of this thread so far, because Google t13 archives just now reconnected me with: http://www.mail-archive.com/forum%40t13.org/ http://www.mail-archive.com/forum%40t13.org/msg01885.html I see we're invited to comment ... but I see no solutions proposed. > > a maximally accelerated test til failure: > > read, park, repeat, indefinitely. I notice now, nastier still is write, park, repeat, indefinitely ..."nastier" I say because delaying a write to avoid parking has more dramatic worst case consequences then does accelerating a read to avoid parking. Apart from injecting such write-behind and read-ahead delays in the host and/or the drive, is there any other solution? Does any standard let the host set a parks per calendar hour limit? Lacking such a standard, then maybe we can guess never more parks than accesses per hour. Ouch, that's easily too many. If then we try dividing the hour of the bus trace into accesses and pauses, then we might not actually see more parks then we see pauses, especially if we count only "long" pauses e.g. more than a revolution. Given the devices as too late to change now, then to get less parks per hour, we have to reprogram the host to give us fewer, longer pauses ... Indeed, changing the devices to actually give us fewer parks despite more pauses wastes power. Ending a pause costs us a spin up. Beginning a pause costs us useless spins and eventually a spin down. All else being equal, we'd probably rather fix this in the host, so that we both limit parks per calendar hour and yet also watts per calendar hour. In short, intermittent use of the drive is maximally rude of the host, yes. Random track access block storage always has worked best in bursts. > > The natural implicit result is then a maximally accelerated test til > > failure: read, park, repeat, indefinitely. > > ... that is ... what the standardized "standby timer" tends to do on > most drives, if you program it with a short interval, but software has > more control over that.) Yes, that's all I meant to say. Myself sometimes I work in IDE but then mostly in ATAPI not in ATA, and lately specifically in MMC ATAPI, which has adopted a standardised standby timer with this, err, widespread, standard, and easily misunderstood design. Pat LaVarre
