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: <20060803233503.GB25727@merlin.emma.line.org>
Date:	Fri, 4 Aug 2006 01:35:03 +0200
From:	Matthias Andree <matthias.andree@....de>
To:	Russell Leighton <russ@...gant-software.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Checksumming blocks? [was Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion]

(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.

-- 
Matthias Andree
-
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/