[Box Backup-dev] Re: [Box Backup] How to move boxbackup store to a larger disk

[Ben Summers]

Chris Wilson write:
>
>> On Fri, 12 Sep 2008, David H Kaufman wrote:
>>
>>> At the end of which I had a happy, larger EXT3 filesystem on new- 
>>> disk.
>>> But boxbackup doesn't like something I did - I ran:
>>>
>>> bbstoreaccounts check <id>
>>>
>>> and got a HEAP of these:
>>>
>>> File ID 61321 has different container ID, probably moved
>>> File ID 61a01 has different container ID, probably moved
>
> I could use a little help here if you have time. I'm not really sure  
> what
> the code in BackupStoreCheck is doing.
>
> BackupStoreCheck::CheckDirectories() loops over the stuff in mInfo  
> (where
> exactly does this come from?) which looks like a list of blocks,  
> each of
> which contains a list of block IDs and attributes. I think these are  
> the
> IDs of the directory entries in the directory blocks.
>
> Around lib/backupstore/BackupStoreCheck.cpp:634, it calls LookupID,  
> which
> looks like it's reading the same kind of data, but returning a
> pointer to an IDBlock called piBlock (not pblock) this time. We then
> check, on line 671, whether piBlock->mContainer[iIndex] != pblock- 
> >mID[e],
> and if so, and it's a file, we report the warning above.
>
> I don't yet follow the origins of these two data sources so I don't
> understand how they can be different. Obviously in this user's case  
> they
> are, and the warnings emitted by the code indicate that this is due  
> to a
> file being moved (presumably to a different container ID), and that  
> this
> is a "normal" thing.
>
> The code also "fixes" the entry, on line 687:
>
> 	piBlock->mContainer[iIndex] = pblock->mID[e];
>
> but it doesn't set isModified = true, so the "fixed" directory isn't  
> written
> back to the store.
>
> What's the reason for not setting isModified = true at this point and
> correcting the entry's container ID? Why isn't the container ID  
> changed
> when the file is moved, to keep the store consistent?


The container ID is set on the client side when the stored file is  
originally created. It's not used for anything except store  
reconstruction, so it seemed a bit of a waste of time to update it  
when files were moved. If it were to be changed, the server would have  
to do it, which given the restrictive RaidFile interface would require  
rewriting the file in it's entirety.

Maybe a reasonable solution is to simply remove that "warning"?

Ben