[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
re[2]: [rdiff-backup-users] ACLs/EAs (who is the audience?)
From: |
Greg Freemyer |
Subject: |
re[2]: [rdiff-backup-users] ACLs/EAs (who is the audience?) |
Date: |
Fri, 7 Mar 2003 17:44:26 -0500 |
>> How about this as a first step then: rdiff-backup
>> would support something like --record-acls and --record-eas-and-acls
>> switches. These would cause rdiff-backup to save the ACL and EA
>> information on the source side, but it wouldn't attempt to actually
>> read/write ACLs or EAs on the destination side.
Samba treats ACLs as a ./configure parameter, not run time. Maybe that would
be better for rdiff-backup as well.
Also, I suspect you will need to just have --record-acls and --record-eas. If
someone wants both, they need to ask for both.
i.e.
My primary use for this feature is to backup samba exported Linux FSs.
For that situation, I need --record-eas xor --record-acls.
Either would work, but doing both would capture the ACLs twice.
Later on, I would like to run rdiff-backup on a Windows box and capture ACLs
and EAs.
I think they are totally separate on NTFS, so I could use both.
NTFS support is likely to be pretty far down the road because the NTFS native
ACLs and EAs are not available from cygwin.
>> The ACLs and EAs would just be stored in text files on the remote
>> side. I hear that linux considers ACLs a special kind of EA, so we
>> could use linux's system to store ACLs as EAs. From Schultz' email I
>> get the idea that he expects EAs and ACLs to get big.
I agree in both senses of the word.
They will be common and IIRC Linux supports each individual EA being 64K, so
they could be large.
>> So maybe there
>> could be a separate rdiff-backup-data/extended-attributes tree with
>> the same structure as the mirror directory, but the files contain the
>> extended attributes instead of the regular data.
I like that idea.
>> file could be similar to the format of the mirror_metadata file now.
Linux EAs are simple name value pairs, where the value can be binary.
Does that make sense with your current format?
>> Also <basename>.<time>.diff and <basename>.<time>.snapshot files could
>> be written to compress differences in the same way they do now for
>> regular data.
That makes sense.
>> Or maybe I should stick all the EA information in one huge file and
>> gzip it. Anyone see why one would be better than the other?
I can see that growing to hundreds of megs or more. Wouldn't it be slow to
have to update that large a file due to a small EA change.
You will definitely be getting lots of small changes.
For instance, I use xfsdump to backup my samba shares currently. xfsdump
accepts a dump-level as an arg.
For every file it backs up, it modifies a dump-level EA. So if I were to do:
rdiff-backup --record-eas ...
xfsdump ...
rdiff-backup --record-eas ...
You could have thousands (tens of thousands, hundreds of thousands) of EA
changes, but no data changes.
>> As Greg said, we can add more ACL support later. However, we don't
>> want to make any mistakes now that make future work harder. Any
>> comments on this plan?
>> --
>> Ben Escoto
Greg
--
Greg Freemyer
- [rdiff-backup-users] ACLs/EAs (who is the audience?), Ben Escoto, 2003/03/02
- RE: [rdiff-backup-users] ACLs/EAs (who is the audience?), Spicer, Kevin, 2003/03/02
- RE: [rdiff-backup-users] ACLs/EAs (who is the audience?), Spicer, Kevin, 2003/03/02
- re: [rdiff-backup-users] ACLs/EAs (who is the audience?), Greg Freemyer, 2003/03/03
- re[2]: [rdiff-backup-users] ACLs/EAs (who is the audience?), Greg Freemyer, 2003/03/03
- re[2]: [rdiff-backup-users] ACLs/EAs (who is the audience?),
Greg Freemyer <=