Thanks Kyotaro, On Wed, Feb 19, 2020 at 2:02 PM Kyotaro Horiguchi <horikyota....@gmail.com> wrote:
> At Wed, 19 Feb 2020 13:28:04 +0900, Michael Paquier <mich...@paquier.xyz> > wrote in > > On Wed, Feb 19, 2020 at 01:07:36PM +0900, Kyotaro Horiguchi wrote: > > > If we also verify checksum in md layer, callback is overkill since the > > > immediate caller consumes the event immediately. We can signal the > > > error by somehow returning a file tag. > > > > FWIW, I am wondering if there is any need for a change here and > > complicate more the code. If you know the block number, the page size > > and the segment file size you can immediately guess where is the > > damaged block. The first information is already part of the error > > I have had support requests related to broken block several times, and > (I think) most of *them* had hard time to locate the broken block or > even broken file. I don't think it is useles at all, but I'm not sure > it is worth the additional complexity. > > > damaged block. The first information is already part of the error > > message, and the two other ones are constants defined at > > compile-time. > > May you have misread the snippet? > > What Hubert proposed is: > > "invalid page in block %u of relation file %s; zeroing out page", > blkno, <filename> > > The second format in my messages just before is: > "invalid page in block %u in relation %u, file \"%s\"", > blockNum, smgr->smgr_rnode.node.relNode, smgrfname() > > All of them are not compile-time constant at all. > > I like your error message, the block number is relation level not file level. I 'll change the error message to "invalid page in block %u of relation %u, file %s" -- Thanks Hubert Zhang
