rdiff-backup-users
[Top][All Lists]
Advanced

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

Re: [rdiff-backup-users] Resource Forks and metadata file


From: Daniel Hazelbaker
Subject: Re: [rdiff-backup-users] Resource Forks and metadata file
Date: Fri, 28 Nov 2003 19:50:53 -0800
User-agent: Microsoft-Entourage/10.1.4.030702.0

> Hmm, so the resource fork data is 99%+ of the total?  When you added the
> resource fork support I assumed that not many files would have resource
> forks, and that they would be pretty small.

Maybe some old OS 9 format files are floating around causing most of the
headaches.  (OS X apps rarely use resource forks anymore).  It seems odd
that about 1.4% of the total data is resource fork data.

They should be fairly small, but bear in mind it IS 250GB of data.  And
actually come to think of it it is actually only 1.2GB which is only one
half a percent.  Since the fork data is stored ascii, each byte now takes up
2 bytes... It still seems like a lot but we'll see if I can figure out
exactly how much and where.

> Extrapolating, you have about 3GB of resource forks, does that sound
> right?  Maybe then we need a separate [...]

See above.  If we came up with some kind of separate store that was
"indexable", either by file offset or as a separate tree that would
definitely make it faster as it would not have to load the RF data until it
needed it.  Before we do anything though I'll see if I can come up with a
way to use find or something to traverse the FS and give me a list of all RF
data and sizes that I can sort... Maybe I can come up with a shell script
that will traverse the hierarchy and give me a separate tree of just the
resource fork data (as you were suggesting rdiff do) so I can run a du and
see where the data is.

I will see what I can come up with before I start hacking around the code,
just to be sure there is not some left over ahh, garbage :), lying around
wasting space. If I do get that working I'll run it on both the data drive
and the system drive for comparison too.

> By "current beta version" do you mean 0.13.3 or CVS?  There is a fix in
> CVS over 0.13.3 for filename quoting, which (as you noticed) was broken
> when running remotely.  I don't know if it fixes the other fs_abilities
> options.

Yes, 0.13.3.  Sorry, could not remember exactly which version it was, knew
it was a 0.13.x series.  If the CVS is stable (heh, well relatively
speaking, compilable anyway) I'll pull a copy of it down and use it instead.

> Ben Escoto

Daniel





reply via email to

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