linux-kernel - Re: Checksumming blocks? [was Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <44D28E4B.20605@elegant-software.com>
Date:	Thu, 03 Aug 2006 20:01:15 -0400
From:	Russell Leighton <russ@...gant-software.com>
To:	Matthias Andree <matthias.andree@....de>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Checksumming blocks? [was Re: the " 'official' point of view"
 expressed by kernelnewbies.org regarding reiser4 inclusion]

Thx, for a db this seems natural...

I am very curious about ZFS as I think we will seem more protection in 
the FS layer as disks get larger...
If I have a very old file I am now half way throught reading and ZFS 
finds a bad block, I assume I would
get some kind of read() error...but then what? Does anyone know if there 
are tools with ZFS to inspect the file?

Matthias Andree wrote:

>(I've stripped the Cc: list down to the bones.
>No need to shout side topics from the rooftops.)
>
>On Thu, 03 Aug 2006, Russell Leighton wrote:
>
>  
>
>>If the software (filesystem like ZFS or database like Berkeley DB)  
>>finds a mismatch for a checksum on a block read, then what?
>>    
>>
>
>(Note that this assumes a Berkeley DB in transactional mode.) Complain,
>demand recovery, set the panic flag (refusing further transactions
>except close and open for recovery).
>
>  
>
>>Is there a recovery mechanism, or do you just be happy you know there is 
>>a problem (and go to backup)?
>>    
>>
>
>Recoverability depends on log retention policy (set by the user or
>administrator) and how recently the block was written. There is a
>recovery mechanism.
>
>For applications that don't need their own recovery methods (few do),
>db_recover can do the job.
>
>In typical cases of power loss or kernel panic during write, the broken
>page will probably either be in the log so it can be restored (recover
>towards commit), or, if the commit hadn't completed but pages had been
>written due to cache conflicts, the database will be rolled back to the
>state before the interrupted transaction, effectively aborting the
>transaction.
>
>The details are in the Berkeley DB documentation, which please see.
>
>  
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/