| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1071.1 | Is it vdump? vrestore? or the kernel? | UNIFIX::HARRIS | Juggling has its ups and downs | Fri May 30 1997 08:11 | 25 |
| I think we need to find out if vdump didn't save the correct
owner/group or if vrestore didn't set the correct owner/group.
Could you examine the vdump file to see if the correct owner and group
are associated with the /oracle/PT1/sapdata1 directory?
vrestore -lf dump_file
----
Another question? If nothing is mounted the /oracle/PT1/sapdata1
mount point, what is its owner and group?
When you mount something on a mount point, the owner, group, and
permissions are those of the mounted file system, and not the directory
which is acting as the mount point. It is possible that this is
something in the kernel when dealing with clones and mount points and
has nothing to do with vdump or vrestore.
Please let us know what the ownership of the mount point is _WITHOUT_
anything mounted on it.
Thanks.
Bob Harris
|
| 1071.2 | Clone backup correct - non-clone backup wrong | UNIFIX::HARRIS | Juggling has its ups and downs | Fri May 30 1997 08:48 | 48 |
| I just did my own experiment and while I see what you reported, I do
_NOT_ think it is a bug. If anything, I think that the opposite may be
a problem.
It is my guess that the directory (/oracle/PT1/sapdata1) which is
acting as the mount point has an owner:group of root:system (0:0).
When you mounted "File system 2" on top of /oracle/PT1/sapdata1, the
owner and group of "File system 2" became visible and the original
mount point directory's attribute information was hidden behind the
mount point.
When you created a clone of "File system 1" and mounted it, the clone
did _NOT_ have anything mounted on /mnt/clone/sapdata1, so the original
directory's attribute information was what was visible to vdump. And
since the original directory's owner and group were root:system, that
is what vdump backed up. Since vrestore was only restoring what vdump
provided as owner and group.
----
If anything, backing up the /oracle/PT1 file system and _NOT_ the clone
is doing the wrong thing, since the restored /oracle/PT1/sapdata1
directory without a file system mounted on it should be its original
owner and group and protections etc..., but it is not. It is getting
the attributes of the mounted file system which is not the same thing
at all.
Why do I think this is wrong. For example, ilets say I set up a
directory with owner, group and protections that allows anyone without
privileges to mount a CD-ROM (or other file system). Then I back file
system containing this public mount point (and I do _NOT_ use a clone).
And to complete the store, I need to restore the file system from the
backup. Sometime later, I would start to get complaints from users
because they could no longer mount a CD-ROM because the ownership and
protections of the restored public mount point are those of the item
that happened to be mounted on the public mount point at the time of
the backup and not the ones of the underlying directory.
So if anything, I think you are seeing correct behavior in the clone
backup and _WRONG_ behavior in the backup without a clone.
----
Please check the underlying directory's owner:group information and
verify that it is actually root:system. I think you will find that it
is (it was in the experiments I tried).
Bob Harris
|
| 1071.3 | Good idea | BIS1::RAVYTS | | Mon Jun 02 1997 03:13 | 18 |
| Bob,
Thanks for the quick reply !
You are right, all teh directorys acting as a mount point have the
owner:group of root:system.
I have now changed this: the directorys acting as mount points have now
the same owner:group as the owner:group of the file system, and I am
retesting a vrestore(with cloning)/vdump.
I will not discuss if this is a bug or not, but it is a fact that you
normally want, that after a vdump/vrestore of complete file systems, the
situation is exactly as before, and this was not the case !
Regards,
Lieve
|
| 1071.4 | Please let us know how the test works out | UNIFIX::HARRIS | Juggling has its ups and downs | Mon Jun 02 1997 07:23 | 24 |
| Re: .3
> You are right, all teh directorys acting as a mount point have the
> owner:group of root:system.
>
> I have now changed this: the directorys acting as mount points have now
> the same owner:group as the owner:group of the file system, and I am
> retesting a vrestore(with cloning)/vdump.
Let us know the results of your testing. I think you will find the
same conditions that I saw in my quick test.
> I will not discuss if this is a bug or not, but it is a fact that you
> normally want, that after a vdump/vrestore of complete file systems,
> the situation is exactly as before, and this was not the case !
It is my contention that the clone backup was an accurate copy of the
file system. If anything was in error, it was the backup _WITHOUT_ a
clone.
Let us know how things go and then we can discuss if there is a bug and
just where that is.
Bob Harris
|
| 1071.5 | | BIS1::RAVYTS | | Tue Jun 03 1997 01:23 | 14 |
| Bob,
My test was OK, now all directorys acting as mount points have the
correct owner:group after vdump(with cloning)/vrestore.
It still doesn't seem logic to me :
I agree that after the restore of file system 1, the directory which
acts as mount point for file system 2, gets owner:group root:system.
But, I should expect that, at the moment of the restore of file system
2, the owner:group should be restored also !
Regards,
Lieve
|
| 1071.6 | Is it the vrestore of the 2nd FS that is a problem? | UNIFIX::HARRIS | Juggling has its ups and downs | Tue Jun 03 1997 10:14 | 42 |
| > My test was OK, now all directorys acting as mount points have the
> correct owner:group after vdump(with cloning)/vrestore.
They should be root:system if and only if they are really root:system
originally. The owner:group should be whatever the underlying mount
point directory's owner:group are.
> It still doesn't seem logic to me :
> I agree that after the restore of file system 1, the directory which
> acts as mount point for file system 2, gets owner:group root:system.
> But, I should expect that, at the moment of the restore of file system
> 2, the owner:group should be restored also !
Lets see if I understand what you are saying:
create new domain for "File System 1"
vrestore "File System 1" backup onto new domain.
at this point the directory used for the "File System 2" mount
point has been restored to the root:system ownership.
create new domain for "File System 2"
Mount new empty "File System 2" on top of "File System 1" at its
normal mount point.
Ownership at this point in time is that of the new domain (most
likely root:system since you had to be root to create the new
domain).
vrestore "File System 2" backup onto new domain.
at this point you are saying that the root directory of "File System 2"
is _NOT_ the correct owner/group. That vrestore did not change the
owner/group of the root directory back to what it was supposed to be.
If that is your contention, then I would say you have a valid argument.
Have I correctly re-stated what you have been asking?
Bob Harris
|
| 1071.7 | Does anyone know how a full domain restore should work? | UNIFIX::HARRIS | Juggling has its ups and downs | Tue Jun 03 1997 10:30 | 21 |
| I just tried an experiment. I followed the steps I outlined in .6.
It seems that vrestore does the right thing _IF_ it is creating the
directory, but if the directory already exists, it does not change the
ownership of the directory.
The root:system ownership of "File System 2" is coming from your
creation of the new domain, and not from "File System 1" and not from
the vrestore.
The question is whether this is correct behavior. Or should a vrestore
of an entire domain change the ownership of existing directories?
Maybe a new vrestore option is required.
Does anyone have any opinions?
Bob Harris
PS. Please confirm that the steps in .6 are the steps that you took in
using vrestore, so that I know I am pursuing the correct problem.
|
| 1071.8 | Please provide examples of with and without a Clone | UNIFIX::HARRIS | Juggling has its ups and downs | Tue Jun 03 1997 13:10 | 17 |
| Also, when _NOT_ using a clone to backup you indicated that this was
not a problem. Could you outline the commands (with examples of
command arguments) that you took to do the vdump/vrestore for a clone
_AND_ a non-clone, and point out the differences.
From my experiments, I don't see where using a clone or a non-clone
would make any difference since the source of the owner:group
information is not coming from the vdump/vrestore procedures and it
seems that the value of the underlying mount point wouldn't matter.
Maybe I'm just confused, but if you could provide example commands of
with and without a clone that I could try to duplicate, maybe I can
learn something. Then I would have the foundation to enter a QAR.
Thanks.
Bob Harris
|
| 1071.9 | test scenario | BIS1::RAVYTS | | Wed Jun 04 1997 03:31 | 87 |
| Bob,
Here follow 3 scenarios :
Actions the same for all scenarios :
As root : create directory for mountpoint1 : /oracle/PT1
Create Advfs domain1 and fileset1
Mount this domain1#fileset1 on mountpoint1 /oracle/PT1
Create directory for mountpoint 2 : /oracle/PT1/sapdata1
Create advfs domain2 and fileset2
Mount this domain2#fileset2 on mountpoint2 /oracle/PT1/sapdata1
chown orapt1:dba /oracle/PT1
chown orapt1:dba /oracle/PT1/sapdata1
By installing SAP, files are written on both file systems.
Scenario 1 : no cloning
backup :
vdump -0uf /dev/nrmt0h /oracle/PT1
vdump -0uf /dev/nrmt0h /oracle/PT1/sapdata1
remove data :
rm -r /oracle/PT1
rm -r /oracle/PT1/sapdata1
restore :
vrestore -xvf /dev/nrmt0h -D /oracle/PT1
vrestore -xvf /dev/nrmt0h -D /oracle/PT1/sapdata1
conclusion :
No problems with owner:group
Scenario 2:
backup :
create directorys for mount points of clone file systems :
mkdir /oracle/PT1_clone
mkdir /oracle/PT1/sapdata1_clone
chown orapt1:dba /oracle/PT1
chown orapt1:dba /oracle/PT1/sapdata1
create clone filesets :
clonefset domain1 fileset1 fileset1_clone
clonefset domain2 fileset2 fileset2_clone
mount clone fileset :
mount -t advfs domain1#fileset1_clone /oracle/PT1_clone
mount -t advfs domain2#fileset2_clone /oracle/PT1/sapdata1_clone
vdump -Ouf /dev/nrmt0h /oracle/PT1_clone
umount /oracle/PT1_clone
rmfset domain1 fileset1_clone
vdump -Ouf /dev/nrmt0h /oracle/PT1/sapdata1_clone
umount /oracle/PT1/sapdata1_clone
rmfset domain1 fileset1_clone
remove data :
see scenario 1
restore data :
see scenario 1
Conclusion :
/oracle/PT1/sapdata1 has owner:group root:system and not orapt1:dba !!!
Scenario 3 :
The same as scenario 2 but before :
umount /oracle/PT1
umount /oracle/PT1/sapdata1
chown orapt1:dba /oracle/PT1
mount /oracle/PT1
chown orapt1:dba /oracle/PT1/sapdata1
mount /oracle/PT1/sapdata1
for backup, remove and restore : see scenario 2.
Conclusion : owner:group are correct
I hope these scenario's is enough to do your tests,
Lieve
|