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

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

Re: [Gnu-arch-users] Re: give us a hand with arch


From: Ethan Benson
Subject: Re: [Gnu-arch-users] Re: give us a hand with arch
Date: Sat, 27 Sep 2003 13:33:31 -0800
User-agent: Mutt/1.3.28i

On Sat, Sep 27, 2003 at 07:54:47PM +0200, Andrea Arcangeli wrote:
> Now the interesting question: am I right that there are already further
> benefits in the tagline compared to explicit tag method (besides not
> having to run an explicit add-tag/delete-tag/move-tag). I understood
> this is the case, and as such the technical gap should be filled, and
> this will make it even easier than using the tagline mode, since people
> won't need to autogenerate arch-tags by hand like they have to do right
> now with the tagline.

there are no advantages to tagline other then the lack of tla
add/delete/move. the new untagged-source directive lets you choose the
behavior tagline uses by default for untagged files in explicit, if
one so desires.

> Yet another obvious reason this is metadata, is that if I would add a
> secondary stream to the same inode in the filesystem explicitly meant
> for userspace metadata, you could store metadata separately from the
> data, and you would provide the user the same property but w/o polluting
> the data (i.e. the metadata wouldn't end in the linux-2.4.22.tar.gz that
> the people only caring about the data downloads). This is exactly what
> you really need infact: you need the metadata stream to avoid the
> add-tag/delete-tag/move-tag. The data pollution is simply a temporary
> workaround for the lack of multiple streams in the inode. LD_PRELOAD
> could emulate it in theory.

you don't need any of that, just use an extended attribute, they can
be at least 64K, which is more then enough for this kind of tag.

the challenge comes in that you need a way to fallback to standard
explicit where tags are in .arch-ids for filesystems not supporting
xattr.  if done right it could be a per user preference in
.arch-params which would work for any project using explicit tags.

basically keep storing explicit tags in the archive exactly as done
now, but on get/replay/whatever write the explicit tag contents into
an xattr for the file it goes with, if possible, otherwise write it
into the .arch-ids file as is done now.  when looking for tags, first
check xattr if possible, and if available, otherwise check normal
.arch-ids.

my suggestion would be to extract the .arch-ids tags into an xattr if
possible, and otherwise do it just as explicit works now.  the tag
should be the same data, its location would be the only difference in
some cases.

-- 
Ethan Benson
http://www.alaska.net/~erbenson/

Attachment: pgp_DDpJBJtMF.pgp
Description: PGP signature


reply via email to

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