From: Ken Smith on
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
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
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
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
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?