Jihad needs scientists
in [Design]
|
From: jmfbahciv on 4 Mar 2007 07:35 In article <MPG.20536be861bedd6a98a048(a)news.individual.net>, krw <krw(a)att.bizzzz> wrote: >In article <esbpq1$8qk_005(a)s977.apx1.sbo.ma.dialup.rcn.com>, >jmfbahciv(a)aol.com says... >> In article <MPG.2052091685c10ec298a03a(a)news.individual.net>, >> krw <krw(a)att.bizzzz> wrote: >> >In article <es928h$8ss_001(a)s1006.apx1.sbo.ma.dialup.rcn.com>, >> >jmfbahciv(a)aol.com says... >> >> In article <es829g$2hl$2(a)blue.rahul.net>, >> >> kensmith(a)green.rahul.net (Ken Smith) wrote: >> >> >In article <87fy8paqu8.fsf(a)nonospaz.fatphil.org>, >> >> >Phil Carmody <thefatphil_demunged(a)yahoo.co.uk> wrote: >> >> >>kensmith(a)green.rahul.net (Ken Smith) writes: >> >> >>> >ls -lu >> >> >>> >> >> >>> I assume you had a point. >> >> >> >> >> >>I think his point is that access time is part of the metadata >> >> >>that accompanies the file. >> >> > >> >> >It is not stored into the data part of the file. The file's sectors are >> >> >not rewritten so there is no change to that part. I believe that it is >> >> >the time you close the file and not the time you opened it that actually >> >> >ends up stored BTW. None of this matters to the backup method I >> >> >suggested. >> >> > >> >> > >> >> > >> >> >>So we have 3 cases: >> >> >>- If it doesn't change the last-accessed time, then the "last- >> >> >>accessed time" is in fact a falsity; >> >> >>- If it changes the last-accessed time and stores the new access, >> >> >>then the restored file will not be what it was a backup of; >> >> >>- If it changes the last-accessed time but doesn't store the new >> >> >>time, then the file in the backup is not identical to the >> >> >>filesystem that it is a backup of. >> >> >>All three of these are unsatisfactory. Therefore I contend that >> >> >>this field is indeed not a useful field when it comes to considering >> >> >>the behaviour of backups. >> >> > >> >> >No, this is all silly. The backup I have been refering to is not cover in >> >> >the cases in your list. What I suggested was a complete image of the >> >> >drive. >> >> >> >> That has the problem of also preserving the bad spots of the disk. >> > >> >Modern disks don't show their "bad spots" to the system. >> >> I'm assuming that this housekeeping moved into the smart >> controllers. > >The disk drive itself. Has controller functionality moved into all disk drives? That sorta sucks. ....Do these disk drives have multi ports? > >> > They're >> >replaced from a cache of hidden sectors as they fail. This doesn't >> >mean it isn't possible to lose data when one fails though. >> >> So what does a bit-to-bit copy of the physical mean? Bit-to-bit >> implies all bits, including the ones covered by the error handler... >> doesn't it? > >Any bad sectors are mapped out so they don't get copied. They no >longer exist. In fact one should never see a bad sector on a disk. >If you do, throw it away. The spare sectors have been used up and >data sectors (the ones you paid for) are being used for replacements. >This indicates a severely damaged drive. 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? > >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. > When a sector >starts failing (retry threshold exceeded) the drive moves the data on >that sector to a spare/reserved sector (hopefully) close by, then >points to the new sector and marks the old as bad. The replacement >sector is mapped to be in the same logical position as the one it >replaced, even though it is not physically adjacent. When a sector- >for-sector copy is done to another drive (for instance) sectors are >copied from the source in logical (not physical) Logical!!! Then it is NOT a bit-to-bit copy. Goddammit. I goofed and believed them on this one. > 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? Note that I realize different code does different things. Give me the rule of thumb ;-) > >> Oh...were they using the term incorrectly again? > >Words change meaning, levels of indirection are thrown in, confusion >reigns, Dimbulb is wrong (and swears a blue streak to prove it). >Nothing ever changes. [glum emoticon here] Yea, no progres has been observed. /BAH
From: jmfbahciv on 4 Mar 2007 07:48 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. > >> 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. 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. Doing memory to memory copies without using a disk was called shuffling. <snip> /BAH
From: jmfbahciv on 4 Mar 2007 07:56 In article <esc6m4$atc$3(a)blue.rahul.net>, kensmith(a)green.rahul.net (Ken Smith) wrote: >In article <esbpio$8qk_004(a)s977.apx1.sbo.ma.dialup.rcn.com>, > <jmfbahciv(a)aol.com> wrote: >>In article <es9djf$q95$3(a)blue.rahul.net>, >> kensmith(a)green.rahul.net (Ken Smith) wrote: >[....] >>>>You are in error. Last access is an important datum. >>> >>>Please explain exactly how you thing the last access is important. >> >>[This is the piece I inadventently deleted] >> >>> What >>>do you do with this information? >> >>I, the BACKUP programmer, will save all files during an incremental >>that has an access date after the date-time argument of the /SINCE >>switch. > >This makes it no longer an "incremental". You are in fact doing a partial >save on the system. That is what an incremental is. > The mere fact that you do something that is not an >incremental and call that an incremental, doesn't make you right about any >of the things you've posted on the subject. You are telling the developers that they are wrong?!! > A far better way to do a >backup is still to make an image of the drive. No, it is not. It is a faster way, not a better way. You lose information when you do a bit-to-bit. And I've just realized that your reference of "bit-to-bit" isn't really a bit-to-bit. I assumed you were correct in this one but I was wrong. > > >> >>> In this context, the only use of that >>>information will be a mistake. >> >>Are you interested enough to read some code which implements >>this stuff correctly? > >Yes, do you know of any? Yes. I developed and maintained it. I was not the original developer. We called it BACKUP.EXE and the source files are BACKUP.MAC and BACKRS.MAC. The OS was called TOPS-10. There, you have all the magic incantations required to find the code. /BAH
From: jmfbahciv on 4 Mar 2007 08:05 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. >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. I don't know how to reword this again so you can understand that there are different strategies which are defined by the nature of the data and its use. > The >speed of light issue is only a slight delay on the commit process. It is a huge delay. <snip> >>> You can have multiple streams of >>>data going to a file even on a Windows machine. All that is needed is to >>>have one task that does the actual write operations. This is usually >>>combined with "event based" recording where the transactions are recorded >>>with time stamps so that the correct order is insured. >> >>That's not very effiecient if your app is writing a lot. There >>will be a bottleneck at the timekeeper's point in the execution. > >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. > > >>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? /BAH
From: jmfbahciv on 4 Mar 2007 08:09
In article <48cku2dg872ekdnpgtu6u9phbndvhu92oo(a)4ax.com>, MassiveProng <MassiveProng(a)thebarattheendoftheuniverse.org> wrote: >On Sat, 03 Mar 07 13:03:35 GMT, jmfbahciv(a)aol.com Gave us: > >>In article <f3d56$45e8681e$49ecf0e$20166(a)DIALUPUSA.NET>, >> "nonsense(a)unsettled.com" <nonsense(a)unsettled.com> wrote: >>>MassiveProng wrote: >>>> On Fri, 02 Mar 07 12:25:31 GMT, jmfbahciv(a)aol.com Gave us: >>>> >>>> >>>>>In article <9abb5$45e6dbbb$4fe70c3$30531(a)DIALUPUSA.NET>, >>>>> "nonsense(a)unsettled.com" <nonsense(a)unsettled.com> wrote: >>>>> >>>>>>jmfbahciv(a)aol.com wrote: >>>>>> >>>>>>>In article <epccu25dvaomn9ak8i5fmq0lks6prbbtuh(a)4ax.com>, >>>>>>> MassiveProng <MassiveProng(a)thebarattheendoftheuniverse.org> wrote: >>>>>>> >>>>>>>Aren't you out of vital bodily fluids yet? >>>>>> >>>>>>This is what happens when you free the serfs. >>>>> >>>>>Even serfs have been toilet trained and know the best >>>>>use of those other fluids. >>>> >>>> >>>> Your senility is showing again, witch. Don't you have a grave site >>>> or an urn of ashes to talk to? Do you really feel so compelled to try >>>> to talk to us? If you're such a bit god, invent something! >>> >>>Well here's one that was/is incapable of learning toilet >>>skills. >> >>It is clear that he needs adult supervision of the >>maternal kind. > > More immature petty baby bullshit. You have succeeded in letting >the Unlearned Tard drag you down to its level. Congratulations. Your congratualtions are premature. I have yet to achieve his level of thinking ability. It's a fine goal. /BAH |