On 12/30/2014 11:57 AM, Dirk Heinrichs wrote:
Am Dienstag 30 Dezember 2014, 17:33:44 schrieb Levente Peres:

Why same server? An AFS setup usually consists of several servers,
especially  if you want to serve terabytes of data. Not to mention the
needed kerberos server.
Same server because I need the transfer to be quick. Once I start - I
need to do the migration in max 1-2 hrs... tops. I know... I know...
Copy over some terabites of data in 1-2 hours? That's challenging. AFS is a
network filesystem, and your data will need to go through the cache manager
anyway. That means you MUST run the AFS client AND server on this same machine
while it still serves the data from the old location.

Still, what about the kerberos setup? Do you have one already? If not, you'll
have to set it up, too (before setting up AFS).

Unfortunately, I have only this "one" partition remotely big enough to
hold the data and/or fast enough to handle in a reasonable amount of
time.
Fast enough for what? To copy over the data or to serve it afterwards?
Both I guess but that's not the main issue, first problem is migrating
it in a very short time. So I need to do it the ugly way, within the
same server... I don't have 8Gb switches or the like and storage fabric
etc to assist me in this externally... simple "work with what you got"
issue...
But you have rsync at your service. You can use it to copy most of the data
over in the background. You can even do several iterations and then do the
last iterations after ensuring that the data can't be modified anymore.

And that's where you'll get into trouble. You can't mount it ro since it's
also your /vicepa partition. If you serve it via NFS currently, you could re-
export it ro, though.

Bye...

        Dirk

You can do a bind mount where you mount the old folder as read-only (I think) in a new location, then only serve out files via AFS and the renamed read-only share.

    mkdir /vicepa-readonly
    mount /vicepa /vicepa-readonly -o ro
Then share out /vicepa-readonly as a share.

** don't try this at home/work**
Other crazy and dangerous options could include using something like AUFS with the RO orginal data and a new AFS layer on top, which is all mounted as a non-AFS share (security?). Tthe new data would be written to AFS, but still visible as a share until the migration is complete, then change the clients to use AFS instead of the old sharing protocol.
*Here be dragons!!*

Jason
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Reply via email to