Steve Simmons wrote:
On Jul 19, 2007, at 7:10 PM, Kim Kimball wrote:
Why not restore the volume (restores to RW), replicate it (same
server and partition) and then remove the RW?
Mount the resulting readonly explicitly -- i.e. be sure to include
the .readonly suffix in the fs mkm
Works
Oh, I see, you're doing "vos exa foo" and not "vos exa foo.readonly" and
getting the message "Dump only information ... blah"
Missed the earlier part of the discussion -- why is this an issue?
Kim
Steve Simmons wrote:
On Jul 19, 2007, at 7:10 PM, Kim Kimball wrote:
Why not restore the volu
On Jul 19, 2007, at 7:10 PM, Kim Kimball wrote:
Why not restore the volume (restores to RW), replicate it (same
server and partition) and then remove the RW?
Mount the resulting readonly explicitly -- i.e. be sure to include
the .readonly suffix in the fs mkm
Works for me.
Works perfec
Why not restore the volume (restores to RW), replicate it (same server
and partition) and then remove the RW?
Mount the resulting readonly explicitly -- i.e. be sure to include the
.readonly suffix in the fs mkm
Works for me.
Kim
Steve Simmons wrote:
On Jul 18, 2007, at 10:27 AM, Carsten
On Jul 18, 2007, at 11:16 AM, Jeffrey Altman wrote:
Except that the new volume should be "special" in that no changes are
permitted. In other words, the "wida" permissions are neutered on
this
volume. Since the new volume type doesn't exist, modifying the
ACLs is
something that has the s
On Jul 18, 2007, at 10:27 AM, Carsten Schulz-Key wrote:
The RW and RO volumes share the same inodes (for the data part) as
long as
they're on the same partition and the RW volume has not been
altered since
releasing the volume. The space needed for the second volume header
should be
negleg
Harald Barth wrote:
>> Steve's request
>> is for a mechanism of restoring a volume that the user can read but
>> which the user can't alter. This is an ACL issue. Perhaps the solution
>> is to not make the user the owner and take away all "write, insert, and
>> admin" privileges on the volumes di
> Steve's request
> is for a mechanism of restoring a volume that the user can read but
> which the user can't alter. This is an ACL issue. Perhaps the solution
> is to not make the user the owner and take away all "write, insert, and
> admin" privileges on the volumes directories.
I don't want
Carsten Schulz-Key wrote:
> Steve Simmons wrote:
>>> How about restoring the volume without the '-readonly' flag and
>>> adding a
>>> replica on the same partition, followed by a
>>> 'fs mkm RESTORE.070702 user.elevina.070702.readonly' ?
>> That'd work, but it sucks up twice as much disk space,
Steve Simmons wrote:
>> How about restoring the volume without the '-readonly' flag and
>> adding a
>> replica on the same partition, followed by a
>> 'fs mkm RESTORE.070702 user.elevina.070702.readonly' ?
>
> That'd work, but it sucks up twice as much disk space,
The RW and RO volumes share th
On Jul 18, 2007, at 7:13 AM, Carsten Schulz-Key wrote:
Steve Simmons wrote:
This works quite well for our purpose, but if you do a 'vos examine
user.name.YYMMDD' you get
---
Volume user.elevina.070702 does not exist in VLDB
How about restoring the volume without the '-readonly' flag and
Steve Simmons wrote:
>This works quite well for our purpose, but if you do a 'vos examine
>user.name.YYMMDD' you get
>
>---
>Volume user.elevina.070702 does not exist in VLDB
How about restoring the volume without the '-readonly' flag and adding a
replica on the same partition, followed by
This actually works, but results in whiny messages from AFS when you
do vos examines. After some thought, I think the right direction is
to have a different 'type' of read-only volume.
The problem - users writing into restored volumes.
The solution - make restore volumes read-only.
The meth
13 matches
Mail list logo
