On Tue, Mar 05, 2013 at 02:36:15PM -0600, Ben Myers wrote: > Hi Dave, > > On Mon, Feb 25, 2013 at 12:31:32PM +1100, Dave Chinner wrote: > > From: Christoph Hellwig <hch@xxxxxx> > > > > Use the reserved space in struct xfs_dqblk to store a UUID and a crc > > for the quota blocks. > > > > [dchinner@xxxxxxxxxx] Add a LSN field and update for current verifier > > infrastructure. > > > > Signed-off-by: Christoph Hellwig <hch@xxxxxx> > > Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx> > > Been over this and it looks fine. > > > @@ -897,6 +910,10 @@ xfs_qm_dqiter_bufs( > > if (error) > > break; > > > > + /* > > + * XXX(hch): need to figure out if it makes sense to validate > > + * the CRC here. > > + */ > > What's you're opinion on this? I did actually change the code to validate the CRC here via the call to xfs_trans_read_buf(.... &xfs_dquot_buf_ops) above. i.e. the read verifier will do CRC validation of the buffer. The comment is still relevant, however, because it's not exactly clear what the best approach to do here if we get a CRC failure. That would indicate some kind of corruption that we weren't expecting, and quite possibly a corruption that rewriting the dquot can't fix. So without knowing what kind of corruption is typical here, I don't know what the best approach to take here is. So effectively what I've done is add CRC validation so that we'll get people telling us about problems (because the quotacheck will abort and there will be a stack trace in the log). If it turns out that corrupted quota files is a common problem that quotacheck encounters we can gather the corpses, do post-mortem analysis of the failures and then revisit the code appropriately with that knowledge in hand. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
