Hi Jeff,

Does "vos addsite" duplicate a volume's data? Because we are using much more 
than half our capacity, and therefore can't afford to double usage. To be 
blunt, we are trying to make the system read only by stages to encourage users 
to migrate off this system as we are trying to retire it at the end of the year.

If mounting the .backup volume isn't a good option, then that more or less 
leaves me with walking the filesystem, parsing and changing ACLs to have no 
write/insert/delete. This would be irreversible unless I stored the original 
ACL states somehow and could re-apply them later if there was a mistake or a 
political reason to restore a volume to be writeable for awhile.

Though, I am open to ideas. It seems awful to ask about how to retire an 
OpenAFS system on this list, however.

> What are the errors?   Obviously, any access that expects write permission or 
> the ability to obtain a lock is going to fail when the volume isn't writable.

Well the errors indicate the files can't even be read, despite that not being 
the case (at least, it works fine within OpenAFS and with the sftp and http 
gateways we have sitting on top... just not Samba.

OS X at least says:

"The document “Document.rtf” could not be opened."

...and if I copy to the desktop, it says:

"The Finder can’t complete the operation because some data in “Document.rtf” 
can’t be read or written.
(Error code -36)"

Chris
--
E. Christine Garrison
Indiana University
Research Technologies
Research Storage

________________________________________
From: Jeffrey Altman <[email protected]>
Sent: Monday, June 20, 2016 2:36 PM
To: Garrison, Christine; [email protected]
Subject: Re: [OpenAFS] Read-only volume issues

On 6/20/2016 1:59 PM, Garrison, Christine wrote:
>
> I've been tasked with turning many volumes on our site read-only. What
> I've come up with is, I would like to unmount existing read-write
> volumes and mount their readonly .backup volume in their place.

The .backup volume is considered transient and should not be relied upon
to exist.  To create a read-only volume use

  vos addsite

to create a replica site on the same service/partition on which the
normal RW volume exists.  Then execute "vos release" for each volume.

The normal AFS mount points do not need to be altered.  When a cache
manager traverses a normal mount point, if there is a .readonly volume
instance that will be preferred over the normal RW instance.

AFS clients cache the volume group information for a couple of hours
so you should not expect the .readonly to become visible immediately
on a client that has already accessed the normal RW instance.

> The trouble comes in (as always) with our Samba service. We sit Samba on
> top of OpenAFS to serve our users, who have not wanted to install the
> OpenAFS client. It works as well as you might hope, but not for readonly
> volumes in OpenAFS -- if you map a drive in Windows or Mac OS X, you may
> browse the files, but any operation at all that involves reading fails
> with errors.

What are the errors?   Obviously, any access that expects write
permission or the ability to obtain a lock is going to fail when the
volume isn't writable.

Jeffrey Altman

_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info

Reply via email to