Two more replication fixes

Jeff Darcy jdarcy at redhat.com
Thu Oct 21 13:11:07 UTC 2010


On 10/21/2010 02:37 AM, Jim Meyering wrote:
> Jeff Darcy wrote:
>> [PATCH 2/3] Add X-redhat-role header when replicating to ourselves.
>> [PATCH 3/3] Add O_TRUNC in case new file is shorter than what's there.
> 
> Thanks!
> 
> What problem does 2/3 correct?

When a downstream iwhd gets a PUT without that header, it rejects it
(PUTs should be done upstream unless/until the "proxy writes upstream"
task is done).

The way we know we're downstream is probably not what it should be,
though.  Right now it's based on master_host being non-null, but even I
forget to add the -m sometimes and find myself surprised by the results.
 I noticed it this time because the decision of whether to use
meta_did_put (nuking previous locations) or meta_got_copy (adding to
them) is based on the same thing.  Thus, after replication the
downstream iwhd called meta_did_put and a subsequent GET at upstream
would fail.  Then I added it and saw the leak.  (Yes, before anyone else
feels a need to mention it, we need tests for that too.)  The following
approach would probably be more robust:

* all iwhds use the same config file

* non-root entries have an "upstream" attribute (possibly a list)

* the command line specifies only a name for which config entry to use

That should do away with the -m argument and ensure that mistakes such
as I describe above cannot occur.  Similarly, I've considered putting
the metadata-DB stuff in the config/provider list (e.g. with type "db")
so that we can get rid of -d as well.  What do you guys think?

BTW, we'd probably have to ensure that graph formed by "upstream" links
is loop-free.  It's a good thing I happen to think graph theory is fun.

> I suppose you have new tests (or at least outlines)
> for these?

You suppose correctly.  As you can see, I finished the changes somewhat
late in the day and didn't know whether I'd be able to get back to them
in the evening.  Hoarding patches didn't seem like the right thing to
do, so I posted them for review and set test development as my task for
this morning.

> The above will always fail if an existing file is somehow unwritable.
> To that end, I think we should be unlinking the file first,
> and then creating with the addition of O_EXCL.

OK.

> Mostly unrelated, shouldn't we prefer 0660 or 0600, just in case
> this is ever run with a permissive umask?  There is rarely any
> reason to make such files world-accessible.

That's why umask exists in the first place.  I don't know why anyone
would want these files to be world-accessible, but if they do I think
they should be able to set umask to an appropriate value and not have
their decision effectively overruled by our code.  If you like, we can
check umask on startup and print out a suitable warning if we deem it
too liberal.


More information about the iwhd-devel mailing list