[Planetlab-devel] identifying source of corrupt filesystems on pl

[Thierry Parmentelat]

I've manually created tag 13 or bootmanager from tag 12 with this  
single line change
That will ship with rc14 that is under way, should be out today I hope

For the other pending changes, since they've been in the way for a  
while, I'd suggest that we somehow make the choice between ext2 and  
ext3 more central; any dirty way could do, like e.g. define a global  
in BM that reads 'ext3' and that can be easily changed manually for  
when we'll be ready to test ext2.
Not sure if that's the right way, but having these entirely untested  
changes in the trunk for too long is IMHO a bit painful, so any other  
workaround would be welcome

-- thierry

On Oct 21, 2009, at 11:48 PM, Stephen Soltesz wrote:

>
> On Oct 21, 2009, at 5:41 PM, Marc Fiuczynski wrote:
>
>> Hi Stephen,
>>
>> On Oct 21, 2009, at 1:55 PM, Stephen Soltesz wrote:
>>> I'm sure that there were some safe fsck checks that were falsely  
>>> identified as corrupt fs.  It was not all of them.
>>
>> Good to know.  I agree that there are likely a number of truly  
>> corrupt file systems, likely due to having bad disks.
>
> I don't think it is related to the hardware being bad.
>
>>> I think the thing to do would be to deploy the fix to BM that  
>>> excludes the safe-fsck check and only fails when there is true fs  
>>> corruption.  Then we could follow up and identify how often real  
>>> corruption is occurring now. What do you think of that strategy?
>>
>> I think this is the right strategy.  How do we get to that point  
>> quickly?  Are the BM fixes only in trunk? Or do we have some that  
>> are tagged?  I don't want to use the trunk version of BM yet, as I  
>> have modified it already to switch to using ext2 vs. ext3.
>
> Apply patch r15328 to the deployed BM.  It's a single line.
>
> Best,
> Stephen
>
> _______________________________________________
> Devel mailing list
> Devel at lists.planet-lab.org
> https://lists.planet-lab.org/mailman/listinfo/devel