gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: tla get --hard-links available


From: Andrea Arcangeli
Subject: Re: [Gnu-arch-users] Re: tla get --hard-links available
Date: Fri, 3 Oct 2003 17:58:54 +0200
User-agent: Mutt/1.4.1i

On Fri, Oct 03, 2003 at 06:53:23AM -0700, Zack Brown wrote:
> On Fri, Oct 03, 2003 at 06:03:44PM +0900, Miles Bader wrote:
> > On Fri, 3 Oct 2003, Paul Hedderly wrote:
> > > At least could get -l create a
> > >   ++WARNING-HARD-LINKS-AT-WORK-HERE-SO-EDIT-AT-YOUR-PEERRRRRRILLLLL!!!!
> > 
> > Yeesh, people are so wimpy.
> > 
> > Maybe a ~/.arch-params/=training-wheels option...
> > 
> > [Anyway, I want someway to make --link the _default_ (for me).]
> 
> Why not have -l be a setting in the archive, rather than a 'get' option?
> If you set a branch to use hard links, then all gets of that branch will use
> them; and the file permissions will be set to read-only (with the original
> permissions recorded in {arch} or wherever, as metadata.
> 
> This has the drawback of forcing all users of a branch to rely on the
> hard link method, but it also makes it easier for them to catch
> themselves inadvertantly corrupting the archive.

I don't think this would be correct. If something it should be an _user_
option, so in ~/.arch-params. I don't think it should be in the {arch}
directory either since it's completely transparent to the archive,
unlike taglines/exlicit etc.. that would better be stored in the
archive to be sure everybody uses the same method.

Here it's up to the user to know about the fact he must overwrite links
in copy-on-write mode or he will get in trouble.

I'd like an override, since I will always use hardlinks so the -l would
be just an overhead for me to type.

The archive is the real data, it sure doesn't need to know how fast we
generated it and in turn it doesn't need to have the hardlink option
inside it, like it doesn't have the mhz of my opteron stored inside.

In the long run the kernel must start storing a bitflag in the on-disk
format of the inode for the kernel level copy-on-write functionality.

For the short term fl-cow helps. BTW, I get segfaults with fl-cow in
64bit mode, I guess it's not 64bit clean, or 64bit glibc hasn't been
tested well yet with LD_PRELOAD.

Andrea - If you prefer relying on open source software, check these links:
            rsync.kernel.org::pub/scm/linux/kernel/bkcvs/linux-2.[45]/
            http://www.cobite.com/cvsps/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]