[Info-vax] The dangers of extended uptime. Was: Re: swap and page files

[Bill Gunshannon]

In article <nospam-E941F4.18495303012013 at news.chingola.ch>,
	Paul Sture <nospam at sture.ch> writes:
> In article <kc497f$s4p$1 at dont-email.me>,
>  Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote:
> 
>> On 2013-01-03 15:15:24 +0000, Paul Sture said:
>> 
>> > ...it's surprising what can come crawling out of the woodwork...
>> 
>> If you don't test or if you miss a test case, certainly.
> 
> One positive result of the conversation with my friend was that it 
> prompted him to dig out test plans which were created but not executed 
> due to other work taking priority...
>  
>> Apple just got bagged by a corner case in iOS date handling with their 
>> Do Not Disturb function, and the details of that are still just 
>> filtering out.
>> 
>> VMS was getting bagged by date handling for years, and it's still far 
>> too messy for my preferences.  VMS date handling is still arguably 
>> fundamentally broken, too. Unix got this one (more) right with UTC 
>> everywhere, rather than localtime.  But I digress.
> 
> When I first learned that NTFS stores file dates as UTC I could 
> immediately see the disadvantages of VMS clusters across time zones.  
> However NTFS has its own problems:
> 
> <http://en.wikipedia.org/wiki/NTFS#Universal_time>
> 
> "As a result, especially shortly after one of the days on which local 
> zone time changes, users may observe that some files have timestamps 
> that are incorrect by one hour. Due to the differences in implementation 
> of DST in different jurisdictions, this can result in a potential 
> timestamp error of up to 4 hours in any given 12 months."
> 
> This has implications for anything using date based file comparisons 
> such as rsync and the likes of Dropbox.  When I tested a Truecrypt disk 
> image with Dropbox I noticed that Truecrypt leaves the container image 
> date untouched when its contents are changed.  Dropbox noticed this when 
> changes were made on more than one system and saved inconsistencies in 
> separate files, but you need to be aware of this.
> 
>> There's reportedly a very evil PCSI bug floating around in an error 
>> path, too — make sure your PCSI patches are current, or Very Bad Things 
>> can happen.
>> 
>> I've chased critters in NEWUSER over the years.  If you're not current 
>> there, please upgrade.
>> 
>> Bugs happen.
>> 
>> That's why we test, after all.
>> 
>> Long server uptimes are the antithesis of testing.
> 
> Yes, yes and yes.
> 

And yet, 6 months ago, long uptimes were the holy grail and one that
was claimed to be the domain of VMS.  Go figure.

bill
(Who has never had a problem attaining long uptimes on a number of
disparate systems but never really saw the value therein as long as
my users were satisfied with systems availability.  :-)

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999 at cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>