Jihad needs scientists
in [Design]
|
From: jmfbahciv on 9 Mar 2007 06:28 In article <esp7m9$hni$1(a)blue.rahul.net>, kensmith(a)green.rahul.net (Ken Smith) wrote: >In article <esothi$8ss_002(a)s1016.apx1.sbo.ma.dialup.rcn.com>, > <jmfbahciv(a)aol.com> wrote: >>In article <esmj7c$bj2$1(a)blue.rahul.net>, >> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>In article <esm9f6$8ss_002(a)s1012.apx1.sbo.ma.dialup.rcn.com>, >>> <jmfbahciv(a)aol.com> wrote: >>>>In article <esju3h$1a4$2(a)blue.rahul.net>, >>>> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>[.....] >>>>>Having multiple disks connected to a single disk drive controller >>>>>electronics gives absolutely no advantage and a few disadvantages. >>>> >>>>I know that one can have multiple structures on one drive. Has >>>>the need of having one structure on multiple drives gone away? >>> >>>No, it hasn't gone away completely. There is a lot less need for logical >>>volumes to span multiple disks today. >> >>Is this because disk capacities are larger than most needs? With >>the habits of downloading music and videos, etc. won't there be >>another capacity problem fairly soon? > >This may happen some time in the slightly distant future. Modern OSes >allow what the user sees as a directory to be a different disk drive. > >MS-DOS did this with the "join" command. When Windows 95 was brought out, >the "join" command went away. On Linux and OS-X, the command is "mount". > >It isn't much of a stretch of the imagination to see some OS automatically >assigning an entier drive to things like videos. These used to be called private packs. The concept has existed since the 60s. > >> >>> It is still done in cases where >>>something will be truly huge. It is also done in the name of speed where >>>the data must be moved on and off the disk at speeds that are impractical >>>for hardware. >> >>The last reason was valid in the olden days. JMF visited an insurance >>company site and saw a disk farm of [can't remember the number] >>hundreds, I think. He was awed because it was all one file. >>There was no way our products could deal with >>that kind of a data base. IBM knew how to handle those. > >IBM's design of the logical structure was very good from this point of >view. The Volume Table Of Contents told you where the Data Extent Blocks >were. The DEBs formed a chain. Extending this chain to include which >physical drive the next things were on wouldn't be hard to do. IBM evolved based on data base usage. We didn't. Our trade offs were guided by delivering computing to people who did science and engineering. /BAH
From: jmfbahciv on 9 Mar 2007 06:29 In article <n7a1v29gv894uc76qtgn35j56hl2fflu5e(a)4ax.com>, MassiveProng <MassiveProng(a)thebarattheendoftheuniverse.org> wrote: >On Thu, 08 Mar 07 11:54:26 GMT, jmfbahciv(a)aol.com Gave us: > >>Is this because disk capacities are larger than most needs? With >>the habits of downloading music and videos, etc. won't there be >>another capacity problem fairly soon? > > > TeraByte drives are looming on the horizon as we speak. > > And those are in 2.5" form factor. > > Keep up much? And will they survive being set next to TV or a vacuum cleaner? /BAH
From: jmfbahciv on 9 Mar 2007 06:32 In article <esp8c8$hni$3(a)blue.rahul.net>, kensmith(a)green.rahul.net (Ken Smith) wrote: >In article <esp193$8qk_002(a)s1016.apx1.sbo.ma.dialup.rcn.com>, > <jmfbahciv(a)aol.com> wrote: >>In article <esou80$8qk_001(a)s1016.apx1.sbo.ma.dialup.rcn.com>, >> jmfbahciv(a)aol.com wrote: >>>In article <esml4r$bj2$3(a)blue.rahul.net>, >>> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>>In article <esmalk$8qk_001(a)s1012.apx1.sbo.ma.dialup.rcn.com>, >>>> <jmfbahciv(a)aol.com> wrote: >>>>>In article <esjvn9$1a4$4(a)blue.rahul.net>, >>>>> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>>[....] >>>>>>If you know what you intend to write onto the tape, figure out what the >>>>>>checksum will be and then write the tape as you intend there is no extra >>>>>>effort needed. >>>>> >>>>>That does not give you a checksummed directory of the physical >>>>>tape you just made. All the handwaving and blustering you >>>>>are doing still does not satisfy the requirement. >>>> >>>>Yes it does. Imagine it step by step. >>>> >>>>(1) >>>>You calculate the checksum of what you intend to put on the tape. >>>> >>>>(2) >>>>You put exactly what you intend onto the tape >>>> >>>>(3) >>>>You calculate the checksum of what you have put on the tape. >>> >>>The checksum of the contents of the tape is not interesting. >>>That is a summary and doesn't help. A bit by bit verify >>>is done instead of your checksum summary. >>> >>>The record of the checksums of each file on the tape is >>>the needed information. That itemized record is put into >>>a file which is the first file on the tape. >> >>Let me try to explain using different lingo. >> >>The first file on the tape, TAPE.DIR, is the invoice of the >>distribution and contains a list of each item on the tape, >>including that item's checksum. > >..... and it includes its own checksum. This checksum can be made to be >correct by the method I suggested. Only by fakery. To fake it would open up many opportunities for Murphy's Law to strike. It was more important to have a physical list of what we put on the tape than to have the checksum of TAPE.DIR be correct and as the first file on the tape. Your approach would open the TAPE.DIR for writing. This was an unacceptable risk. /BAH
From: jmfbahciv on 9 Mar 2007 06:48 In article <esp89d$hni$2(a)blue.rahul.net>, kensmith(a)green.rahul.net (Ken Smith) wrote: >In article <esou80$8qk_001(a)s1016.apx1.sbo.ma.dialup.rcn.com>, > <jmfbahciv(a)aol.com> wrote: >>In article <esml4r$bj2$3(a)blue.rahul.net>, >> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>In article <esmalk$8qk_001(a)s1012.apx1.sbo.ma.dialup.rcn.com>, >>> <jmfbahciv(a)aol.com> wrote: >>>>In article <esjvn9$1a4$4(a)blue.rahul.net>, >>>> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>[....] >>>>>If you know what you intend to write onto the tape, figure out what the >>>>>checksum will be and then write the tape as you intend there is no extra >>>>>effort needed. >>>> >>>>That does not give you a checksummed directory of the physical >>>>tape you just made. All the handwaving and blustering you >>>>are doing still does not satisfy the requirement. >>> >>>Yes it does. Imagine it step by step. >>> >>>(1) >>>You calculate the checksum of what you intend to put on the tape. >>> >>>(2) >>>You put exactly what you intend onto the tape >>> >>>(3) >>>You calculate the checksum of what you have put on the tape. >> >>The checksum of the contents of the tape is not interesting. >>That is a summary and doesn't help. A bit by bit verify >>is done instead of your checksum summary. > >Suddenly you are changing the subject. I am still talking about the same procedure and constraints that I had to solve. > The question is: would the >checksum before and after match? The answer is yes, so the method works. No. It cannot match. Your method provides a list of we intended to put on the tape. My method describes what was really put on the tape because the TAPE.DIR file was generated by examining the tape. Anybody who has done any grocery shopping would know the difference between the two. Just because dog food is on your shopping list never guarantees that dog food will be in your car when you get home. The only listing that shows you were successful in putting dog food in the shopping cart is the cash register receipt. > >>>If the checksum at step (3) doesn't match the checksum at step (1), you >>>haven't written what you intended onto the tape. I am really surprised >>>that you can't see this. >> >>I'm at a loss to try to explain what we were doing. YOu seem >>to be determined not to understand. > >You were making a mistake, is what you were doing. You just gotta love this illogic. Your method is not a solution and creates havoc. It can also be extremely expensive if it results in customers sending in problem reports when they could have done preliminary checking at the time they first examine the tape. > >>>>You still are not getting the fact that the directory of the tape >>>>had to be on the tape--not a directory of the files on disk >>>>soon to be copied to the tape. >>> >>>Why the devil can't you understand this!!!!!! Go back and look at what I >>>wrote above. >> >>Your solution does not provide a list of all files on the tape. > >Yes it does. I have shown how you can make the checksum on this file >correct. This file that contains the list is the very file we have been >talking about. It is a faked listing. It was not generated by looking at the files that were really put on the tape. Not only did my method provide an invoice of what got packed, my method kept us from making blank or incomplete masters. > > > >>> I have told you how to do it when you know what will end up >>>on the tape. You were talking about tapes that will contain code to be >>>sent to others. If you don't know what that tape will contain, you are >>>not ready to make it. >>> >>>I also pointed out but did not cover that there is a method for tapes >>>where the contents are not known before hand. The fact that you haven't >>>been able to understand the simple case makes it nonuseful to get into >>>that subject right now. >>> >>> >>>>>The issue of what to do if you can't be sure about how much will really >>>>>fit onto the tape is worthy of further discussion if you want to know how >>>>>to solve that one. >>>> >>>>I know more about how to fit stuff on small tapes than you will ever >>>>encounter. Tape fitting still has nothing to do with the requirement >>>>of a directory of the tape prepended to the files we distributed >>>>on that tape. >>> >>>The tail end of this is wrong in a way that I won't try to explain to you >>>until you understand the simpler case. The start of it is evidence that >>>haven't yet understood the simple case. >> >>Your simple case doesn't address any of the issues. All it does >>is create extra work in the procedure with no usefulness. > >My simple case solves a problem that you said can't be solved. You said >it was imposible. It is not. It is impossible. Everytime you take a new directory of the tape, the checksum of TAPE.DIR changes. If you do another save with the new TAPE.DIR, another directory of the physical tape will produce a different checksum of TAPE.DIR. > >>>>> The problem >>>>>is that you couldn't see how to make the checksum correct when the file >>>>>that contained the checksum had to be included in the checksum. >>>> >>>>Since the contents of the directory file will always change (checksummed >>>>file's checksum is the thing that will never be a constant), >>>>there will never be an accurate directory of the tape. However, >>>>no customer's system needed to use the directory-of-the-tape file's >>>>checksum to verify their restores. >>> >>>This is wrong in two way. The checksum can in fact be put in place after >>>all the data has been saved. >> >>You can't edit a tape. That would open such a can of Murphy's >>worms, even if it were possible. > >This would be a very strange drive if you really couldn't. You have never been able to edit magtape. You need two drives to do an edit. > But if you >know the names of the files to be put onto the tape, it is obvious that >you don't need to do it. If you don't know the names before hand, you >can't write a file containing those names so your suggested problem is >meaningless if the editing can't be done. > >The reason tapes have an IRG (Inter Record Gap) is to allow the data on >the tape to be edited. You may decide not to do this but the drives knew >how. Now that's a new one. > > >> >>> The contents of the directory on the tape >>>doesn't change once the tape is created and is ready to ship. >> >>A tape is not a directory medium. The file I am talking about >>is part of the save set. > >This file lists the names of the files on the tape. You method does not list the files on the tape. Your method lists the files you intend to put on the tape. These are two very different lists. > This is a >"directory". It is also sometimes called a manifest. >>>>That is not how we used checksums when packaging our materials. >>>>The program our customers used to get a checksum had to match >>>>the program we used to get the checksum we reported. >>> >>>There is absolutely nothing in what I suggested that changes this. I will >>>suggest you go back over the subject again. >> >>I don't have to; my methods worked and provided enough data >>for sanity checks on both ends of the distribution system. > >You said the checksum was published as wrong Only the checksum of the file TAPE.DIR was incorrect. The first save of the tape had the checksum as 0. >and that doing it right was >not posible. I worry about your customers. You don't have to worry. My methods solved a couple problems with two swell foops and prevented waste of time and money of both us and our customers. /BAH
From: Ken Smith on 9 Mar 2007 09:29
In article <esrg7f$8ss_001(a)s842.apx1.sbo.ma.dialup.rcn.com>, <jmfbahciv(a)aol.com> wrote: >In article <2v91v2pjpp3qdcn8mv70t5rk21t7g1oeem(a)4ax.com>, > MassiveProng <MassiveProng(a)thebarattheendoftheuniverse.org> wrote: >>On Thu, 08 Mar 07 11:48:40 GMT, jmfbahciv(a)aol.com Gave us: >> >>>As I said above, our OS philosophy was to provide multiple pathways. >>>Multiple pathways...do you understand what that means? So why >>>are you demeaning the OS philosophy with an argument about networks? >> >> >> Networking is a MAJOR part of a modern OS, dingledorf. > >It shouldn't be. Routing should be kept off user machines. If more effective ways of breaking up the routing problem were found, routing could be spread across the user machines. With the current situation, I agree with you that it needs to be kept on a special box just for that purpose. -- -- kensmith(a)rahul.net forging knowledge |