[jira] [Commented] (CASSANDRA-9881) Rows with negative-sized keys can't be skipped by sstablescrub

["Sylvain Lebresne (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-9881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14725110#comment-14725110 ] 

Sylvain Lebresne commented on CASSANDRA-9881:
---------------------------------------------

bq. Is this still a problem post 8099?

I lack information to be certain but I have no reason to think 8099 helps here in any way.

In fact, my best guess as to why this could happen is that the file is broken in a way that throws while reading the partition key but this without making any progress on the data file (the file pointer isn't moved), and there is no available index file (it is either not present at all, or we're reached the end of it). For instance, maybe the data file has actually been read entirely (and hence the index file is EOF) but there is something wrong with the file system at the end of the file. In any case, if that happens, we'll fail reading the key, write the "row (unreadable key) is -1 bytes" (the negative size is a red herring, it's -1 only because there is no index key to use for the calculation of the size), and then start again (as we don't have an index entry, we won't seek to the new row but rather just start reading from the same place).

So it sounds like a scrub bug really and we should give up if we can't read the partition and have no index entry to skip it (which, for some reason, we don't do). The open question is what we do in that case: currently, when scrub gives up, it abort any writing and so doesn't "salvage the rest of the sstable". I suppose the assumption was that we can't log which keys we skip so we prefer not skipping any, but probably we want to revisit that.

> Rows with negative-sized keys can't be skipped by sstablescrub
> --------------------------------------------------------------
>
>                 Key: CASSANDRA-9881
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9881
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Brandon Williams
>            Assignee: Stefania
>            Priority: Minor
>             Fix For: 2.1.x
>
>
> It is possible to have corruption in such a way that scrub (on or offline) can't skip the row, so you end up in a loop where this just keeps repeating:
> {noformat}
> WARNING: Row starting at position 2087453 is unreadable; skipping to next 
> Reading row at 2087453 
> row (unreadable key) is -1 bytes
> {noformat}
> The workaround is to just delete the problem sstable since you were going to have to repair anyway, but it would still be nice to salvage the rest of the sstable.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)