Jihad needs scientists
in [Design]
|
From: Ken Smith on 2 Mar 2007 21:31 In article <87zm6v8gvb.fsf(a)nonospaz.fatphil.org>, Phil Carmody <thefatphil_demunged(a)yahoo.co.uk> wrote: >kensmith(a)green.rahul.net (Ken Smith) writes: >> In article <es928h$8ss_001(a)s1006.apx1.sbo.ma.dialup.rcn.com>, >> <jmfbahciv(a)aol.com> wrote: >> >In article <es829g$2hl$2(a)blue.rahul.net>, >> > kensmith(a)green.rahul.net (Ken Smith) wrote: >> [...] >> >>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. >> >I'm assuming that you do want an image of the disk and not drive. >> >> Preseving the bad spots is a feature not a problem. It is a record of >> exactly how things were warts and all that you want to keep. >> >> >>This would store the times as they were at the time archive was >> >>made and not change anything about any of them >> >> >> >>The only times that matter for backup are the time of creation and the >> >>last modification. It doesn't matter when the last access happened. >> > >> >You are in error. Last access is an important datum. >> >> Please explain exactly how you thing the last access is important. What >> do you do with this information? In this context, the only use of that >> information will be a mistake. > >The only other time I can can see it being important is if you're >usig some kind of HFS, in which case the concepts of backing up >the filesystem kind of become an irrelevance. The backup, however, shouldn't look at such things. You want it to make an exact copy of how things are. You don't want it to out smart you. BTW: I have seen backups that turned out to be useless because the software tried to be smart. -- -- kensmith(a)rahul.net forging knowledge
From: Ken Smith on 2 Mar 2007 21:33 In article <MPG.2052091685c10ec298a03a(a)news.individual.net>, krw <krw(a)att.bizzzz> wrote: [...] >Modern disks don't show their "bad spots" to the system. 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. That makes the "logical bad spot" and the "physical bad spot" two different things but from the user's point of view it is just a disk that fails less often. -- -- kensmith(a)rahul.net forging knowledge
From: Phil Carmody on 2 Mar 2007 22:05 kensmith(a)green.rahul.net (Ken Smith) writes: > >> >You are in error. Last access is an important datum. .... > The backup, however, shouldn't look at such things. You want it to make > an exact copy of how things are. You don't want it to out smart you. Absolutely agreed. > BTW: I have seen backups that turned out to be useless because the > software tried to be smart. That would be like most software, then. KISS. Phil -- "Home taping is killing big business profits. We left this side blank so you can help." -- Dead Kennedys, written upon the B-side of tapes of /In God We Trust, Inc./.
From: jmfbahciv on 3 Mar 2007 07:13 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. > >[....] >>> Normal OS file rules prohibit file "co-edit" sessions. >> >>Nope. It can be done but you really have to know what you're >>doing. We implemented a system calls that would help different >>programs "share" files. > >Note his word "normal" in the above. I was talking about normal. Windows is not normal. > 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. Contention also needs handling because two events could have the same time stamp. Comm has been dealing with this kind of stuff since I can remember. Error handling is not straight forward in this case. /BAH
From: jmfbahciv on 3 Mar 2007 07:17
In article <87tzx3ahj9.fsf(a)nonospaz.fatphil.org>, Phil Carmody <thefatphil_demunged(a)yahoo.co.uk> wrote: >jmfbahciv(a)aol.com writes: >> You are in error. Last access is an important datum. > >Not universally. I'd be tempted to say very very rarely, It wasn't rare on our installations nor our customers' installations. >except in a few forensic situations. > >Are you familiar with the concept of reading filesystems >read-only? No. It was almost impossible to make a file system read-only with our implementation. The monitor needed to be able to write to BADBLK.SYS whenever hard errors occurred. Now, if you are talking about read-only files; one of the protection fields was dedicated to that kind of protection. We also had execute-only levels of protection, but on a file basis, not a structure basis. >Are you suggesting that it's important that >no-one ever do so, lest they lose that important datum? You might try using your hat rack to think. /BAH |