Uptime for OpenVMS
abrsvc
we not moved datacenters...
OpenVMS V7.1-2 on node xxx 10-MAY-2011 13:52:46.60 Uptime 842
20:38:06
Can anyone beat this?
Marc Schlensog
abrsvc
> On Tue, 10 May 2011 11:54:38 -0700 (PDT)
>
> > This is the best so far at my current site. This would be longer had
> > we not moved datacenters...
>
> > OpenVMS V7.1-2 on node xxx 10-MAY-2011 13:52:46.60 Uptime 842
> > 20:38:06
>
> > Can anyone beat this?
>
> Here's a story from 2006:http://www.openvms.org/stories.php?story=06/01/08/4531954
Close, but I would argue that the "cluster" itself could remain up for
10 years with individual nodes being up for far less. The posting I
did was for a single machine. I seem to recall a record for a VAX in
the 5 year range, but can't find the reference. The machine I posted
will need to be upgraded to V7.3-2 soon, so the record for us here
will soon stop...
Dan
Bob Koehler
>
> Close, but I would argue that the "cluster" itself could remain up for
> 10 years with individual nodes being up for far less. The posting I
> did was for a single machine. I seem to recall a record for a VAX in
> the 5 year range, but can't find the reference. The machine I posted
> will need to be upgraded to V7.3-2 soon, so the record for us here
> will soon stop...
There's a well known story about an Irish Railway cluster that stayed
up for 17 years and kept the application available 24 x 365.23 x 17.
There's a less known story about a MicroVAX in an establishment
that had other requirements leading to a really good UPS, and 14 year
uptime all on it's own. It came down the day they moved the office
to a different building.
Rich Jordan
VAX/VMS V6.1 on node ZZZZ 10-May-2011 18:09:43.10 Uptime 991
09:42:37
Boottime = 22-AUG-2008 08:07:46.08
We're cheering for 1000 though that would not be a record for this box
(close to 1500 days). They always lose it to a powerfail that
outlasts the backup power, or once to replace an internal drive.
Neil Rieck
Yesterday afternoon I received an email from a surveillance group in
India (nothing to do with HP) telling me that there is something wrong
with one of our computer systems. It was an emulated VAX running
VMS-5.5-2 and was now up for 400 days which "just can't be correct"
Neil Rieck
Kitchener / Waterloo / Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/OpenVMS.html
BillPedersen
It has always been great to have these long and productive uptimes on
OpenVMS.
While there has not been the determination of the exact criteria for
evaluation everyone should know that there will be an "Availability
Award" presented at this year's Connect OpenVMS Boot Camp at the
Sheraton Needham in September. Sue Skonetski is working with the HP
OpenVMS organization to define the criteria. Once it is defined we
will make sure to publish so people can submit their sites for
consideration.
Bill.
Paul Sture
<2ed009ed-5982-41b8...@z37g2000vbl.googlegroups.com>,
abrsvc <dansabr...@yahoo.com> wrote:
I'm afraid I've forgotten the details, but approximately a decade ago we
had an Alpha/VMS patch which required a full cluster reboot, since one
of the messaging protocols changed. It might have been hardware
specific (e.g. Memory Channel) There were no Vaxes in that particular
cluster.
--
Paul Sture
Bob Koehler
>
> Yesterday afternoon I received an email from a surveillance group in
> India (nothing to do with HP) telling me that there is something wrong
> with one of our computer systems. It was an emulated VAX running
> VMS-5.5-2 and was now up for 400 days which "just can't be correct"
That's an old story from the UNIX vs. VMS wars. Of course, it
predates emulated VAXen.
Do you actually have a copy you can share? For posterity.
R.A.Omond
> This is the best so far at my current site. This would be longer had
> we not moved datacenters...
>
> OpenVMS V7.1-2 on node xxx 10-MAY-2011 13:52:46.60 Uptime 842
> 20:38:06
At one of my customer sites in London, we had a "compute farm" of
15 DS15's (non-clustered).
They were unfortunately switched off in October last year.
14 of them had an uptime of 963 days, and one with 600 days
(it had its system disk swapped).
Bill Gunshannon
Mine's bigger than yours!!!
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Bill Gunshannon
server1# uname -a
FreeBSD server1.cs.uofs.edu 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Sun May 7 04:42:56 UTC 2006 ro...@opus.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP i386
server1# uptime
9:05AM up 4914 days, 19:54, 1 user, load averages: 0.00, 0.00, 0.00
server1#
What do I win?
JF Mezei
> server1# uname -a
> FreeBSD server1.cs.uofs.edu 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Sun May 7 04:42:56 UTC 2006 ro...@opus.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP i386
> server1# uptime
> 9:05AM up 4914 days, 19:54, 1 user, load averages: 0.00, 0.00, 0.00
> server1#
I am pale in comparison:
9:13 up 101 days, 10:08, 8 users, load averages: 0.07 0.07 0.08
And actually, this should be much less, because Apple provides many
upgrades to the OS and applications which (stupidly) require a reboot.
There are a whole bunch queued right now on my server, but I don't want
to lose all the X terminal windows popped from the server to my
workstation so I keep postponing those upgrades :-)
MG
On 11-5-2011 14:58, R.A.Omond wrote:
> At one of my customer sites in London, we had a "compute farm" of
> 15 DS15's (non-clustered).
>
> They were unfortunately switched off in October last year.
>
> 14 of them had an uptime of 963 days, and one with 600 days
> (it had its system disk swapped).
Impressive and DS15s are great systems in my opinion! I still don't
see them all too often on auction sites, so my guess is that they're
still seeing action.
- MG
abrsvc
For the record, the time I posted intially was on an Alpha DS10
system. I have another here with almost the same service time of:
OpenVMS V7.1-2 on node xxx 11-MAY-2011 06:32:40.69 Uptime 719
22:00:05
Dan
Rich Jordan
Agreed on DS15s. I keep hoping to run across a cheap one for home
use, but it doesn't happen; they still have too much value to the
resellers and aftermarket. I hope that London site didn't just trash
theirs. We've got one customer with one that I'm keeping an eye on
since its no longer in production (just used for acccess to historical
data); if they surplus it I'm going to try and pounce on it.
I'd never manage long uptimes at home though; even now that I can't
get ECO kits anymore (so no patch reboots) we get at least one
powerfail every year or so that outlasts the UPS. Longest recent
uptime on the server DS10L (which was not getting ECOs applied during
that period) was around 380 days. Its at 124 days now after a winter
power outage, and will be going down in June so I can replace the
external drives with larger capacity but more power efficient and
quieter ones (those 2.5" Savvio's mentioned here a while ago).
Come on, someone here has to have an uptime to beat the customer VAX,
now at 992 days (besides Bill's antique BSD box that probably has
_real_ power backup available).
Bill Gunshannon
Before someone complains, JF, it was a joke; meant to show that anyone
can make any claim of uptime they want. FreeBSD 6.1 was released in
2003. 4914 days of uptime is 13 years. While no one here is likely
to believe it anyway, I have had servers that would have run for years
except I don't control the power and for a long time we had an annual
power shutdown here at the University limiting uptime to no more than
364 days. I do not remember the last time I had an OS related failure.
Not on Unix, not on Windows and, of course, not on VMS. I have had a
feew hardware related failures, which would kill a VMS system equally
well. But the majority of my failures have been due to loss of comm-
ercial power that lasted longer than I have UPSes to support.
Single Stage to Orbit
> FreeBSD server1.cs.uofs.edu 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Sun
> May 7 04:42:56 UTC 2006
> ro...@opus.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP i386
> server1# uptime
> 9:05AM up 4914 days, 19:54, 1 user, load averages: 0.00, 0.00, 0.00
Your box is dated 2006, but your uptime is equal to 13 years' worth.
--
Tactical Nuclear Kittens
Johnny Billquist
> In article<d768c138-27f6-40fb...@y31g2000vbp.googlegroups.com>,
> BillPedersen<pede...@ccsscorp.com> writes:
>> On May 10, 2:54 pm, abrsvc<dansabrservi...@yahoo.com> wrote:
>>> This is the best so far at my current site. This would be longer had
>>> we not moved datacenters...
>>>
>>> OpenVMS V7.1-2 on node xxx 10-MAY-2011 13:52:46.60 Uptime 842
>>> 20:38:06
>>>
>>> Can anyone beat this?
>> It has always been great to have these long and productive uptimes on
>> OpenVMS.
>> While there has not been the determination of the exact criteria for
>> evaluation everyone should know that there will be an "Availability
>> Award" presented at this year's Connect OpenVMS Boot Camp at the
>> Sheraton Needham in September. Sue Skonetski is working with the HP
>> OpenVMS organization to define the criteria. Once it is defined we
>> will make sure to publish so people can submit their sites for
>> consideration.
>
> server1# uname -a
> FreeBSD server1.cs.uofs.edu 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Sun May 7 04:42:56 UTC 2006 ro...@opus.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP i386
> server1# uptime
> 9:05AM up 4914 days, 19:54, 1 user, load averages: 0.00, 0.00, 0.00
> server1#
>
>
> What do I win?
How did you get near 5000 days from a system built 5 years ago? There is
only about 1800 days in 5 years...
Johnny
JF Mezei
>> 9:05AM up 4914 days, 19:54, 1 user, load averages: 0.00, 0.00, 0.00
>
> Your box is dated 2006, but your uptime is equal to 13 years' worth.
You have 2 dimensional thinking...
You are forgetting time travel. Machine booted in 2006, just before time
travel 8 years back, (so it relived 2006 again 8 years later) and this
explains it has been up for 13 years.
Or, the machine was booted in 2006, lived normally until 2019 and just
recently time traveled back to 2011. In both instances, the systen clock
would still indicate it has been up for 13 years.
John Wallace
> On 2011-05-11 07.09, Bill Gunshannon wrote:
>
>
>
> > BillPedersen<peder...@ccsscorp.com> writes:
> >> On May 10, 2:54 pm, abrsvc<dansabrservi...@yahoo.com> wrote:
> >>> This is the best so far at my current site. This would be longer had
> >>> we not moved datacenters...
>
> >>> OpenVMS V7.1-2 on node xxx 10-MAY-2011 13:52:46.60 Uptime 842
> >>> 20:38:06
>
> >>> Can anyone beat this?
> >> It has always been great to have these long and productive uptimes on
> >> OpenVMS.
> >> While there has not been the determination of the exact criteria for
> >> evaluation everyone should know that there will be an "Availability
> >> Award" presented at this year's Connect OpenVMS Boot Camp at the
> >> Sheraton Needham in September. Sue Skonetski is working with the HP
> >> OpenVMS organization to define the criteria. Once it is defined we
> >> will make sure to publish so people can submit their sites for
> >> consideration.
>
> > server1# uname -a
> > server1# uptime
> > 9:05AM up 4914 days, 19:54, 1 user, load averages: 0.00, 0.00, 0.00
> > server1#
>
> > What do I win?
>
> How did you get near 5000 days from a system built 5 years ago? There is
> only about 1800 days in 5 years...
>
> Johnny
I noticed that too, then later I read he said it was meant to be a
joke? Any real system with load averages of 0.0 (as this one appeared
to have) over an extended period would be a joke too.
JF Mezei
OK, in light of Bill Gunshannon's 4000 day uptime, I wanted to "edit"
the output of SHOW SYSTEM....
VMS Alpha 8.3:
$START = "17=NOV-1858 01:00:00"
$END = F$TIME()
$write sys$output f$delta_time(start,end)
%SYSTEM-F-IVTIME, invalid time
If I change "start" to have a date last year, it works.
Note that by having it at 01:00:00, it means that "start" isn't set to
"0" and should not be considered a deltatime.
Is this due to a 32 bit limitation in DCL that would not allow a
delta-time greater than 32 bits ?
Bill Gunshannon
Actually, the load averages are quite real. Slow time for the students
and we have multiple general purpose servers avaialable. Not the "1 user".
that was me getting the uptime.
But, all of this is, as usual, just plain silly. The only thing needed
to get a long uptime is "time". I could easily build a system that did
nothing and was backed up with emough power sources to guarantee it never
went down. Eventually, it would have some ridiculous uptime and it would
have accomplished... wait for it...... NOTHING.
On another note, with all the VMing of systems today I wonder what would
happen if I built a system started it running, took a snapshot, shut it
down and then restarted it from the snapshot (note, not reboot, restart)
10 years later? Would it report an uptime of 10 years?
Johnny Billquist
> In article<c5dead8c-9266-486a...@q12g2000prb.googlegroups.com>,
I think just editing the output is much easier... :-)
Johnny
Johnny Billquist
If the above is literally what you wrote, then it could also be the
inability to parse "17=NOV-1858" as a valid date. :-D
Johnny
Michael Moroney
Ignoring/fixing the typo, DCL has always had a delta time limition of
9999 days max. I don't know why that is.
$ $START = "25-DEC-1983 01:00:00"
$ $write sys$output f$delta_time(start,end)
9999 12:10:35.21
$ $START = "24-DEC-1983 01:00:00"
$ $write sys$output f$delta_time(start,end)
%SYSTEM-F-IVTIME, invalid time
JF Mezei
>
> If the above is literally what you wrote, then it could also be the
> inability to parse "17=NOV-1858" as a valid date. :-D
OK, here is the litteral cut/paste:
$ start = "17-NOV-1858 01:00:01"
$ end = f$time()
$ write sys$output f$delta_time(start,end)
%SYSTEM-F-IVTIME, invalid time
$
And just to be sure:
$ start = "17-NOV-1859 01:00:01"
$ write sys$output f$delta_time(start,end)
%SYSTEM-F-IVTIME, invalid time
So even a year after the start of VMS time, it still says it is invalid.
A bit more investigating:
$ start = "17-NOV-1984 01:00:01"
$ write sys$output f$delta_time(start,end)
9671 11:51:14.66
$ start = "17-NOV-1983 01:00:01"
$ write sys$output f$delta_time(start,end)
%SYSTEM-F-IVTIME, invalid time
So I suspect that when it goes beyond 9999 days, it fails. So probably
more a $FAO issue than a 32 bit issue.
Johnny Billquist
I know that the 9999 day limit for delta times are documented somewhere,
and it is not DCL specific. Not sure if that is just when formatting
though, or if the limit somehow also applies in general.
Thanks for reminding me. :-)
Johnny
glen herrmannsfeldt
(snip)
> I noticed that too, then later I read he said it was meant to be a
> joke? Any real system with load averages of 0.0 (as this one appeared
> to have) over an extended period would be a joke too.
FreeBSD strange 3.3-RELEASE FreeBSD 3.3-RELEASE #0: Fri Apr 21 23:40:33 PDT 2000
root@strange:/usr/home/src/sys/compile/gah i386
2:46PM up 311 days, 12:04, 2 users, load averages: 0.00, 0.00, 0.00
It has been up more than 311 days, though I don't remember what
happened 311 days ago. This is my NAT router, home nameserver, and
otherwise useful home host. I sysgenned the kernel myself, as the
generic one didn't include NAT at the time. Other than power outages,
it could have been running 11 years.
The load is normally pretty low, even when NAT is keeping it busy.
-- glen
glen herrmannsfeldt
(snip)
> But, all of this is, as usual, just plain silly. The only thing needed
> to get a long uptime is "time". I could easily build a system that did
> nothing and was backed up with emough power sources to guarantee it never
> went down. Eventually, it would have some ridiculous uptime and it would
> have accomplished... wait for it...... NOTHING.
For most, the disk has to keep running throughout. For a diskless
client off an NFS server, even that isn't needed. (Diskless NFS
clients survive a server reboot.)
> On another note, with all the VMing of systems today I wonder what would
> happen if I built a system started it running, took a snapshot, shut it
> down and then restarted it from the snapshot (note, not reboot, restart)
> 10 years later? Would it report an uptime of 10 years?
I have seen ones where the TOD clock stopped while it was suspended.
Then again, running BACKUP on a Win2K dual processor box reports
the time as twice the actual clock time. (Presumably once for
each processor.)
-- glen
Bill Gunshannon
glen herrmannsfeldt <g...@ugcs.caltech.edu> writes:
> Bill Gunshannon <bill...@cs.uofs.edu> wrote:
>
> (snip)
>
>> But, all of this is, as usual, just plain silly. The only thing needed
>> to get a long uptime is "time". I could easily build a system that did
>> nothing and was backed up with emough power sources to guarantee it never
>> went down. Eventually, it would have some ridiculous uptime and it would
>> have accomplished... wait for it...... NOTHING.
>
> For most, the disk has to keep running throughout. For a diskless
> client off an NFS server, even that isn't needed. (Diskless NFS
> clients survive a server reboot.)
Well, if you were considering possible disk failure, how about I build
a system with just a ramdisk? :-) No moving parts beyond electrons.
And talk about being old. Unless they have fixed it (which I
doubt as I never saw anyone in the linux crowd admit it was done
wrong) Linux versions of NFS are, in some way, stateful and a reboot
of the server requires a reboot of all the clients. One of the
reasons I have resisted moving anything here to Linux as we rely
very heavily on NFS and I can't be rebooting all our clients if I
have to take the fileserver down for any reason.
>
>> On another note, with all the VMing of systems today I wonder what would
>> happen if I built a system started it running, took a snapshot, shut it
>> down and then restarted it from the snapshot (note, not reboot, restart)
>> 10 years later? Would it report an uptime of 10 years?
>
> I have seen ones where the TOD clock stopped while it was suspended.
>
> Then again, running BACKUP on a Win2K dual processor box reports
> the time as twice the actual clock time. (Presumably once for
> each processor.)
No practical reason, but it might be interesting to see what Hyper-V
does.
glen herrmannsfeldt
(snip, I wrote)
>> For most, the disk has to keep running throughout. For a diskless
>> client off an NFS server, even that isn't needed. (Diskless NFS
>> clients survive a server reboot.)
> Well, if you were considering possible disk failure, how about I build
> a system with just a ramdisk? :-) No moving parts beyond electrons.
> And talk about being old. Unless they have fixed it (which I
> doubt as I never saw anyone in the linux crowd admit it was done
> wrong) Linux versions of NFS are, in some way, stateful and a reboot
> of the server requires a reboot of all the clients. One of the
> reasons I have resisted moving anything here to Linux as we rely
> very heavily on NFS and I can't be rebooting all our clients if I
> have to take the fileserver down for any reason.
Yes, all my diskless NFS work was with Sun hosts. I had many
survive a server reboot. Then once we sold a server, while the
clients sat there waiting for it to come back...
Stateless (except for file lock) is supposed to be part of NFS.
-- glen
Bill Gunshannon
True. And yet, people still wonder why I think Linux is pure crap.
Ken Fairfield
I think the problem is that a "proper" delta-time must
be less than or equal 9999-23:59:59.99 . This is a general
statement. See Help Date_Time Delta .
A delta time of 9999 days takes us back to about 27 years
to 24-DEC-1983, a far cry from 17-NOV-1858.
I used to have some understanding of the internal quadword
format of time (something simple like the number of centi-
seconds since 17-NOV-1858), and that a delta time is
identified as being a negative value.
I suspect that the limitation is not on the internal representation
of delta times, but that the output routines, e.g., $ASCTIM,
simply limit the value to fit in a 4-digit day field.
-Ken
Bob Eager
Yup, I have one like that. It only ever gets rebooted for extended power
outages or system upgrades. I've done well over a year on occasion.
Doesn't even have a proper disk - just a CF card. Custom (small) kernel
etc., uses RAMdisk as a web cache.
--
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
*lightning protection* - a w_tom conductor
Bob Eager
>> For most, the disk has to keep running throughout. For a diskless
>> client off an NFS server, even that isn't needed. (Diskless NFS
>> clients survive a server reboot.)
> Well, if you were considering possible disk failure, how about I build a
> system with just a ramdisk? :-) No moving parts beyond electrons.
Use a CF card...!
> And talk about being old. Unless they have fixed it (which I doubt as I
> never saw anyone in the linux crowd admit it was done wrong) Linux
> versions of NFS are, in some way, stateful and a reboot of the server
> requires a reboot of all the clients. One of the reasons I have
> resisted moving anything here to Linux as we rely very heavily on NFS
> and I can't be rebooting all our clients if I have to take the
> fileserver down for any reason.
Don't seem to see that on FreeBSD...clients occasionally need a nudge,
that's all.
>> I have seen ones where the TOD clock stopped while it was suspended.
NTP ought to fix that...!
Bill Gunshannon
Bob Eager <rd...@spamcop.net> writes:
> On Wed, 11 May 2011 18:46:35 +0000, Bill Gunshannon wrote:
>
>>> For most, the disk has to keep running throughout. For a diskless
>>> client off an NFS server, even that isn't needed. (Diskless NFS
>>> clients survive a server reboot.)
>> Well, if you were considering possible disk failure, how about I build a
>> system with just a ramdisk? :-) No moving parts beyond electrons.
>
> Use a CF card...!
Showing my age here. We used to use ramdisks, but that isn't really
necessary any more. :-)
>
>> And talk about being old. Unless they have fixed it (which I doubt as I
>> never saw anyone in the linux crowd admit it was done wrong) Linux
>> versions of NFS are, in some way, stateful and a reboot of the server
>> requires a reboot of all the clients. One of the reasons I have
>> resisted moving anything here to Linux as we rely very heavily on NFS
>> and I can't be rebooting all our clients if I have to take the
>> fileserver down for any reason.
>
> Don't seem to see that on FreeBSD...clients occasionally need a nudge,
> that's all.
Strictly a Liux problem. It's what you get from NIH Syndrome carried
out by idiots.
Bob Eager
> In article <93066a...@mid.individual.net>,
> Bob Eager <rd...@spamcop.net> writes:
>> On Wed, 11 May 2011 18:46:35 +0000, Bill Gunshannon wrote:
>>
>>>> For most, the disk has to keep running throughout. For a diskless
>>>> client off an NFS server, even that isn't needed. (Diskless NFS
>>>> clients survive a server reboot.)
>>> Well, if you were considering possible disk failure, how about I build
>>> a system with just a ramdisk? :-) No moving parts beyond electrons.
>>
>> Use a CF card...!
>
> Showing my age here. We used to use ramdisks, but that isn't really
> necessary any more. :-)
>
>
>>> And talk about being old. Unless they have fixed it (which I doubt as
>>> I never saw anyone in the linux crowd admit it was done wrong) Linux
>>> versions of NFS are, in some way, stateful and a reboot of the server
>>> requires a reboot of all the clients. One of the reasons I have
>>> resisted moving anything here to Linux as we rely very heavily on NFS
>>> and I can't be rebooting all our clients if I have to take the
>>> fileserver down for any reason.
>>
>> Don't seem to see that on FreeBSD...clients occasionally need a nudge,
>> that's all.
>
> Strictly a Liux problem. It's what you get from NIH Syndrome carried
> out by idiots.
Yup. I get arrogant students going on about how wonderful Linux is, and I
say it's just a jumped up UNIX wannabe!
Richard B. Gilbert
> On May 10, 2:54 pm, abrsvc<dansabrservi...@yahoo.com> wrote:
>> This is the best so far at my current site. This would be longer had
>> we not moved datacenters...
>>
>> OpenVMS V7.1-2 on node xxx 10-MAY-2011 13:52:46.60 Uptime 842
>> 20:38:06
>>
>> Can anyone beat this?
>
> India (nothing to do with HP) telling me that there is something wrong
> with one of our computer systems. It was an emulated VAX running
> VMS-5.5-2 and was now up for 400 days which "just can't be correct"
>
> Neil Rieck
> Kitchener / Waterloo / Cambridge,
> Ontario, Canada.
> http://www3.sympatico.ca/n.rieck/OpenVMS.html
<snicker> <choke> <gasp>
Single Stage to Orbit
> > Strictly a Liux problem. It's what you get from NIH Syndrome
> carried
> > out by idiots.
>
> Yup. I get arrogant students going on about how wonderful Linux is,
> and I say it's just a jumped up UNIX wannabe!
And Linux still isn't a microkernel!
--
Tactical Nuclear Kittens
Johnny Billquist
> In article<iqema8$ltc$1...@dont-email.me>,
> glen herrmannsfeldt<g...@ugcs.caltech.edu> writes:
>> Bill Gunshannon<bill...@cs.uofs.edu> wrote:
>>
>> (snip, I wrote)
>>>> For most, the disk has to keep running throughout. For a diskless
>>>> client off an NFS server, even that isn't needed. (Diskless NFS
>>>> clients survive a server reboot.)
>>
>>> Well, if you were considering possible disk failure, how about I build
>>> a system with just a ramdisk? :-) No moving parts beyond electrons.
>>
>>> And talk about being old. Unless they have fixed it (which I
>>> doubt as I never saw anyone in the linux crowd admit it was done
>>> wrong) Linux versions of NFS are, in some way, stateful and a reboot
>>> of the server requires a reboot of all the clients. One of the
>>> reasons I have resisted moving anything here to Linux as we rely
>>> very heavily on NFS and I can't be rebooting all our clients if I
>>> have to take the fileserver down for any reason.
>>
>> Yes, all my diskless NFS work was with Sun hosts. I had many
>> survive a server reboot. Then once we sold a server, while the
>> clients sat there waiting for it to come back...
>>
>> Stateless (except for file lock) is supposed to be part of NFS.
>
> True. And yet, people still wonder why I think Linux is pure crap.
Linux is crap. That's old news. :-)
But it's moving crap, which in some ways is better than things sitting
still sometimes.
However, as for NFS statelessness, it's not totally true.
For an NFS client to be able to continue operating after the server have
rebooted, the server must not have changed its hardware configuration,
or else the device handles that the NFS client holds becomes invalid.
Johnny
onedbguru
DS10L>$ sh sym start
START = "24-DEC-1983 18:32:16.42"
DS10L>$ sh sym end
END = "11-MAY-2011 18:32:16.41"
DS10L>$ write sys$output f$delta_time(start,end)
9999 23:59:59.99
DS10L>$ START = "24-DEC-1983 18:16:41"
DS10L>$ write sys$output f$delta_time(start,end)
%SYSTEM-F-IVTIME, invalid time
Trips the wire at 10000 days..
Bill Gunshannon
That can't be exactly true. With systems other than Linux I have
taken down one piece of hardware and brought up another totally
different piece of hardware and as long as the new system presented
the same exported file systems as the previous one the clients would
pick it up and march on. With Linux, iunless I actually umount
everything NFS beforehand. all I have to do is reboot the server and
all is lost. The clients can not umount the partitions because the
server knows they are no longer mounted and istead of just saying
"OK" to the umount command it will NAK all the reuests leaving the
client still holding a mountpoint it can not clear. Thus, a reboot
of the client is necessary.
Nothing other than Linux has ever exhipited this behavior.
Johnny Billquist
> In article<iqf63n$57t$1...@iltempo.update.uu.se>,
I have had SUN machines (in the old days of SunOS 4.1) fail to access
NFS on the server after a server reboot. But it only happens if you had
added or removed a disk. Even if it isn't the one you were accessing,
and the disk could be accessed just fine locally after reboot.
So there is some kind of device identifier held by the client, which can
be changed after a reboot, if the hardware changes, that will cause NFS
to fail. I have not looked at the NFS protocol in detail to tell exactly
how it works, but I have seen server reboots that clients survive just
fine, and I have seen ones where the clients didn't. But since server
changes aren't that often, I'd say that around 99 times out of 100, the
client survives a server reboot just fine.
From the sound of it, it would appear that for Linux, things are much
worse.
Johnny
Bob Eager
As if that were necessarily an issue.
glen herrmannsfeldt
(snip)
> However, as for NFS statelessness, it's not totally true.
> For an NFS client to be able to continue operating after the server have
> rebooted, the server must not have changed its hardware configuration,
> or else the device handles that the NFS client holds becomes invalid.
Yes, there is that. I never figured out exactly how it works,
but I do remember that even a different OS version would do it.
One of my first NFS server configurations included booting between
two different versions of HP-UX. The hardware configuration was
the same, other than the root partition. It knew the difference.
Still, I will guess that if you really need to build a server
such that the disk can be replaced and continue, that it is
possible to do it. There is a reason they make hot-swap disks.
-- glen
Paul Sture
<b7f4bb8a-549c-4feb...@dn9g2000vbb.googlegroups.com>,
onedbguru <oned...@yahoo.com> wrote:
Woosh. That's reminiscent of the 10,000 day overflow problem we had in
1997 with Unix dates. There was a VMS patch then, IIRC for X11 / Motif.
--
Paul Sture
jbriggs444
> OK, in light of Bill Gunshannon's 4000 day uptime, I wanted to "edit"
> the output of SHOW SYSTEM....
>
> VMS Alpha 8.3:
>
> $START = "17=NOV-1858 01:00:00"
> $END = F$TIME()
> $write sys$output f$delta_time(start,end)
>
> %SYSTEM-F-IVTIME, invalid time
>
> If I change "start" to have a date last year, it works.
>
> Note that by having it at 01:00:00, it means that "start" isn't set to
> "0" and should not be considered a deltatime.
>
> Is this due to a 32 bit limitation in DCL that would not allow a
> delta-time greater than 32 bits ?
It's a limitation is built into the VMS operating system routines,
SYS$BINTIM and SYS$ASCTIM. This limitation was carried
over and documented for certain run time library routines such
as LIB$ADD_TIMES and LIB$SUB_TIMES.
The limitation is that delta times may not represent intervals
greater than 9999 days. This was known at one time as the
D10K problem.
I have strong opinions on the level of intelligence implied by
the D10K behavior in the relevant vintage of the VMS RTL.
The RTL enforced the 9999 day limit on delta times not
just for input/output, but also for internal arithmetic in
routines such as LIB$ADD_TIMES and LIB$SUB_TIMES.
http://www.b2systems.com/support/delta.html
But I digress.
The output format for a VMS delta time has four digits for
day number and no provision for overflow. If you try to print
out a delta time for an interval of some 50,000+ days, it
won't fit. That is, I believe, the problem you report above.
However, there is another issue with your calculation. VMS
uptime is not properly computed by subtracting the boot time
from the current time. It is properly computed by looking
at EXE$GL_ABSTIME (in seconds).
Assuming unsigned arithmetic, the former puts a limit of
49,710 days (136 years) of uptime on any VMS system
in which ABSTIME is maintained in an unsigned 32 bit cell.
The question of signed versus unsigned arithmetic is
largely academic since we haven't had any systems up
for 68 years yet and because...
My recollection is that "SHOW SYSTEM" uses the incorrect
computation for uptime and does, in fact, subtract boot time
from time now. This can give rise to absolute times showing
up in the "SHOW SYSTEM" uptime display if you change
the system clock backward far enough.
jbriggs444
> I used to have some understanding of the internal quadword
> format of time (something simple like the number of centi-
> seconds since 17-NOV-1858), and that a delta time is
> identified as being a negative value.
The unit is 100 nanoseconds, aka the "clunk".
Hoff seems to share your confusion about the centisecond,
but otherwise does a fine job describing the VMS epoch.
Note that the 0.5 offset is becauase astronomers work at
night and put the zero hour at noon. The rest of us customarily
work during the day and put the zero hour at midnight.
http://labs.hoffmanlabs.com/node/282
http://h71000.www7.hp.com/wizard/wiz_5744.html
Bob Koehler
>
> I suspect that the limitation is not on the internal representation
> of delta times, but that the output routines, e.g., $ASCTIM,
> simply limit the value to fit in a 4-digit day field.
The limitation is well known not to be in the internal
representation, as those of us who applied the 10K day patch can
recall.
Prior to the patch, LIB$ routines would return an error if asked to
manipulate larger delta times. Related to this, the C RTL was going
to have a problem at 10K days since the C/UNIX epoch of 1-Jan-1970.
DEC released a patch so that the LIB$ routines would not return an
error, even though they were returning a delta time that the LIB$
and system routines could not format.
Bob Koehler
>
> Linux is crap. That's old news. :-)
> But it's moving crap, which in some ways is better than things sitting
> still sometimes.
Yes, but it's easy to get the latest source. Which makes it easier to
patch the particular piece that's been crapping on you, than most
systems.
Except when it's a very large POS.
Can you imaging Microsoft shipping fiche with H kits?
Bob Koehler
>
> It's a limitation is built into the VMS operating system routines,
> SYS$BINTIM and SYS$ASCTIM.
These routines also have a limit of 9999 years. There is a very
famous SPR which promises to fix them in time.
I wonder if the records of the SPR actually survived the
DEC-Compaq-HP-India changes?
Bill Gunshannon
koe...@eisner.nospam.encompasserve.org (Bob Koehler) writes:
> In article <iqf63n$57t$1...@Iltempo.Update.UU.SE>, Johnny Billquist <b...@softjar.se> writes:
>>
>> Linux is crap. That's old news. :-)
>> But it's moving crap, which in some ways is better than things sitting
>> still sometimes.
>
> Yes, but it's easy to get the latest source. Which makes it easier to
> patch the particular piece that's been crapping on you, than most
> systems.
Most of the problems with Linux are systemic. All the source in the
world doesn't make fixing it easy, practical or reasonable. Especially
when there are (and have always been!) functional replacements without
all the mistakes. Too bad the IT industry is so far in the crapper that
the "experts" seem unable to even see this. (And yes, after 23 years in
academia I know exactly where the problem lies and originated!!)
Dennis Boone
> happen if I built a system started it running, took a snapshot, shut it
> down and then restarted it from the snapshot (note, not reboot, restart)
> 10 years later? Would it report an uptime of 10 years?
Likely. I was running apt-get upgrade on a xen domu when the host was
shut down one time. Guest suspended, hadware rebooted, guest resumed,
finished applying updates like nothing had happened. Jut like it's
supposed to work, but you always expect reality to intervene.
De
Henry Crun
Found "among my souvenirs' : (look out for line wrap)
---------------------<start code>-------------------------------
.title get system up time
.link /sys$system:sys.stb/
;
; for Alpha: link/SYSEXE
;
; Macro to setup calling sub-routine
;
.macro call_division dvsr, dvdent, quot, remainder
pushl dvsr
pushl dvdent
pushal quot
pushal remainder
calls #4, division
.endm call_division
.psect data, long, wrt, noexe
up_sec: .long 0
hrs: .long 0
min: .long 0
sec: .long 0
day: .long 0
sec_remain:.long 0
min_remain:.long 0
hrs_remain:.long 0
q_tmp: .quad 0
sixty: .long 60
hrs_in_day:.long 24
ctrstr: .ascid /System has been up for !UL day!%S, !UL hour!%S, <<<- line wrap!
!UL minute!%S and !UL second!%S/
outdesc: .long 80
.address outstr
outstr: .blkb 80
outlen: .long 0
.psect code, long, exe
.entry uptime,0
movl g^exe$gl_abstim, up_sec
;
; Calculate number of minutes and store remaining seconds
;
cal_min:
call_division sixty, up_sec, min, sec_remain
cmpl min, #0
beql skip
;
; Calculate number of hours and store remaining minutes
;
cal_hrs:
call_division sixty, min, hrs, min_remain
cmpl hrs, #0
beql skip
;
; Calculate number of days and store remaining hours
;
cal_day:
call_division hrs_in_day, hrs, day, hrs_remain
; cmpl hrs, #0
; beql skip
;
; Format the output string to be printed out
;
skip:
$fao_s ctrstr=ctrstr, -
outlen=outlen, -
outbuf=outdesc, -
p1=day,-
p2=hrs_remain,-
p3=min_remain,-
p4=sec_remain
movl outlen, outdesc
pushal outdesc
calls #1, g^lib$put_output
ret
;
; Routine to do the divisions
;
.entry division, ^m<>
clrq q_tmp
movl 4(ap), r5 ;remainder
movl 8(ap), r6 ;quotient
movl 12(ap), q_tmp ;dividend
movl 16(ap), r8 ;divisor
ediv r8, q_tmp, (r6), (r5)
ret
.end uptime
---------------------------<end code>----------------------------
--
Mike R.
Home: http://alpha.mike-r.com/
QOTD: http://alpha.mike-r.com/php/qotd.php
No Micro$oft products were used in the URLs above, or in preparing this message.
Recommended reading: http://www.catb.org/~esr/faqs/smart-questions.html#before
Homer Shoemaker
> This is the best so far at my current site. This would be longer had
> we not moved datacenters...
>
> OpenVMS V7.1-2 on node xxx 10-MAY-2011 13:52:46.60 Uptime 842
> 20:38:06
>
> Can anyone beat this?
Can I get an honorable mention?
$ SHOW SYSTEM
OpenVMS V8.3 on node XXXXX 12-MAY-2011 11:55:59.46 Uptime 707
14:50:23
$ sh us
OpenVMS User Processes at 12-MAY-2011 12:05:39.71
Total number of users = 122, number of processes = 447
Joe Bloggs
<dansabr...@yahoo.com> wrote:
Best we've ever seen for production systems,
(single systems, not clustered) is 3.5 - 4 years.
similar to everyone else, UPS/Generator work
gets in the way of better numbers ...
this was from a Alpha 8.3 system (mostly unpatched):
(the only numbers I had captured, and easy to find, atm)
now: .......3-NOV-2010 16:00:47.65
boot: .....24-JUN-2007 06:34:10.00
uptim: .................1228 09:26:37.65
that's approx 3yrs 133 days.
Steve Thompson
> Linux versions of NFS are, in some way, stateful and a reboot of the
> server requires a reboot of all the clients.
I have a lot of Linux NFS servers and a lot of NFS clients, mostly Linux
and some OSX, and over several years I have never seen a server reboot
cause any problems for a client, not that a server reboot happens often.
Steve
glen herrmannsfeldt
(snip)
> I have a lot of Linux NFS servers and a lot of NFS clients, mostly Linux
> and some OSX, and over several years I have never seen a server reboot
> cause any problems for a client, not that a server reboot happens often.
It is only supposed to fail (stale file handle) if, for example,
you replace the disk drive with a completely different one.
You wouldn't want data from a file open on the previous disk to
be written to the new one.
-- glen
Bob Eager
Even then, if the inode numbers are preserved, it shpuld be OK.
Johnny Billquist
> On Fri, 13 May 2011 01:21:48 +0000, glen herrmannsfeldt wrote:
>
>> Steve Thompson<s...@vgersoft.com> wrote:
>>
>> (snip)
>>> I have a lot of Linux NFS servers and a lot of NFS clients, mostly
>>> Linux and some OSX, and over several years I have never seen a server
>>> reboot cause any problems for a client, not that a server reboot
>>> happens often.
>>
>> It is only supposed to fail (stale file handle) if, for example, you
>> replace the disk drive with a completely different one. You wouldn't
>> want data from a file open on the previous disk to be written to the new
>> one.
>
> Even then, if the inode numbers are preserved, it shpuld be OK.
No. Because at that point, the inode numbers might mean totally
different files.
A full file identification is a combination of the inode number, and a
device identifier.
inode number themselfs are only guaranteed to be unique within one file
system. Even on local disks, you can have the same inode number for
different files, if they are on different local disks.
Johnny
Johnny Billquist
And that was meant to read "even on local machines..."
Johnny
Bob Eager
> On 2011-05-13 00.01, Bob Eager wrote:
>> On Fri, 13 May 2011 01:21:48 +0000, glen herrmannsfeldt wrote:
>>
>>> Steve Thompson<s...@vgersoft.com> wrote:
>>>
>>> (snip)
>>>> I have a lot of Linux NFS servers and a lot of NFS clients, mostly
>>>> Linux and some OSX, and over several years I have never seen a server
>>>> reboot cause any problems for a client, not that a server reboot
>>>> happens often.
>>>
>>> It is only supposed to fail (stale file handle) if, for example, you
>>> replace the disk drive with a completely different one. You wouldn't
>>> want data from a file open on the previous disk to be written to the
>>> new one.
>>
>> Even then, if the inode numbers are preserved, it shpuld be OK.
>
> No. Because at that point, the inode numbers might mean totally
> different files.
Not what I said. I said "IF the inode numbers are preserved". I accept
that this may not necessarily be the case.
> A full file identification is a combination of the inode number, and a
> device identifier.
And the device identifier need not change.
> inode number themselfs are only guaranteed to be unique within one file
> system. Even on local disks, you can have the same inode number for
> different files, if they are on different local disks.
Yes, I know that. In fact, the same local disk can include the same inode
number multiple times, since the disk is likely to be partitioned into
distinct file systems.
Johnny Billquist
> On Fri, 13 May 2011 00:54:09 -0600, Johnny Billquist wrote:
>
>> On 2011-05-13 00.01, Bob Eager wrote:
>>> On Fri, 13 May 2011 01:21:48 +0000, glen herrmannsfeldt wrote:
>>>
>>>> Steve Thompson<s...@vgersoft.com> wrote:
>>>>
>>>> (snip)
>>>>> I have a lot of Linux NFS servers and a lot of NFS clients, mostly
>>>>> Linux and some OSX, and over several years I have never seen a server
>>>>> reboot cause any problems for a client, not that a server reboot
>>>>> happens often.
>>>>
>>>> It is only supposed to fail (stale file handle) if, for example, you
>>>> replace the disk drive with a completely different one. You wouldn't
>>>> want data from a file open on the previous disk to be written to the
>>>> new one.
>>>
>>> Even then, if the inode numbers are preserved, it shpuld be OK.
>>
>> No. Because at that point, the inode numbers might mean totally
>> different files.
>
> Not what I said. I said "IF the inode numbers are preserved". I accept
> that this may not necessarily be the case.
Ok. True. Yes, if the inode numbers were preserved, then it would be
theoretically possible.
However, the OS have no way of knowing for sure that the inode numbers
were preserved, so that is more on the theoretical side (I actually
don't know of any way to actually preserve inode numbers when copying a
disk...).
>> A full file identification is a combination of the inode number, and a
>> device identifier.
>
> And the device identifier need not change.
No. But the OS should probably always do this, because it can't decide
for sure, and taking a chance with this is a good way to disaster.
>> inode number themselfs are only guaranteed to be unique within one file
>> system. Even on local disks, you can have the same inode number for
>> different files, if they are on different local disks.
>
> Yes, I know that. In fact, the same local disk can include the same inode
> number multiple times, since the disk is likely to be partitioned into
> distinct file systems.
Right.
Johnny
Bob Eager
> Ok. True. Yes, if the inode numbers were preserved, then it would be
> theoretically possible.
> However, the OS have no way of knowing for sure that the inode numbers
> were preserved, so that is more on the theoretical side (I actually
> don't know of any way to actually preserve inode numbers when copying a
> disk...).
The equivalent of BACKUP/PHYSICAL would do it. It would be nice though...
Steve Thompson
> On Fri, 13 May 2011 01:49:24 -0600, Johnny Billquist wrote:
>
>> Ok. True. Yes, if the inode numbers were preserved, then it would be
>> theoretically possible.
>> However, the OS have no way of knowing for sure that the inode numbers
>> were preserved, so that is more on the theoretical side (I actually
>> don't know of any way to actually preserve inode numbers when copying a
>> disk...).
>
> The equivalent of BACKUP/PHYSICAL would do it. It would be nice though...
That would be dd.
seasoned_geek
> On 2011-05-11 07.09, Bill Gunshannon wrote:
>
>
>
>
>
>
>
>
>
> > In article<d768c138-27f6-40fb-8248-57a4e5aea...@y31g2000vbp.googlegroups.com>,
> > BillPedersen<peder...@ccsscorp.com> writes:
> >>> we not moved datacenters...
>
> >>> OpenVMS V7.1-2 on node xxx 10-MAY-2011 13:52:46.60 Uptime 842
> >>> 20:38:06
>
> >>> Can anyone beat this?
> >> OpenVMS.
> >> While there has not been the determination of the exact criteria for
> >> evaluation everyone should know that there will be an "Availability
> >> Award" presented at this year's Connect OpenVMS Boot Camp at the
> >> Sheraton Needham in September. Sue Skonetski is working with the HP
> >> OpenVMS organization to define the criteria. Once it is defined we
> >> will make sure to publish so people can submit their sites for
> >> consideration.
>
> > server1# uname -a
> > FreeBSD server1.cs.uofs.edu 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Sun May 7 04:42:56 UTC 2006 r...@opus.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP i386
> > server1# uptime
> > 9:05AM up 4914 days, 19:54, 1 user, load averages: 0.00, 0.00, 0.00
> > server1#
>
> > What do I win?
>
> How did you get near 5000 days from a system built 5 years ago? There is
> only about 1800 days in 5 years...
>
> Johnny
And now you understand why a degree from his school isn't worth the
roll of Charmin it is printed on.
Bill Gunshannon
Rich Jordan
> On May 10, 1:54 pm, abrsvc <dansabrservi...@yahoo.com> wrote:
>
> > This is the best so far at my current site. This would be longer had
> > we not moved datacenters...
>
> > OpenVMS V7.1-2 on node xxx 10-MAY-2011 13:52:46.60 Uptime 842
> > 20:38:06
>
> > Can anyone beat this?
>
> 09:42:37
>
> Boottime = 22-AUG-2008 08:07:46.08
>
> We're cheering for 1000 though that would not be a record for this box
> (close to 1500 days). They always lose it to a powerfail that
> outlasts the backup power, or once to replace an internal drive.
VAX/VMS V6.1 on node ZZZZ 13-May-2011 11:49:04.41 Uptime 994
03:21:58
Next Thursday is the next 'big day'. Unfortunately its spring storm
season, but we're hoping for the best. It has ridden out a couple
outages already that weren't too long.
And a plug: TMESIS UPShot provides UPS support on this box. Works
great, potentially saved the data a couple times in the past when
power was out too long.
Johnny Billquist
> On Fri, 13 May 2011 01:49:24 -0600, Johnny Billquist wrote:
>
>> Ok. True. Yes, if the inode numbers were preserved, then it would be
>> theoretically possible.
>> However, the OS have no way of knowing for sure that the inode numbers
>> were preserved, so that is more on the theoretical side (I actually
>> don't know of any way to actually preserve inode numbers when copying a
>> disk...).
>
> The equivalent of BACKUP/PHYSICAL would do it. It would be nice though...
Not that I know of any such creature under Unix, but a physical backup
would also limit you to restoring to the same kind/size of disk...
Johnny
Johnny Billquist
Hmm. Yuck! Yes, dd would be a way to copy a disk preserving the inode
numbers. Output disk must be the same size as input disk. And it will be
slow. But ok... :-)
But the OS would still not know that this new disk was equivalent to the
old one...
Johnny
Johnny Billquist
> In article<dce9ccb9-bf84-4d9e...@t19g2000yql.googlegroups.com>,
Whoa! Both of you...
Johnny
Michael Moroney
What's needed is a Linux version of VMS's mount verification.
Bill Gunshannon
I apologize to the group but I have had about all of that idiot
that I can stand. At this point I think it is best if I just
leave. Wether or not I will come back remains to be seen.
JF Mezei
> What's needed is a Linux version of VMS's mount verification.
fsck ?
Bill Gunshannon
My apologies for my outburst but I have had all of this crap
I can stand. With that, I will state my good-byes. I really
don't need this.
Johnny Billquist
No, that would be ANALYZE/REPAIR I think...
Johnny
Johnny Billquist
>
> My apologies for my outburst but I have had all of this crap
> I can stand. With that, I will state my good-byes. I really
> don't need this.
There are abusive people everywhere, Bill. You just have to ignore them.
That's what kill files are for.
Johnny
Paul Sture
mor...@world.std.spaamtrap.com (Michael Moroney) wrote:
Linux (at least Ubuntu) nowadays uses UUIDs (Universal Unique
Identifiers) to identify disks. Dunno without trying whether a dd
operation would duplicate the UUID or not.
<http://www.cyberciti.biz/faq/linux-finding-using-uuids-to-update-fstab/>
--
Paul Sture
Richard B. Gilbert
>
> My apologies for my outburst but I have had all of this crap
> I can stand. With that, I will state my good-byes. I really
> don't need this.
>
> bill
>
Running away won't help, Bill!
A sage once asked, "Why is there so many more horse's asses than there
is horses?"
I have no answer to the question! ;-)
Bob Eager
I know. I was converting it to VMS terms for the general audience! I
first used dd in 1975....
Bob Eager
> On 2011-05-13 09.38, Steve Thompson wrote:
>> On Fri, 13 May 2011, Bob Eager wrote:
>>
>>> On Fri, 13 May 2011 01:49:24 -0600, Johnny Billquist wrote:
>>>
>>>> Ok. True. Yes, if the inode numbers were preserved, then it would be
>>>> theoretically possible.
>>>> However, the OS have no way of knowing for sure that the inode
>>>> numbers were preserved, so that is more on the theoretical side (I
>>>> actually don't know of any way to actually preserve inode numbers
>>>> when copying a disk...).
>>>
>>> The equivalent of BACKUP/PHYSICAL would do it. It would be nice
>>> though...
>>
>> That would be dd.
>
> Hmm. Yuck! Yes, dd would be a way to copy a disk preserving the inode
> numbers. Output disk must be the same size as input disk. And it will be
> slow. But ok... :-)
Don't see why it has to be slow. Give it a nice big buffer and it can be
very fast.
> But the OS would still not know that this new disk was equivalent to the
> old one...
Yes, that *is* the problem.
glen herrmannsfeldt
(snip)
> Hmm. Yuck! Yes, dd would be a way to copy a disk preserving the inode
> numbers. Output disk must be the same size as input disk. And it will be
> slow. But ok... :-)
> But the OS would still not know that this new disk was equivalent to the
> old one...
I am not sure how it knows, but it might be that DD would do.
Even for a larger new disk (with unused space), it might be that
disk data is used to identify it. As far as I understand, it is
left to the implementation on how to distinguish them.
More specifically, how to generate file handles.
-- glen
Johnny Billquist
> On Fri, 13 May 2011 11:18:10 -0600, Johnny Billquist wrote:
>
>> On 2011-05-13 09.38, Steve Thompson wrote:
>>> On Fri, 13 May 2011, Bob Eager wrote:
>>>
>>>> On Fri, 13 May 2011 01:49:24 -0600, Johnny Billquist wrote:
>>>>
>>>>> Ok. True. Yes, if the inode numbers were preserved, then it would be
>>>>> theoretically possible.
>>>>> However, the OS have no way of knowing for sure that the inode
>>>>> numbers were preserved, so that is more on the theoretical side (I
>>>>> actually don't know of any way to actually preserve inode numbers
>>>>> when copying a disk...).
>>>>
>>>> The equivalent of BACKUP/PHYSICAL would do it. It would be nice
>>>> though...
>>>
>>> That would be dd.
>>
>> Hmm. Yuck! Yes, dd would be a way to copy a disk preserving the inode
>> numbers. Output disk must be the same size as input disk. And it will be
>> slow. But ok... :-)
>
> Don't see why it has to be slow. Give it a nice big buffer and it can be
> very fast.
You're still copying a lot of disk blocks (I would suspect) that are
actually not in use. A copy operation that understands the disk content
needs to copy much less. But big buffers will undeniably improve
performance significantly. I don't even dare to think how slow dd is
when you use 512 byte buffers... :-)
>> But the OS would still not know that this new disk was equivalent to the
>> old one...
>
> Yes, that *is* the problem.
Yeah.
Johnny
Johnny Billquist
True.
In theory, it is definitely doable.
Johnny
Richard B. Gilbert
fsck will check the validity of a file system.
Mount verification determines whether or not the disk that is physically
mounted is, in fact, the disk that is supposed to be mounted; e.g. the
disk label written on the disk matches that of the disk that is
supposedly mounted.
I'm not certain that Unix/Linux really cares what disk is mounted.
JF Mezei
> Mount verification determines whether or not the disk that is physically
> mounted is, in fact, the disk that is supposed to be mounted; e
Doesn't it also check to properly close files (and update various
pointers) that were not closed if the disk was improperly dismounted ?
If that is not "mount verification", what is that process called ?
Michael Moroney
>Richard B. Gilbert wrote:
Mount Verify gets invoked if a drive goes offline when trying to do I/O
to it. It attempts to bring the disk back online, including alternate
path searches (DU/MSCP), and once it brings a disk online it attempts to
verify it is, in fact, the correct disk. I don't remember how extensive
this is, other than it at minimum looks at the disk label.
Not to be confused with either ANALYZE/DISK (checks filestructure for
errors and optionally repairs them) and SET VOLUME/REBUILD (which cleans
up allocated space etc. from an improper dismount)
JF Mezei
> Mount Verify gets invoked if a drive goes offline when trying to do I/O
> to it.
OK, when you reboot after a crash, and the MOUNT command takes an
eternity to complete because it does some "cleanup" of the disk, what is
that process called ?
Johnny Billquist
Traditonally there have been very litte checking for this. Nowadays,
there have come up a number of solutions that makes it just as viable as
VMS. But the fact that a disk have the "right" label is no guarantee
that it is the correct disk... It is only a string, after all...
Johnny
Johnny Billquist
Is that on VMS? I don't think I've seen a mount take an eternity to
complete, except for the time when it waits for a disk to physically
spin up. But then again, I use VMS seldom enough that I might just have
forgotten about it...
Johnny
glen herrmannsfeldt
(snip)
> Mount verification determines whether or not the disk that is physically
> mounted is, in fact, the disk that is supposed to be mounted; e.g. the
> disk label written on the disk matches that of the disk that is
> supposedly mounted.
> I'm not certain that Unix/Linux really cares what disk is mounted.
It seems that Linux can mount either by device file (/dev/sda)
or by disk label. In the latter case, it will find the right
disk, even if it moves to a different mount point.
-- glen
Michael Moroney
>Michael Moroney wrote:
That is a variant of $ SET VOLUME /REBUILD.
(can be put off by $ MOUNT/NOREBUILD and doing $ SET VOLUME /REBUILD later
if desired)
Wilm Boerhout
It will find the disk with the specified label. This may or may not be
the "right" disk, with "right" meaning "the physical disk that was
previously mounted"
--
Wilm Boerhout |
Zwolle, | 'These are the times that try men's souls'
The Netherlands | (Thomas Paine, The Crisis)
Richard B. Gilbert
$ ANALYZE_DISK_STRUCTURE /REPAIR /CONFIRM DKA100:
or something like that???
We have almost NO crashes here and the UPS allows time for a clean
shutdown in case of power outrage!
glen herrmannsfeldt
(snip, someone wrote)
>>> I'm not certain that Unix/Linux really cares what disk is mounted.
(then I wrote)
>> It seems that Linux can mount either by device file (/dev/sda)
>> or by disk label. In the latter case, it will find the right
>> disk, even if it moves to a different mount point.
> It will find the disk with the specified label. This may or may not be
> the "right" disk, with "right" meaning "the physical disk that was
> previously mounted"
In days past, there were systems to assign volume labels to
reduce the chance that two had the same label. (Especially for
tapes, but disks, too.) It seems that I have a linux system
with a disk label of 1, which isn't so likely to be unique.
-- glen
Paul Sture
glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
I've found that the Linux utilities in and around the area of setting up
disks and partitions and OS installation make it easy to lose volume
labels. So much so that it can be easier / less frustrating to set them
when done.
--
Paul Sture
Single Stage to Orbit
> I've found that the Linux utilities in and around the area of setting
> up
> disks and partitions and OS installation make it easy to lose volume
> labels. So much so that it can be easier / less frustrating to set
> them when done.
That simply isn't true any more. Granted, in the early days that did
happen but not nowadays.
--
Tactical Nuclear Kittens
jbriggs444
> Michael Moroney wrote:
> > Mount Verify gets invoked if a drive goes offline when trying to do I/O
> > to it.
>
> OK, when you reboot after a crash, and the MOUNT command takes an
> eternity to complete because it does some "cleanup" of the disk, what is
> that process called ?
Reminds me of the old VMS war story... Guys are in the
machine room working on a chassis with a stack of RA81's.
The wheels weren't locked and the thing rolls into a hole
where a floor tile would have been. The frame is bent
and they use a car jack to straighten it out again.
Just for grins they fire the thing back up and VMS boots
cleanly except for one message:
"Volume improperly dismounted, rebuild in progress"
Robert A. Brooks
> JF Mezei<jfmezei...@vaxination.ca> writes:
>> Doesn't it also check to properly close files (and update various
>> pointers) that were not closed if the disk was improperly dismounted ?
>> If that is not "mount verification", what is that process called ?
>
> Mount Verify gets invoked if a drive goes offline when trying to do I/O
> to it. It attempts to bring the disk back online, including alternate
> path searches (DU/MSCP),
Similar to DUDRIVER "connection walking", Multipath for fibre channel
and SCSI devices is invoked as part of mount verification.
It's kinda fun to look at [SYS]MOUNTVER.MAR from VAX/VMS V1.0 and see
how simple it was, compared to the complexity of what happens today,
which isn't even the full story, as other areas play a role in mount
verification (DKDRIVER, SHDRIVER for shadow sets).
-- Rob