Bug 413021
| Summary: | Journal recovery fails when flush did not occur and records don't end on sblk boundary | ||
|---|---|---|---|
| Product: | Red Hat Enterprise MRG | Reporter: | Kim van der Riet <kim.vdriet> |
| Component: | qpid-cpp | Assignee: | Kim van der Riet <kim.vdriet> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Kim van der Riet <kim.vdriet> |
| Severity: | urgent | Docs Contact: | |
| Priority: | urgent | ||
| Version: | beta | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | --- | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Kim van der Riet
2007-12-05 21:57:12 UTC
Currently recovery does not use O_DIRECT (since performance is not an issue during this process), and this relieves the sblk boundary restriction for reads and writes. This should make it easier to add the required fill records in this case. The strategy to fix this is as follows: Step 1: Check the record tail of each record during the analysis phase. A bad tail indicates either a corrupted record header or an incomplete record write. If a bad tail is found in any file *other* than the last logical file, then this is a fatal error (and should never happen). However, if this occurs in the last logical file, then this indicates an incomplete write at the file overwrite boundary. In this context, the first logical file is the last complete file to not be overwritten (i.e. the oldest complete file) and thus the first to be read during recovery, while the last logical file is the most recent file to be overwritten, and possibly contains an overwrite boundary. It is the last file to be read during recovery. Step 2: If the record that has been truncated starts on a dblock boundary that is not also an sblock boundary, then filler records need to be written to the file which will overwrite the truncated record. These will start at the record header, each consuming one dblock, until the next sblock boundary is reached. At this point, the journal is once again usable, as O_DIRECT reads and writes which must be sblock aligned, can again take place without interleaving bad or corrupted records. Presently, the sblock size is 512 bytes (although this can be set to any multiple of 512 bytes), and there are 4 dblocks per sblock - i.e. 128 bytes. RHM svn r1442 Cruisecontrol 64-bit build 337 Cruisecontrol 32-bit build 49 |