[Box Backup-dev] "setlimit 0 (...) back with vengeance (Was: Proposal (patch): bbstored HousekeepingStyle mod)

[Chris Wilson]

Hi Gary,

On Tue, 23 Jan 2007, G. wrote:

> I am not sure I follow... If this is (exclusively) a problem on the 
> client side, how come it has worked fine under i686/CentOS and suddenly 
> broke under AMD64/Ubuntu? My Win32 bbstored (your general tree) 
> executable was exactly the same in both cases.

Perhaps it's the volume of data backed up versus the hard limit? Seem my 
email to Martin, the client will stop backing up when it reaches soft 
limit + 1/3 of hard limit at the time of connection.

> No, we're lucky here, I actually implemented this stuff already (but 
> backed off from it), and it turns out to be a rather very simple patch. 
> Actually, running a different housekeeping style allows housekeeping to 
> calculate the number of out-of-date/deleted blocks precisely, and run 
> that exact number through the block removal code.
>
> However, even if we patch bbackupd, the question whether a (low) 
> soft-limit should have any effect whatsoever on >>new<< file upload 
> still remains...?

Yes, just patching bbstored and not bbackupd will not solve the problem 
you're seeing, and just patching bbackupd will (without any changes to 
bbstored). So I think that we should only patch bbackupd.

I think we should remove this check in bbackupd. I can't see the point of 
it, since we could easily start off below the threshold, and then have 
sufficient data to upload that we exceed the hard limit and throw an 
exception. Conversely, we might be over the threshold, but have very 
little data to upload, or even want to delete some data from the server.

Is there any circumstance in which this threshold is useful?

Cheers, Chris.
-- 
_____ __     _
\  __/ / ,__(_)_  | Chris Wilson <0000 at qwirx.com> - Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer |
\ _/_/_/_//_/___/ | We are GNU-free your mind-and your software |