Jihad needs scientists
in [Design]
|
From: Ken Smith on 1 Mar 2007 22:08 In article <87y7mhb0fx.fsf(a)nonospaz.fatphil.org>, Phil Carmody <thefatphil_demunged(a)yahoo.co.uk> wrote: [.... swapping ...] >Wrong. If it's not moved onto the swap medium, it's lost. >My kind of computing doesn't like losing data, yours might, >but as we know BAH computing is BAD computing. This is almost exactly right. The write to the swap volume is only needed if the page is dirty (ie: has been written to) This is part of the "complex issues" skipped to keep the list short. -- -- kensmith(a)rahul.net forging knowledge
From: Ken Smith on 1 Mar 2007 22:11 In article <es6hje$8qk_002(a)s985.apx1.sbo.ma.dialup.rcn.com>, <jmfbahciv(a)aol.com> wrote: >In article <87y7mhb0fx.fsf(a)nonospaz.fatphil.org>, > Phil Carmody <thefatphil_demunged(a)yahoo.co.uk> wrote: [........] >>> >- OS looks for the page to swap out >>> >>> Swap out from where? >> >>Main memory, obviously. That's what we're talking about. > >No, Ken is not talking about main memory. He is talking about >"swapping" when the RAM's data is to be written out. Please don't try to tell him what I was saying he fully understood the post I made. The term to "swap out" has a meaning when talking about VM systems. He obviously knew this meaning and was trying to explain it to you. -- -- kensmith(a)rahul.net forging knowledge
From: nonsense on 1 Mar 2007 22:42 Ken Smith wrote: > In article <5685e$45e760f9$4fe7431$8325(a)DIALUPUSA.NET>, > nonsense(a)unsettled.com <nonsense(a)unsettled.com> wrote: > >>Phil Carmody wrote: >> >> >>>kensmith(a)green.rahul.net (Ken Smith) writes: >>> >>> >>>>>ls -lu >>>> >>>>I assume you had a point. >> >>snip blather >> >> >>>So his point wasn't worth getting. >> >>Every time you touch a file it is written to. >> >>Touching a file is sufficient to introduce error. > > > The backup method I have been suggeting has no such problem. Making an > image of a drive does not risk changing its contents. > > BTW: Since the time is not stored within the body of the file, the > sectors that contain the body of the file are not written. It is only the > directory information that is updated. You can have an error in that > sector. So directory all errors are of no concern to you then.
From: MassiveProng on 2 Mar 2007 02:08 On Thu, 01 Mar 07 12:27:08 GMT, jmfbahciv(a)aol.com Gave us: >In article <epccu25dvaomn9ak8i5fmq0lks6prbbtuh(a)4ax.com>, > MassiveProng <MassiveProng(a)thebarattheendoftheuniverse.org> wrote: > >Aren't you out of vital bodily fluids yet? > Sit on it and spin, ditz.
From: MassiveProng on 2 Mar 2007 02:16
On Thu, 01 Mar 07 12:34:42 GMT, jmfbahciv(a)aol.com Gave us: >Each time you copy, the file has been in a writable mode. Wrong. The host file has a snapshot taken of it. If large, it will get read sequentially as the copy takes place. The TARGET file must be "open" to be "created". The original file is NOT EVER in "open" mode, and was not ever in a "writable mode" during a simple copy function. That is why any file which IS "open" and in write mode cannot be accessed by any other user until said write has been performed, and the file released. Database "tables" are the exception, where the database engine "opens" the table file, and allows what could be called a "co-edit" session on the table. At that point, the lockout is at the "record" level, and the same table line cannot be "co-edited", even though the table itself can. That is all managed within the database engine, however, not at the file level. This is why database hard drives can become very fragmented. Tables get updated a couple kB or less at a time. That makes for a very spotty file system (well, it used to) NTFS changed all that, and Linux never suffered the problem. Normal OS file rules prohibit file "co-edit" sessions. |