Re: Print physical file path when checksum check fails

Thanks Kyotaro,

On Wed, Feb 19, 2020 at 2:02 PM Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
wrote:

> At Wed, 19 Feb 2020 13:28:04 +0900, Michael Paquier <michael(at)paquier(dot)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