Re: Suggestion

Well, right at this instant, I don't mind so much about the performance. The disk
is considerably faster than the rate that we can draw internet data. At least an
order of magnitude or two.

I've just patched store.c and unlinkd.c to handle storing the information as
extra data on my test-box. I've not looked deeply enough at the file/disk model
to confidently prepend the necessary data into the cache-file itself. I may end
up doing that before the day is out.

D

David Luyer wrote:

> > Having just lost the contents of my cache (well, the swaplog, which
> > renders the contents of the cache effectively useless), I got to
> > thinking. What if the appropriate line of the swaplog was written with
> > each object in the cache? Either prepended as the first line (hardest
> > option) or written as a dot-file (.nnnnn contains the swaplog info for
> > object nnnnn. A much simpler solution). That way, even if your swaplog
> > was completely trashed (as mine was) the cache_dirs would still contain
> > enough information for a simple script to rebuild it.
>
> The dot-file - very bad idea. Kills dcache/inopde cache performance and so
> on by having twice the number of files per directory.
>
> As for the first line, people have suggested this, especially when using
> something like an SHA or MD5 store key - then when the object is opened
> on disk the first line acts as a check of the object info, as well as meaning
> the cache can be rebuilt from files in a restructuring or in loss of swaplog.
>
> It would probably have a near-zero disk space cost since it would be included
> in existing blocks mostly and there's no extra open() or significant extra
> disk IO volume associated with it.
>
> As for why it's not implemented - I guess nobody likes the idea enough to
> implement it, or people see some problem which I can't see...
>
> David.

--
Note to evil sorcerers and mad scientists: don't ever, ever summon powerful
demons or rip holes in the fabric of space and time. It's never a good idea.
ICQ UIN: 3225440