maria-discuss team mailing list archive

[Reindl Harald <h.reindl@xxxxxxxxxxxxx>]

Am 08.12.22 um 22:32 schrieb Gordan Bobic:
> On Thu, Dec 8, 2022 at 10:59 PM Reindl Harald <h.reindl@xxxxxxxxxxxxx> wrote:
> > > What is the net benefit of detecting said error? The way I see it, the
> > > options are:
> > > 1) MariaDB detects and error, crashes out
> > > 2) MariaDB doesn't detect an error, ingests garbage, crashes out
> >
> > silent data corruption
>
> At what layer? If at anything below, up to and including the file
> system level, ZFS will detect and correct it for you.
> MariaDB can at best only detect it for you. So catching it at a lower
> level wins.
>
> > > The only way an error will creep in without the error checking FS
> > > spotting it is:
> > > 1) manually corrupting the block by writing garbage over it
> > > 2) MariaDB generated a duff block and wrote it out
> > > 3) Some other hardware failure corrupted the block in MariaDB memory,
> > > just before writing it to the file system
> > >
> > > If any of the latter set happens, the data is toast anyway.
> > > If the former set happens, the data is toast anyway.
> >
> > silent data corruption
>
> At what layer? 

on the database layer itself

> If at anything below, up to and including the file
> system level, ZFS will detect and correct it for you

are you really that dumb that you don't understand that the filesystem 
don't matter here?

> MariaDB can at best only detect it for you. So catching it at a lower
> level wins.

that layer can't do anything about databse internals

> > moron the files are fine from the viewpoint of the filessystem
>
> At what layer? 

the database layer moron

> If at anything below, up to and including the file
> system level, ZFS will detect and correct it for you

different layer moron

> > moron the files are fine from the viewpoint of the filessystem
> >
> > > > AGAIN: THE FILESYSTEM CAN'T DO ANYTHING BECAUSE IT'S NOT AFFECTED
> > >
> > > So your argument is that the page checksum is there to tell you that
> > > your data is corrupted because of either:
> > > 1) data was corrupted by the database itself, or
> > > 2) a superuser overwriting the block on the disk
> >
> > and it's impressive how long it takes until you mororn understand such
> > basics
>
> And in that case what exactly will the ckecksum do for you?

let you notice you have a problem and need backups

> What do you gain from it? The error message that the block is
> corrupted just before the database crashes?

know that your data are damaged instead growing silent corruption

> 2) InnoDB has no checksums. Database steps on the duff block.
> 2.1) Database crashes during a query. You get the query and tables
> accessed during a stack trace.
> You run a check table and it finds a corrupted table.
> You restore it from backup

and without that over time you have no backup without the problem and 
even if you have one nobody wants a backup from months ago not containg 
any recent data

> 2.2) Database doesn't crash because the damage merely corrupts a
> single value but the record structure remains sound.
>
> So it is that 2.2) point where the InnoDB checksum gives you anything

moron it don't matter if you find it useful - the whole point was that 
you pretended the filesystem can do the same with it's checksums which 
is nonsense