On Jan 19, 2013 1:16 AM, "Alasdair G Kergon" <<a href="mailto:agk@redhat.com">agk@redhat.com</a>> wrote: > > On Fri, Jan 18, 2013 at 11:43:34PM +0200, Kasatkin, Dmitry wrote: > > This patch I sent out has one missing feature what I have not pushed yet. > > In the case of non-matching blocks, it just zeros blocks and returns > > no error (zero-on-mismatch). > > Writing to the block replaces the hmac. > > It works quite nicely. mkfs and fsck is able to read and write/fix the > > filesystem. > > In normal environment, if fsck crashes, it might corrupt file system > > in the same way. > > zero-on-mismatch makes block device still accessible/fixable for fsck. > > I'm afraid I don't buy that. > > We can hardly call this "integrity" if it's designed to lose some of > your data when the machine crashes - and worse - it doesn't tell you > what you lost, but just gives you blocks of zeroes instead! > > I think a redesign is needed before this goes upstream. > > Alasdair > Do not look to it as integrity from reliability point of view. This might be wrong name for the target. The purpose is to provide integrity from security point of view. So modified blocks are not available. To prevent attacker to put arbitrary content. This is not to provide reliability. Default is to return error. But zero might be desirable. It works as needed for the purpose and data=journal works for this if reliability is required. - Dmitry