David Glasser wrote:
> On Wed, Oct 22, 2008 at 7:30 PM, Hyrum K. Wright
> <hyrum_wright_at_mail.utexas.edu> wrote:
>> David Glasser wrote:
>>> On Wed, Oct 22, 2008 at 1:10 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>>>> David Glasser wrote:
>>>>> *nod*, reasonable. I'd still argue that (for FSFS) rep-sharing seems
>>>>> to be a net loss, though.
>>>> All the code to do rep-sharing should be wrapped up in FS-format-version
>>>> conditionals -- should we expose rep-sharing as an option (in the format
>>>> file) to the administrator and let him/her decide if the space savings is
>>>> worth it?
>>> Might be a good idea. Note that (unlike sharding) I think that the
>>> use of rep-sharing can be essentially turned on and off at will (as
>>> long as reuse numbers are always parsed), so I'd advocate for putting
>>> this in the new fsfs.conf rather than the format file. (Or y'all
>>> could decide that I made a false dichotomy between format options and
>>> configuration and ditch the fsfs.conf.)
>> rep-sharing can be turned on and off pretty much at will. The cache can be
>> blown away without any negative consequences, and the parser can be taught to
>> ignore the reuse numbers.
>
> Er, though is that true --- won't "ignoring the reuse numbers" break
> the rep key comparisons?
Hmm, yeah. Well, we've already bumped the fsfs format number, so the parser
doesn't have to ignore the reuse numbers. If rep sharing is turned off, the
node rev will already be unique, so the reuse number becomes redundant.
rep-sharing could be turned on again later.
As for bdb, I'm not sure what the best way to enable/disable it would be, or
even what the performance gain would be. Mike, do you have any ideas?
I'm probably not explaining this very clearly, but on some ethereal level, I
feel that disabling rep-sharing (on a rep-sharing-aware filesystem) shouldn't be
a problem.
-Hyrum
Received on 2008-10-23 16:02:27 CEST