[OpenAFS] Re: hard link behavior

[Andrew Deason]

On Tue, 06 Jul 2010 20:54:44 -0400
"Chas Williams (CONTRACTOR)" <chas@cmf.nrl.navy.mil> wrote:

> In message <20100707005602.v77jd7w14tcgwooo@www.umrk.nl>,Jaap Winius
> writes:
> >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
> reversible.

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
course.

> 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).

-- 
Andrew Deason
adeason@sinenomine.net