From: Ken Smith on 4 Mar 2007 12:19 In article <eseef4$8qk_001(a)s993.apx1.sbo.ma.dialup.rcn.com>, <jmfbahciv(a)aol.com> wrote: [.....] >Has controller functionality moved into all disk drives? Some fraction of the controller has been on the disk drive for a long time. As we went ST506->EDI->fast ATA->SATA, more and more of the workings moved into the drive. > That >sorta sucks. ....Do these disk drives have multi ports? As I suspect you mean multi-port, they never had and never will. There is only one set of hardware to be controlled. Making it multiported would slow things down and add a bunch of electronics for no gain anywhere. [....] >So if you don't ever "see" bad sectors, how does the human know >that a disk replacement is required? Do we have to wait until >it's a complete mess? What happened to mess prevention? I will just leave that unanswered but here for you to read over. >> >>Drives today use LBA (Logical Block Addressing). > >Yes,yes. Is this hardware or software? Note, for the purposes >of this discussion, firmware is soft. Oh, and exclude optical-- >I don't understand that stuff. It is a mix of the two. There is hardware and firmware. Without the hardware, you couldn't have the firmwhere. >> order to the target >>(where they often end up in physical order). > >When you say physical order, is this a numerical monotonically >increasing order of the sectors? Or is it ordered by the directory tree? The sectors end up in physical order. The drive knows nothing of the logical structure written onto it therefor obviously, that can't be what sets the order. >Note that I realize different code does different things. Give me >the rule of thumb ;-) Nothing can base results on information it doesn't have. -- -- kensmith(a)rahul.net forging knowledge
From: Ken Smith on 4 Mar 2007 12:31 In article <eseg77$8qk_001(a)s993.apx1.sbo.ma.dialup.rcn.com>, <jmfbahciv(a)aol.com> wrote: >In article <esc81s$atc$5(a)blue.rahul.net>, > kensmith(a)green.rahul.net (Ken Smith) wrote: >>In article <esboom$8qk_001(a)s977.apx1.sbo.ma.dialup.rcn.com>, >> <jmfbahciv(a)aol.com> wrote: >>>In article <es9f0f$q95$6(a)blue.rahul.net>, >>> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>>In article <es98ds$8qk_001(a)s1006.apx1.sbo.ma.dialup.rcn.com>, >>>> <jmfbahciv(a)aol.com> wrote: >>>>[....] >>>>The other stuff I've spoken to elsewhere. >>>> >>>>>The case that I brought up was database; with databases, the data >>>>>is always a moving target that can never be snap-shot with accuracy. >>>> >>>>This is not always true. In a multidisk mirroring system, you can do a >>>>commit and unmount one drive. It will be an image of what was there at >>>>the time the commit happened. Disks are fast enough that this option can >>>>be used for most applications. The delay caused by the OS's commit >>>>operation is not very long. >>> >>>I know this is one strategy. One kind of implementation was called >>>striping. For a reservation system, this may not be the best >>>technique because data entry and maintenance is over a wide >>>geographical area; the speed of light is very slow. >> >>You said "never". > >That's right; that kind of data base can never be snapshot with >accuracy; this is because the same field can change often at >the same wall clock time. So now you go back to "never". Which is it? > >>You now admit that the method I stated does exist. > >I never said it didn't exist. I said it couldn't be backed up >with the snapshot stratgey. You were wrong when you said this. The method of doing a commit, and then an image makes a backup of the files as they existed at an exact instant in time. There is no way around it, you were wrong. [....] >> The >>speed of light issue is only a slight delay on the commit process. > >It is a huge delay. On your plannet, the speed of light must be very low. The disk is a mechanical thing. Light can go a very long way in 100uS. The head on a disk doesn't get very far in that much time. [....] >>What do you mean by "timekeeper". I have to ask because there is no such >>problem in any part I can think of as the "timekeeper". > >In any computer system, there has to be a timekeeper which will >dictate the time so all things can be synchronized. When this >syncrosity is spread geographically, some flavor of timekeeper >has to be the boss so that coincidental events don't overwrite >each other. There is not bottle neck in that if you don't do something completely daft. BTW: coincidental events won't overwrite each other unless you do something also daft. Today, time stamping can be done with very high accuracy for very little cost. The GPS system sends a very accurate clock around the world for you. You don't have to use time packets and figure travel times any more. [....] >>>Contention also needs handling because two events could have >>>the same time stamp. >> >>Contention is only an issue if you have multiprocessing and events that >>can't be commuted. > >I have been talking about a reservation system. You and somebody >half-way around the world can make a reservation for the same flight. >How do you think such a system prevents you from sitting in that >other person's lap?...or, for that matter, out on the wing? That is pretty obvious. Based on what you have said, I doubt you actually wrote the code that dealt with this. You have made too many mistakes on the issue to be the one who actually wrote it. Just being in the same room where it was written doesn't count. -- -- kensmith(a)rahul.net forging knowledge
From: Ken Smith on 4 Mar 2007 12:37 In article <esef6o$8qk_001(a)s993.apx1.sbo.ma.dialup.rcn.com>, <jmfbahciv(a)aol.com> wrote: >In article <esc9ar$atc$7(a)blue.rahul.net>, > kensmith(a)green.rahul.net (Ken Smith) wrote: >>In article <esbqel$8qk_010(a)s977.apx1.sbo.ma.dialup.rcn.com>, >> <jmfbahciv(a)aol.com> wrote: >>>In article <es9g7v$q95$8(a)blue.rahul.net>, >>> kensmith(a)green.rahul.net (Ken Smith) wrote: >>[.....] >>>>>>This is part of the "complex issues" skipped to keep the list short. >>>>> >>>>>Do you think that a swapper moves pages from the RAM to the >>>>>swap file? >>>> >>>>If you think otherwise, you don't know what you are talking about. This >>>>is what "swapping" in a VM system implies. >>> >>>It didn't in any VM system JMF implemented. >> >>Then JMF was not implementing VM as the term is commonly used in the >>industry. He obvious implemented something that he called VM. > >People who do the first implementations in the industry get to do the >naming. We got to do that a lot. I know IBM did an implementation. >I don't remember if the other six sisters did. The generally accepted meaning in the industry is the one that matters. VM has a generally accepted meaning. You seem to have your own private meaning. Welll good for you but it doesn't help you to communicate when you you vuncanize a gorm for a pogo. >>> I'm unaware of >>>any other OS that used the term in that wasy. >> >>In which way? > >The way you've been using it. From your descriptions you >think the RAM is a replacement of our core memory. RAM is the currently used term. > I can >see where some implmentations would do this because RAM >capacities grew so large so fast. Swapping transfers >a context to the disk, not memory. This is not what you said early. I see you have learned something new. This is good. > Doing memory to memory >copies without using a disk was called shuffling. Perhaps it was called that by you and a few others. The process of "compacting" was crushing the gaps out of the memory map. Since the moves involved don't look anything like shuffling, I don't see why anyone would use such a misleading term, for the operations involved. -- -- kensmith(a)rahul.net forging knowledge
From: MassiveProng on 4 Mar 2007 13:59 On Sun, 04 Mar 07 12:12:25 GMT, jmfbahciv(a)aol.com Gave us: >I don't call webbing modern computing. No, but it IS the absolute best resource for a dope like you to learn about it. You are the main reason why I feel that anyone taking computer sciences as a major should have to take electronics first. You are clueless as to how things actually work at the hardware level. That is why they call this the "information age". For you to live your pathetic life, cutting yourself out of an entire segment of the worldwide information base is yet another proof that you do not have a single clue. Start with NEETS http://tpub.com/neets/ After you learn a little about electronics, take a new, modern course in computer sciences. Short of that, I give you zero credence as you are stuck several decades in the past.
From: MassiveProng on 4 Mar 2007 14:03
On Sun, 04 Mar 07 12:24:46 GMT, jmfbahciv(a)aol.com Gave us: >That is not a bit by bit compare. For the most part, yes it is as there cannot be one bit out of place and yield the same checksum, AND the exact bits that would have to be off in order to yield the same checksum put the likelihood at about 10 to the 17th power to one odds against. So, you were also unaware that checksums are the de facto standard in the industry? How telling. Entire CD and DVD and soon HD DVD images are verified in this manner. Has been done for decades without a miss. What happened to you? Why have you "missed" the rest of the world? |