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, > > 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 > neglegtable. That's as far as I know -- please correct me if I'm wrong. > >> leaves two >> volumes rather than one that we have to remove later, and the savvy >> user could still mount the r/w original. > > yeah, but you were going to delete it anyways, weren't you? So the worst case > would be that the users mount the RW volume, delete the data and fill it up > with other data -- which they can not rely on since it will be deleted w/o > further notice a couple of days later. In this case you'll indeed end up with > twice the disk space used for a short period of time. I don't think that this > should be much of an issue in the days of Terabyte disks, shouldn't it? ;-) > > > Regards, > Carsten
I suspect the problem is not the disk usage but the problem that the user who has now modified the RW restore data is going to get pissed off when the new version on the restored volume disappears. 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.
smime.p7s
Description: S/MIME Cryptographic Signature
