Jihad needs scientists
in [Design]
|
From: MassiveProng on 3 Mar 2007 22:03 On Sat, 3 Mar 2007 13:38:29 -0500, krw <krw(a)att.bizzzz> Gave us: >If you accept that there are disk controllers controlling >controllers. IDE controllers are ALL ON THE DRIVE. The part on the MOBO is called an I/O interface, NOT a drive controller.
From: MassiveProng on 3 Mar 2007 22:08 On Sat, 3 Mar 2007 23:35:21 +0000 (UTC), kensmith(a)green.rahul.net (Ken Smith) Gave us: >Back in the era of the tape drive, there were controllers and formatters. >The term "formatter" seems to no longer be used. Tapes were big and cumbersome. No sense using up a read drive's hubs when a dedicated formatting machine was the right choice. That read drive needed to be reading.
From: MassiveProng on 3 Mar 2007 22:13 On Sat, 3 Mar 2007 19:23:33 -0500, krw <krw(a)att.bizzzz> Gave us: >Sorry, but that's the drive's call. SMART tells you it _was_ time to >buy a new drive. You don't have access to the information, for a >number of reasons. A bit-by-bit copy won't see this information >either. One does NOT need SMART turned on in order to get bad sectors mapped out on a drive.
From: jmfbahciv on 4 Mar 2007 07:24 In article <dgngu2lsqttfl017jk96dqvs8p0irnlcsf(a)4ax.com>, MassiveProng <MassiveProng(a)thebarattheendoftheuniverse.org> wrote: >On Fri, 02 Mar 07 12:33:54 GMT, jmfbahciv(a)aol.com Gave us: > >>>This is only a problem with this copy of the file and not with the one we >>>were backing up. You have also ignored the verify step which is always >>>done. >> >>No, it is not. > > Bullshit. It used to be a flag the user could turn off. Now ALL >files get a checksum verification at ALL times. That is not a bit by bit compare. How large is the checksum field? And where is it stored on the saveset? If you're not saving in a directory mode, (but by a bit-to-bit copy), I don't see how you can even use checksumming. > With large files the >data is kept sequentially, as in a "running checksum" figure is kept >as the file write occurs, and the final value has to match the >checksum for the file. You have to reread that file on the save set before you can match the accumulated checksum with what went on the save set. Again, you appear to be mixing up the two styles of saving. There are directory saves and then there is the bit-to-bit image copy. > > This is even how file download managers work to allow resuming of a >transfer to be properly addenumed <sp> to the file. That way I can >download entire DVD images of Knoppix at 2 MB pre second. Stop, go >get lunch, come back and turn my computer back on and resume the file >WRITE where it left off! HAHAHAHAhahaha. 4.6GB reception success! Comm transfers are a completely different method based on packets described by the several layers of protocols the comm biz has evolved. > >> Verifying requires a second "save" to occur. > > Wrong. You are living in the dark ages. After a block of data is >written, it gets read, and the checksum for that block is kept, and >the next block gets written, then read, then the checksum gets >updated. The checksum is stored in RAM, and at the end of the file >write, the checksum must match the checksum provided in the file >header. No dual save is required. You are decades behind the rest of >the world. You so many holes in this design, it is almost in the category of not even wrong. > >>Even the old days a full system save couldn't be saved and verified >>in one night. > > Nowadays, a power supply for a government computer has a single rail >that is meant fore critical saves... "core dumps" to take place at the >moment power is taken from the system. This "core dump" takes place >within a 150ms window! I suggest you SUAC. > >> Nowadays you have disks that have capacities >>in the giga-thingies. > > Yes, and there was a time that a power outage during a write cycle >not only meant that that particular file was hosed, but the retracting >head arm could "spray" write energy all over your platter as it pulls >back out screwing the whole drive up. This is no longer a problem. You sound confused again. > > So many things you have claimed as problematic are not such any >more. > > That is your main problem. Not really. I'm observing that the biz is reinventing what we did two and three decades ago. /BAH
From: nonsense on 4 Mar 2007 07:39
jmfbahciv(a)aol.com wrote: > In article <dgngu2lsqttfl017jk96dqvs8p0irnlcsf(a)4ax.com>, > MassiveProng <MassiveProng(a)thebarattheendoftheuniverse.org> wrote: snip >> So many things you have claimed as problematic are not such any >>more. >> That is your main problem. > Not really. I'm observing that the biz is reinventing what > we did two and three decades ago. What you're hearing is a peasant rendering of Shakespeare. |