Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.vms > #2767 > unrolled thread
| Started by | abrsvc <dansabrservices@yahoo.com> |
|---|---|
| First post | 2011-05-10 11:54 -0700 |
| Last post | 2011-05-12 09:35 -0700 |
| Articles | 20 on this page of 136 — 34 participants |
Back to article view | Back to comp.os.vms
Uptime for OpenVMS abrsvc <dansabrservices@yahoo.com> - 2011-05-10 11:54 -0700
Re: Uptime for OpenVMS Marc Schlensog <mschlens+news@gmail.com> - 2011-05-10 21:11 +0200
Re: Uptime for OpenVMS abrsvc <dansabrservices@yahoo.com> - 2011-05-10 12:23 -0700
Re: Uptime for OpenVMS koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-10 15:59 -0500
Re: Uptime for OpenVMS Paul Sture <paul.nospam@sture.ch> - 2011-05-11 13:59 +0200
Re: Uptime for OpenVMS Rich Jordan <jordan@ccs4vms.com> - 2011-05-10 16:21 -0700
Re: Uptime for OpenVMS Rich Jordan <jordan@ccs4vms.com> - 2011-05-13 09:59 -0700
Re: Uptime for OpenVMS Neil Rieck <n.rieck@sympatico.ca> - 2011-05-11 03:38 -0700
Re: Uptime for OpenVMS koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-11 07:32 -0500
Re: Uptime for OpenVMS billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-11 13:04 +0000
Re: Uptime for OpenVMS "Richard B. Gilbert" <rgilbert88@comcast.net> - 2011-05-11 17:20 -0400
Re: Uptime for OpenVMS BillPedersen <pedersen@ccsscorp.com> - 2011-05-11 04:01 -0700
Re: Uptime for OpenVMS billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-11 13:09 +0000
Re: Uptime for OpenVMS JF Mezei <jfmezei.spamnot@vaxination.ca> - 2011-05-11 09:15 -0400
Re: Uptime for OpenVMS billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-11 14:55 +0000
Re: Uptime for OpenVMS ChrisQ <meru@devnull.com> - 2011-05-17 16:22 +0100
Re: Uptime for OpenVMS helbig@astro.multiCLOTHESvax.de (Phillip Helbig---undress to reply) - 2011-05-17 18:35 +0000
Re: Uptime for OpenVMS Keith Parris <keithparris_deletethis@yahoo.com> - 2011-05-17 14:15 -0600
Re: Uptime for OpenVMS ChrisQ <meru@devnull.com> - 2011-05-17 22:48 +0100
Re: Uptime for OpenVMS seasoned_geek <roland@logikalsolutions.com> - 2011-05-21 08:54 -0700
Re: Uptime for OpenVMS Paul Sture <paul.nospam@sture.ch> - 2011-05-25 10:30 +0200
Re: Uptime for OpenVMS moroney@world.std.spaamtrap.com (Michael Moroney) - 2011-05-17 23:19 +0000
Re: Uptime for OpenVMS Paul Sture <paul.nospam@sture.ch> - 2011-05-18 11:25 +0200
Re: Uptime for OpenVMS MG <marcogbNO@SPAMxs4all.nl> - 2011-05-17 20:41 +0200
Re: Uptime for OpenVMS "Richard B. Gilbert" <rgilbert88@comcast.net> - 2011-05-17 16:37 -0400
Re: Uptime for OpenVMS MG <marcogbNO@SPAMxs4all.nl> - 2011-05-17 22:47 +0200
Re: Uptime for OpenVMS ChrisQ <meru@devnull.com> - 2011-05-17 22:33 +0100
Re: Uptime for OpenVMS koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-18 09:54 -0500
Re: Uptime for OpenVMS Paul Sture <paul.nospam@sture.ch> - 2011-05-21 06:45 +0200
Re: Uptime for OpenVMS koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-18 09:50 -0500
Re: Uptime for OpenVMS seasoned_geek <roland@logikalsolutions.com> - 2011-05-21 08:25 -0700
Re: Uptime for OpenVMS MG <marcogbNO@SPAMxs4all.nl> - 2011-07-15 15:42 +0200
Re: Uptime for OpenVMS koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-18 09:44 -0500
Re: Uptime for OpenVMS "Richard B. Gilbert" <rgilbert88@comcast.net> - 2011-05-18 11:15 -0400
Re: Uptime for OpenVMS Johnny Billquist <bqt@softjar.se> - 2011-05-18 09:30 -0700
Re: Uptime for OpenVMS "Richard B. Gilbert" <rgilbert88@comcast.net> - 2011-05-18 21:08 -0400
Re: Uptime for OpenVMS Johnny Billquist <bqt@softjar.se> - 2011-05-18 19:13 -0700
Re: Uptime for OpenVMS MG <marcogbNO@SPAMxs4all.nl> - 2011-05-19 11:31 +0200
Re: Uptime for OpenVMS Paul Sture <paul.nospam@sture.ch> - 2011-05-23 13:10 +0200
Re: Uptime for OpenVMS "Syltrem" <syltremzulu@videotron.ca> - 2011-05-19 13:22 -0400
Re: Uptime for OpenVMS John Wallace <johnwallace4@yahoo.co.uk> - 2011-05-19 10:53 -0700
Re: Uptime for OpenVMS Paul Sture <paul.nospam@sture.ch> - 2011-05-21 06:36 +0200
Re: Uptime for OpenVMS koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-18 11:59 -0500
Re: Uptime for OpenVMS Single Stage to Orbit <alex.buell@munted.org.uk> - 2011-05-11 16:43 +0100
Re: Uptime for OpenVMS JF Mezei <jfmezei.spamnot@vaxination.ca> - 2011-05-11 12:47 -0400
Re: Uptime for OpenVMS Johnny Billquist <bqt@softjar.se> - 2011-05-11 10:23 -0600
Re: Uptime for OpenVMS John Wallace <johnwallace4@yahoo.co.uk> - 2011-05-11 09:48 -0700
Re: Uptime for OpenVMS billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-11 17:01 +0000
Re: Uptime for OpenVMS Johnny Billquist <bqt@softjar.se> - 2011-05-11 11:02 -0600
Re: Uptime for OpenVMS glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-05-11 18:13 +0000
Re: Uptime for OpenVMS billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-11 18:46 +0000
Re: Uptime for OpenVMS glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-05-11 18:59 +0000
Re: Uptime for OpenVMS billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-11 19:12 +0000
Re: Uptime for OpenVMS Johnny Billquist <bqt@softjar.se> - 2011-05-11 17:28 -0600
Re: Uptime for OpenVMS billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-12 00:06 +0000
Re: Uptime for OpenVMS Johnny Billquist <bqt@softjar.se> - 2011-05-11 18:37 -0600
Re: Uptime for OpenVMS glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-05-12 09:08 +0000
Re: Uptime for OpenVMS koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-12 08:36 -0500
Re: Uptime for OpenVMS billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-12 14:12 +0000
Re: Uptime for OpenVMS Bob Eager <rde42@spamcop.net> - 2011-05-11 19:26 +0000
Re: Uptime for OpenVMS billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-11 20:40 +0000
Re: Uptime for OpenVMS Bob Eager <rde42@spamcop.net> - 2011-05-11 21:12 +0000
Re: Uptime for OpenVMS Single Stage to Orbit <alex.buell@munted.org.uk> - 2011-05-11 23:33 +0100
Re: Uptime for OpenVMS Bob Eager <rde42@spamcop.net> - 2011-05-12 05:49 +0000
Re: Uptime for OpenVMS Steve Thompson <smt@vgersoft.com> - 2011-05-12 16:56 -0400
Re: Uptime for OpenVMS glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-05-13 01:21 +0000
Re: Uptime for OpenVMS Bob Eager <rde42@spamcop.net> - 2011-05-13 06:01 +0000
Re: Uptime for OpenVMS Johnny Billquist <bqt@softjar.se> - 2011-05-13 00:54 -0600
Re: Uptime for OpenVMS Johnny Billquist <bqt@softjar.se> - 2011-05-13 01:13 -0600
Re: Uptime for OpenVMS Bob Eager <rde42@spamcop.net> - 2011-05-13 07:32 +0000
Re: Uptime for OpenVMS Johnny Billquist <bqt@softjar.se> - 2011-05-13 01:49 -0600
Re: Uptime for OpenVMS Bob Eager <rde42@spamcop.net> - 2011-05-13 08:45 +0000
Re: Uptime for OpenVMS Steve Thompson <smt@vgersoft.com> - 2011-05-13 11:38 -0400
Re: Uptime for OpenVMS Johnny Billquist <bqt@softjar.se> - 2011-05-13 11:18 -0600
Re: Uptime for OpenVMS moroney@world.std.spaamtrap.com (Michael Moroney) - 2011-05-13 17:24 +0000
Re: Uptime for OpenVMS JF Mezei <jfmezei.spamnot@vaxination.ca> - 2011-05-13 13:38 -0400
Re: Uptime for OpenVMS Johnny Billquist <bqt@softjar.se> - 2011-05-13 12:45 -0600
Re: Uptime for OpenVMS "Richard B. Gilbert" <rgilbert88@comcast.net> - 2011-05-13 15:11 -0400
Re: Uptime for OpenVMS JF Mezei <jfmezei.spamnot@vaxination.ca> - 2011-05-13 21:18 -0400
Re: Uptime for OpenVMS moroney@world.std.spaamtrap.com (Michael Moroney) - 2011-05-14 02:35 +0000
Re: Uptime for OpenVMS JF Mezei <jfmezei.spamnot@vaxination.ca> - 2011-05-13 23:24 -0400
Re: Uptime for OpenVMS Johnny Billquist <bqt@softjar.se> - 2011-05-14 02:32 -0600
Re: Uptime for OpenVMS seasoned_geek <roland@logikalsolutions.com> - 2011-05-21 08:09 -0700
Re: Uptime for OpenVMS moroney@world.std.spaamtrap.com (Michael Moroney) - 2011-05-14 13:24 +0000
Re: Uptime for OpenVMS "Richard B. Gilbert" <rgilbert88@comcast.net> - 2011-05-14 11:04 -0400
Re: Uptime for OpenVMS "Robert A. Brooks" <rab@aitchpee.com> - 2011-05-16 11:24 -0400
Re: Uptime for OpenVMS Paul Sture <paul.nospam@sture.ch> - 2011-05-18 11:34 +0200
Re: Uptime for OpenVMS "John Reagan" <johnrreagan@earthlink.net> - 2011-05-18 07:03 -0400
Re: Uptime for OpenVMS seasoned_geek <roland@logikalsolutions.com> - 2011-05-21 07:54 -0700
Re: Uptime for OpenVMS "Robert A. Brooks" <rab@aitchpee.com> - 2011-05-23 10:00 -0400
Re: Uptime for OpenVMS Johnny Billquist <bqt@softjar.se> - 2011-05-14 02:30 -0600
Re: Uptime for OpenVMS glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-05-14 09:28 +0000
Re: Uptime for OpenVMS Wilm Boerhout <wboerhout-remove@this-gmail.com> - 2011-05-14 15:41 +0200
Re: Uptime for OpenVMS glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-05-14 20:55 +0000
Re: Uptime for OpenVMS Paul Sture <paul.nospam@sture.ch> - 2011-05-15 17:10 +0200
Re: Uptime for OpenVMS Single Stage to Orbit <alex.buell@munted.org.uk> - 2011-05-15 20:17 +0100
Re: Uptime for OpenVMS Paul Sture <paul.nospam@sture.ch> - 2011-05-18 11:37 +0200
Re: Uptime for OpenVMS seasoned_geek <roland@logikalsolutions.com> - 2011-05-21 08:13 -0700
Re: Uptime for OpenVMS seasoned_geek <roland@logikalsolutions.com> - 2011-05-21 08:12 -0700
Re: Uptime for OpenVMS Paul Sture <paul.nospam@sture.ch> - 2011-05-13 21:12 +0200
Re: Uptime for OpenVMS Bob Eager <rde42@spamcop.net> - 2011-05-13 19:43 +0000
Re: Uptime for OpenVMS Johnny Billquist <bqt@softjar.se> - 2011-05-13 14:27 -0600
Re: Uptime for OpenVMS glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-05-13 20:05 +0000
Re: Uptime for OpenVMS Johnny Billquist <bqt@softjar.se> - 2011-05-13 14:28 -0600
Re: Uptime for OpenVMS Bob Eager <rde42@spamcop.net> - 2011-05-13 19:41 +0000
Re: Uptime for OpenVMS Johnny Billquist <bqt@softjar.se> - 2011-05-13 11:16 -0600
Re: Uptime for OpenVMS koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-16 15:49 -0500
Re: Uptime for OpenVMS koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-18 09:59 -0500
Re: Uptime for OpenVMS ChrisQ <meru@devnull.com> - 2011-05-17 16:31 +0100
Re: Uptime for OpenVMS drb@ihatespam.msu.edu (Dennis Boone) - 2011-05-12 09:22 -0500
Re: Uptime for OpenVMS glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-05-11 18:09 +0000
Re: Uptime for OpenVMS Bob Eager <rde42@spamcop.net> - 2011-05-11 19:23 +0000
Re: Uptime for OpenVMS JF Mezei <jfmezei.spamnot@vaxination.ca> - 2011-05-11 12:56 -0400
Re: Uptime for OpenVMS Johnny Billquist <bqt@softjar.se> - 2011-05-11 11:04 -0600
Re: Uptime for OpenVMS moroney@world.std.spaamtrap.com (Michael Moroney) - 2011-05-11 17:20 +0000
Re: Uptime for OpenVMS Johnny Billquist <bqt@softjar.se> - 2011-05-11 11:52 -0600
Re: Uptime for OpenVMS JF Mezei <jfmezei.spamnot@vaxination.ca> - 2011-05-11 13:21 -0400
Re: Uptime for OpenVMS Ken Fairfield <ken.fairfield@gmail.com> - 2011-05-11 12:16 -0700
Re: Uptime for OpenVMS jbriggs444 <jbriggs444@gmail.com> - 2011-05-12 05:45 -0700
Re: Uptime for OpenVMS koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-12 08:17 -0500
Re: Uptime for OpenVMS onedbguru <onedbguru@yahoo.com> - 2011-05-11 17:03 -0700
Re: Uptime for OpenVMS Paul Sture <paul.nospam@sture.ch> - 2011-05-12 11:08 +0200
Re: Uptime for OpenVMS jbriggs444 <jbriggs444@gmail.com> - 2011-05-12 05:30 -0700
Re: Uptime for OpenVMS koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-12 08:39 -0500
Re: Uptime for OpenVMS Henry Crun <mike@rechtman.com> - 2011-05-12 18:41 +0300
Re: Uptime for OpenVMS seasoned_geek <roland@logikalsolutions.com> - 2011-05-13 08:49 -0700
Re: Uptime for OpenVMS Johnny Billquist <bqt@softjar.se> - 2011-05-13 11:19 -0600
Re: Uptime for OpenVMS billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-13 17:57 +0000
Re: Uptime for OpenVMS Johnny Billquist <bqt@softjar.se> - 2011-05-13 12:46 -0600
Re: Uptime for OpenVMS "Richard B. Gilbert" <rgilbert88@comcast.net> - 2011-05-13 15:16 -0400
Re: Uptime for OpenVMS "R.A.Omond" <Roy.Omond@BlueBubble.UK.Com> - 2011-05-11 13:58 +0100
Re: Uptime for OpenVMS MG <marcogbNO@SPAMxs4all.nl> - 2011-05-11 15:31 +0200
Re: Uptime for OpenVMS abrsvc <dansabrservices@yahoo.com> - 2011-05-11 06:37 -0700
Re: Uptime for OpenVMS Rich Jordan <jordan@ccs4vms.com> - 2011-05-11 07:42 -0700
Re: Uptime for OpenVMS Homer Shoemaker <homer.shoemaker@gmail.com> - 2011-05-12 09:07 -0700
Re: Uptime for OpenVMS Joe Bloggs <JBloggs@acme.com> - 2011-05-12 09:35 -0700
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
| From | Bob Eager <rde42@spamcop.net> |
|---|---|
| Date | 2011-05-13 19:43 +0000 |
| Message-ID | <935fv8F6diU5@mid.individual.net> |
| In reply to | #2864 |
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. > But the OS would still not know that this new disk was equivalent to the > old one... Yes, that *is* the problem. -- Use the BIG mirror service in the UK: http://www.mirrorservice.org *lightning protection* - a w_tom conductor
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2011-05-13 14:27 -0600 |
| Message-ID | <iqk484$pa4$1@Iltempo.Update.UU.SE> |
| In reply to | #2875 |
On 2011-05-13 13.43, Bob Eager wrote: > 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
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2011-05-13 20:05 +0000 |
| Message-ID | <iqk2us$9vv$2@dont-email.me> |
| In reply to | #2864 |
Johnny Billquist <bqt@softjar.se> wrote: (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
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2011-05-13 14:28 -0600 |
| Message-ID | <iqk4ab$pa4$2@Iltempo.Update.UU.SE> |
| In reply to | #2876 |
On 2011-05-13 14.05, glen herrmannsfeldt wrote: > Johnny Billquist<bqt@softjar.se> wrote: > > (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. True. In theory, it is definitely doable. Johnny
[toc] | [prev] | [next] | [standalone]
| From | Bob Eager <rde42@spamcop.net> |
|---|---|
| Date | 2011-05-13 19:41 +0000 |
| Message-ID | <935frsF6diU4@mid.individual.net> |
| In reply to | #2859 |
On Fri, 13 May 2011 11:38:36 -0400, 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. I know. I was converting it to VMS terms for the general audience! I first used dd in 1975.... -- Use the BIG mirror service in the UK: http://www.mirrorservice.org *lightning protection* - a w_tom conductor
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2011-05-13 11:16 -0600 |
| Message-ID | <iqjp1l$lmc$1@Iltempo.Update.UU.SE> |
| In reply to | #2855 |
On 2011-05-13 02.45, 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... 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
[toc] | [prev] | [next] | [standalone]
| From | koehler@eisner.nospam.encompasserve.org (Bob Koehler) |
|---|---|
| Date | 2011-05-16 15:49 -0500 |
| Message-ID | <LHspuMvNevO9@eisner.encompasserve.org> |
| In reply to | #2853 |
On 2011-05-13 21.24, JF Mezei wrote: > 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 ? It's rebuilding the bitmap. You can skip that at mount with /NOREBUILD, and do it at your convinience with SET VOLUME /REBUILD. Typically on production systems I use /NOREBUILD during boot and SET VOLUME/REBUILD prior to the overnight BACKUP. The bitmap is cached with some block pre set as allocated. If the bitmap needs to be rebuilt and you delay it, there's a little bit of free space that's marked allocated until you do rebuild.
[toc] | [prev] | [next] | [standalone]
| From | koehler@eisner.nospam.encompasserve.org (Bob Koehler) |
|---|---|
| Date | 2011-05-18 09:59 -0500 |
| Message-ID | <+mZ+udpsS2AJ@eisner.encompasserve.org> |
| In reply to | #2850 |
In article <paul.nospam-AC81E2.11340318052011@pbook.sture.ch>, Paul Sture <paul.nospam@sture.ch> writes: > > I believe it was Larry Kilgallen who related the tale of how mount > verification came into being. IIRC the tale went that a new and junior > member of VMS Engineering took a disk out without dismounting it first, > causing some disruption. Instad of being screamed at, the offender got > told to address the problem, and mount verification was the outcome. Yes, I recall that story. (But not who from). On the other hand, I've seen an 11/780 run for many minutes after it's system disk was pulled by accident (somebody swapped the unit plugs on the first two RP06). Then errorlog tried to put a time stamp in the error log file, the failure was reported to OPCOM which reported it on the console and tried to log it in the operator log. Both write attempts caused errorlog to try to record disk I/O failure, ... The only thing that allowed other processes to keep going was the slow speed of the LA36 console, which held up OPCOM from chewing up too much CPU time as it worked on it's growing backlog of messages.
[toc] | [prev] | [next] | [standalone]
| From | ChrisQ <meru@devnull.com> |
|---|---|
| Date | 2011-05-17 16:31 +0100 |
| Message-ID | <XwwAp.962$t41.415@newsfe25.ams2> |
| In reply to | #2813 |
Bill Gunshannon wrote: > > 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. Not sure if that's true or not, or is it something that was introduced as a mount option on nfs V4 ?. Still have the Solaris 10 server here, which talks well to Linux boxen, as well as several pc's running NfsAxe nfs client... Regards, Chris > > >> >>> 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. > > bill >
[toc] | [prev] | [next] | [standalone]
| From | drb@ihatespam.msu.edu (Dennis Boone) |
|---|---|
| Date | 2011-05-12 09:22 -0500 |
| Message-ID | <wradnXfIUaiScFbQnZ2dnUVZ_rGdnZ2d@giganews.com> |
| In reply to | #2805 |
> 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? 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
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2011-05-11 18:09 +0000 |
| Message-ID | <iqejd5$2ia$1@dont-email.me> |
| In reply to | #2803 |
John Wallace <johnwallace4@yahoo.co.uk> wrote:
(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
[toc] | [prev] | [next] | [standalone]
| From | Bob Eager <rde42@spamcop.net> |
|---|---|
| Date | 2011-05-11 19:23 +0000 |
| Message-ID | <93060sF83tU6@mid.individual.net> |
| In reply to | #2811 |
On Wed, 11 May 2011 18:09:41 +0000, glen herrmannsfeldt wrote: > John Wallace <johnwallace4@yahoo.co.uk> wrote: > > (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. 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
[toc] | [prev] | [next] | [standalone]
| From | JF Mezei <jfmezei.spamnot@vaxination.ca> |
|---|---|
| Date | 2011-05-11 12:56 -0400 |
| Message-ID | <4dcabfc1$0$28807$c3e8da3$c8b7d2e6@news.astraweb.com> |
| In reply to | #2801 |
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 ?
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2011-05-11 11:04 -0600 |
| Message-ID | <iqefit$s6n$2@Iltempo.Update.UU.SE> |
| In reply to | #2804 |
On 2011-05-11 10.56, JF Mezei wrote: > > 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 ? 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
[toc] | [prev] | [next] | [standalone]
| From | moroney@world.std.spaamtrap.com (Michael Moroney) |
|---|---|
| Date | 2011-05-11 17:20 +0000 |
| Message-ID | <iqegg0$c85$1@pcls6.std.com> |
| In reply to | #2807 |
Johnny Billquist <bqt@softjar.se> writes: >On 2011-05-11 10.56, JF Mezei wrote: >> Is this due to a 32 bit limitation in DCL that would not allow a >> delta-time greater than 32 bits ? >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 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
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2011-05-11 11:52 -0600 |
| Message-ID | <iqeic2$tpp$1@Iltempo.Update.UU.SE> |
| In reply to | #2808 |
On 2011-05-11 11.20, Michael Moroney wrote: > Johnny Billquist<bqt@softjar.se> writes: > >> On 2011-05-11 10.56, JF Mezei wrote: >>> Is this due to a 32 bit limitation in DCL that would not allow a >>> delta-time greater than 32 bits ? > >> 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 > > 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 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
[toc] | [prev] | [next] | [standalone]
| From | JF Mezei <jfmezei.spamnot@vaxination.ca> |
|---|---|
| Date | 2011-05-11 13:21 -0400 |
| Message-ID | <4dcac5a9$0$2747$c3e8da3$2e0018d8@news.astraweb.com> |
| In reply to | #2807 |
Johnny Billquist wrote: > > 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.
[toc] | [prev] | [next] | [standalone]
| From | Ken Fairfield <ken.fairfield@gmail.com> |
|---|---|
| Date | 2011-05-11 12:16 -0700 |
| Message-ID | <62f37534-d939-4629-8217-c2926a1989ae@j13g2000pro.googlegroups.com> |
| In reply to | #2804 |
On May 11, 9:56 am, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> 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 ?
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
[toc] | [prev] | [next] | [standalone]
| From | jbriggs444 <jbriggs444@gmail.com> |
|---|---|
| Date | 2011-05-12 05:45 -0700 |
| Message-ID | <c787842f-e1c9-4af6-a9f4-b82e4657b6d0@d26g2000prn.googlegroups.com> |
| In reply to | #2816 |
On May 11, 3:16 pm, Ken Fairfield <ken.fairfi...@gmail.com> wrote: > 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
[toc] | [prev] | [next] | [standalone]
| From | koehler@eisner.nospam.encompasserve.org (Bob Koehler) |
|---|---|
| Date | 2011-05-12 08:17 -0500 |
| Message-ID | <kM45h133N+Js@eisner.encompasserve.org> |
| In reply to | #2816 |
In article <62f37534-d939-4629-8217-c2926a1989ae@j13g2000pro.googlegroups.com>, Ken Fairfield <ken.fairfield@gmail.com> writes: > > 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.
[toc] | [prev] | [next] | [standalone]
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
Back to top | Article view | comp.os.vms
csiph-web