On 2019/1/23 上午1:47, David Sterba wrote: > On Fri, Jan 18, 2019 at 10:19:51AM +0800, Qu Wenruo wrote: >> Patchset can be fetched from github: >> https://github.com/adam900710/linux/tree/write_time_tree_checker >> Which is based on v5.0-rc1 tag. >> >> This patchset has the following two features: >> - Tree block validation output enhancement >> * Output validation failure timing (write time or read time) >> * Always output tree block level/key mismatch error message >> This part is already submitted and reviewed. >> >> - Write time tree block validation check >> To catch memory corruption either from hardware or kernel. >> Example output would be: >> >> BTRFS critical (device dm-3): corrupt leaf: root=2 block=1350630375424 slot=68, bad key order, prev (10510212874240 169 0) current (1714119868416 169 0) >> BTRFS error (device dm-3): write time tree block corruption detected >> BTRFS critical (device dm-3): corrupt leaf: root=2 block=1350630375424 slot=68, bad key order, prev (10510212874240 169 0) current (1714119868416 169 0) >> BTRFS error (device dm-3): write time tree block corruption detected > > Would it be possible to print this message only once? I think it's caused by DUP profile. I'll change to make it abort. > It's correct when > it's the last message after all the corruptions are detected as there > could be a lot of text that can scroll off the screen. The real reason > what happend would stay and give enough clue what happened. > >> BTRFS: error (device dm-3) in btrfs_commit_transaction:2220: errno=-5 IO failure (Error while writing out transaction) >> BTRFS info (device dm-3): forced readonly >> BTRFS warning (device dm-3): Skipping commit of aborted transaction. >> BTRFS: error (device dm-3) in cleanup_transaction:1839: errno=-5 IO failure >> BTRFS info (device dm-3): delayed_refs has NO entry > > That's not from your patch es but now that I see it, it's not for the > 'info' level, maybe 'debug' or not printed at all. > > The extra checks will cause some slowdown, do we have an estimate how > much? In theory it should be no slower than an extra csum run for tree blocks. Thanks, Qu
Attachment:
signature.asc
Description: OpenPGP digital signature
