[OpenAFS] Re: hard link behavior
Tue, 6 Jul 2010 21:47:48 -0500
On Tue, 06 Jul 2010 20:54:44 -0400
"Chas Williams (CONTRACTOR)" <firstname.lastname@example.org> wrote:
> In message <email@example.com>,Jaap Winius
> >For example, if it were possible to change the properties of a
> >volume so that only the ACL of the volume's root directory would
> >apply to all of its subdirectories, then in such cases there would
> >never be any ACL conflicts and the usual limitation that prevents
> >hard links from being created across directories could be suspended.
> this would be fraught with peril to implement safely and isnt
I've heard this suggested before, and I don't see why it's so bad; the
work just hasn't been done. Having cross-dir hardlinks would make it
much easier to just copy directory trees containing cross-dir links from
local disk into AFS. Some things like package repositories also make use
of them, which some people would like to (efficiently) keep in AFS.
> say someone changes their mind about this acl policy. should we go
> through the entire volume fixing the hard links so they arent supposed
> to be hard links?
You could have some tool to 'convert' a single-ACL volume to a regular
one. If you find a cross-dir hardlink, you say "remove any cross-dir
links before doing this" and bail out.
> >If this were possible, such volumes would be great for making
> >disk-based backups on. These solutions typically make heavy use of
> >hard links to save space,
> afs has a better scheme for this -- copy on write. create a volume.
> dump in your backup. now vos clone that volume. this would be a
> snapshot of that backup. future backups go into the original volume,
> vos clone'ing as necessary for the snapshots in time.
I agree this is probably better for this use, but the current state of
OpenAFS tools makes this a bit error prone. But that could be fixed, of
> instead of creating a special hardlinks mode perhaps expending beyond
> the 7 slots for copy on write volumes would be more productive.
Another option is implementing file-granular ACLs. That's arguably the
most useful of these features, but also the hardest (to do 'correctly'
anyway, from what I hear).