Note that the per-volume options are persistent; their values are recorded in the file system "fsinfo block". Thus, for example, you don't have to update "/etc/rc" to put
Interesting. Can you share the reasoning behind making these options persistent?
The following scenario is not uncommon:
- person executes "options" command to fix/change something - person forgets to add it to /etc/rc - time passes (sometimes a lot of time, i.e. till the next reboot) - after the next reboot, it takes (and wastes) time to re-discover the need for the fix/change, and re-apply it.
For this reason, in a future release of ONTAP more things (more than just the per-volume options) will be automatically persistent. You can still put them in /etc/rc, but the trend will be toward not needing to.
A question. Given the choice between:
- Having a command tell you "there's a conflicting command already in /etc/rc, you should change it there as well (or just remove it)" vs. - Having the command automatically update /etc/rc with the change, if it contains a conflicting command.
Which do you think would be a better approach?
...Tim Thompson...Network Appliance, Inc...tjt@netapp.com...
+--- In a previous state of mind, "Thompson, Tim" tim.thompson@netapp.com wrote: | | For this reason, in a future release of ONTAP more things (more than | just the per-volume options) will be automatically persistent. | You can still put them in /etc/rc, but the trend will be toward not | needing to.
Perhaps it could ask if you wish these changes to be persistent (ala write mem on a cisco).
| - Having a command tell you "there's a conflicting | command already in /etc/rc, you should change it there as well | (or just remove it)"
Having it let you know if handy.
Alex
On Mon, 12 Oct 1998, Thompson, Tim wrote:
A question. Given the choice between:
- Having a command tell you "there's a conflicting command already in /etc/rc, you should change it there as well (or just remove it)"
vs.
- Having the command automatically update /etc/rc with the change, if it contains a conflicting command.
Which do you think would be a better approach?
Automatic updating of /etc/rc would be IMHO a *bad* thing. We use RCS to keep revision history of changes that we make to our filers. If the command automatically updated the file, the admin would have to remember to run 'rcs -l rc', 'ci -u rc' straight away. If they forgot to, the next user to come along and make a change that required editing /etc/rc (say SNMP, which I can't see being stored persistently) would run 'co -l rc' and get the last checked in version of the file, wiping out the automatically registered changes.
-
alexei＠cimedia.com -
James FitzGibbon -
Thompson, Tim