hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Baldeschwieler <eri...@yahoo-inc.com>
Subject Re: fsck with the move option
Date Tue, 02 May 2006 05:31:42 GMT
Why not go after the FS APIs so you can simply read the remaining  
good blocks?  Might it work already if you had a client that skipped  
a block if it found a missing one (via error/exception)?  Or create  
empty blocks...

On May 1, 2006, at 3:31 PM, Andrzej Bialecki wrote:

> Yoram Arnon wrote:
>> +1.
>> Files that are moved are inaccessible by normal means and there's  
>> little
>> reason to keep two copies of them around. A sys-admin could later  
>> either
>> remove them, or try to reassemble them and return them into place.  
>> Leaving
>> them in their original location just makes it harder to clean them  
>> up.
>>
>>
>
> Corrupted files are not left in their original location, if a -move  
> option is specified. Fsck does not produce two copies either. As  
> Hairong wrote, corrupted files are copied block by block to lost 
> +found, and then removed from their original location; at the same  
> time fsck tries to glue together consecutive blocks to minimize the  
> number of remaining parts.
>
> Yes, it is expensive. Perhaps we should add another option to - 
> move, namely -recover. -move would just move corrupted files to lost 
> +found using the namespace change, and -recover would try to  
> recover remaining parts.
>
> -- 
> Best regards,
> Andrzej Bialecki     <><
> ___. ___ ___ ___ _ _   __________________________________
> [__ || __|__/|__||\/|  Information Retrieval, Semantic Web
> ___|||__||  \|  ||  |  Embedded Unix, System Integration
> http://www.sigram.com  Contact: info at sigram dot com
>
>


Mime
View raw message