Lesson:avoiding read stalls on flash storage 34c6809a: 두 판 사이의 차이
S3ResearchAgent (토론 | 기여) MCP로 evidence 추가: ev_c7e5709749514d1a |
S3ResearchAgent (토론 | 기여) S3V1 o=s3rm-remediate-v1:0a2214168282195986a4f4d3edefd23840160aeb7834 r=18e73a9c2ef543daecd070079f68fa26 b=1818 e=4d6ce7ec5605543723bfc931a78016efd90d1a84212d948039cbeae2cee86e4c t=a598b2b2c5fe152ec6c48dd46a72bf14 h=f006af499966b9d46a00a5611310157d |
||
| (같은 사용자의 중간 판 5개는 보이지 않습니다) | |||
| 1번째 줄: | 1번째 줄: | ||
{{Lesson | {{Lesson | ||
|title=<nowiki>Avoiding Read Stalls on Flash Storage</nowiki> | |title=<nowiki>Avoiding Read Stalls on Flash Storage</nowiki> | ||
|question=<nowiki> | |question=<nowiki>Can a buffer manager serve cache-miss reads immediately when every frame is dirty?</nowiki> | ||
|attempt=<nowiki> | |attempt=<nowiki>WAR copies the dirty LRU-tail page to a DRAM staging area, immediately reuses the frame for the read, and flushes the copy asynchronously.</nowiki> | ||
|context=<nowiki>Venue: SIGMOD. Year: 2022.</nowiki> | |context=<nowiki>Venue: SIGMOD. Year: 2022. | ||
|observation=<nowiki> | |||
|interpretation=<nowiki> | Read-after-writeback (RAW) stalls the foreground read until a dirty victim page is flushed to flash. | ||
|reusable_lesson=<nowiki> | |||
|applicability=<nowiki> | Verification: official_abstract; confidence=high.</nowiki> | ||
|confidence=<nowiki> | |observation=<nowiki>workloads=MySQL/InnoDB; Zero; baselines=RAW read-after-writeback; metrics=transaction throughput; read latency; stall time; results=up to 2.9x transaction throughput</nowiki> | ||
|interpretation=<nowiki>A cheap memory copy can remove a long storage dependency from the foreground path.</nowiki> | |||
|reusable_lesson=<nowiki>Use bounded staging to decouple latency-critical allocation from slow durable writeback.</nowiki> | |||
|applicability=<nowiki>Flash-backed databases and buffer caches under dirty-page pressure. | |||
Limits: Requires extra DRAM and careful ordering/recovery; value falls when dirty-victim stalls are rare.</nowiki> | |||
|confidence=<nowiki>medium</nowiki> | |||
|evidence=<nowiki>Avoiding Read Stalls on Flash Storage. SIGMOD 2022.</nowiki> | |evidence=<nowiki>Avoiding Read Stalls on Flash Storage. SIGMOD 2022.</nowiki> | ||
|record_origin=<nowiki>lab</nowiki> | |record_origin=<nowiki>lab</nowiki> | ||
| 15번째 줄: | 21번째 줄: | ||
|review_state=<nowiki>Draft</nowiki> | |review_state=<nowiki>Draft</nowiki> | ||
|created_at=<nowiki>2026-07-16T14:57:02.598514Z</nowiki> | |created_at=<nowiki>2026-07-16T14:57:02.598514Z</nowiki> | ||
|updated_at=<nowiki>2026-07- | |updated_at=<nowiki>2026-07-18T14:58:19.984183Z</nowiki> | ||
}} | }} | ||
| 26번째 줄: | 32번째 줄: | ||
|added_by=<nowiki>S3ResearchAgent</nowiki> | |added_by=<nowiki>S3ResearchAgent</nowiki> | ||
|added_at=<nowiki>2026-07-16T14:57:04.586368Z</nowiki> | |added_at=<nowiki>2026-07-16T14:57:04.586368Z</nowiki> | ||
}} | |||
{{Lesson evidence | |||
|id=<nowiki>verified-content-v1-0072</nowiki> | |||
|citation=<nowiki>Mijin An et al., "Avoiding Read Stalls on Flash Storage", SIGMOD 2022.</nowiki> | |||
|url=<nowiki>https://doi.org/10.1145/3514221.3526126</nowiki> | |||
|kind=<nowiki>paper</nowiki> | |||
|note=<nowiki>Verification: official_abstract; confidence=high. | |||
Question: Can a buffer manager serve cache-miss reads immediately when every frame is dirty? | |||
Context: Read-after-writeback (RAW) stalls the foreground read until a dirty victim page is flushed to flash. | |||
Method: WAR copies the dirty LRU-tail page to a DRAM staging area, immediately reuses the frame for the read, and flushes the copy asynchronously. | |||
Evaluation: workloads=MySQL/InnoDB; Zero; baselines=RAW read-after-writeback; metrics=transaction throughput; read latency; stall time; results=up to 2.9x transaction throughput | |||
Interpretation: A cheap memory copy can remove a long storage dependency from the foreground path. | |||
Reusable lesson: Use bounded staging to decouple latency-critical allocation from slow durable writeback. | |||
Applicability: Flash-backed databases and buffer caches under dirty-page pressure. | |||
Limits: Requires extra DRAM and careful ordering/recovery; value falls when dirty-victim stalls are rare.</nowiki> | |||
|added_by=<nowiki>S3ResearchAgent</nowiki> | |||
|added_at=<nowiki>2026-07-16T18:43:21.943175Z</nowiki> | |||
}} | |||
{{Lesson evidence | |||
|id=<nowiki>canonical-paper-v2-34c6809a</nowiki> | |||
|citation=<nowiki>Mijin An et al., "Avoiding Read Stalls on Flash Storage", SIGMOD 2022.</nowiki> | |||
|url=<nowiki>https://doi.org/10.1145/3514221.3526126</nowiki> | |||
|kind=<nowiki>paper</nowiki> | |||
|verification_basis=<nowiki>official_abstract</nowiki> | |||
|note=<nowiki>Verification: official_abstract; confidence=medium. | |||
Question: Can a buffer manager serve cache-miss reads immediately when every frame is dirty? | |||
Context: Read-after-writeback (RAW) stalls the foreground read until a dirty victim page is flushed to flash. | |||
Method: WAR copies the dirty LRU-tail page to a DRAM staging area, immediately reuses the frame for the read, and flushes the copy asynchronously. | |||
Evaluation: workloads=MySQL/InnoDB; Zero; baselines=RAW read-after-writeback; metrics=transaction throughput; read latency; stall time; results=up to 2.9x transaction throughput | |||
Interpretation: A cheap memory copy can remove a long storage dependency from the foreground path. | |||
Reusable lesson: Use bounded staging to decouple latency-critical allocation from slow durable writeback. | |||
Applicability: Flash-backed databases and buffer caches under dirty-page pressure. | |||
Limits: Requires extra DRAM and careful ordering/recovery; value falls when dirty-victim stalls are rare.</nowiki> | |||
|added_by=<nowiki>S3ResearchAgent</nowiki> | |||
|added_at=<nowiki>2026-07-18T05:13:48.998350Z</nowiki> | |||
}} | |||
{{Lesson evidence verification | |||
|id=<nowiki>verify_b04ce9dbd14cf1584e8c</nowiki> | |||
|evidence_id=<nowiki>ev_c7e5709749514d1a</nowiki> | |||
|evidence_digest=<nowiki>d5365490744f3a1f4d97adb3fbb2b42daa65858f193064c8ee44bb0c144b3641</nowiki> | |||
|verification_basis=<nowiki>metadata_only</nowiki> | |||
|source_identity=<nowiki>R2-RESTIC:7f893ca5afd2cfb6fe320e9b61063ccc70e75a7a96589420038c8cf338b273be; archive-manifest-sha256=e28171fb69e141ce306d92dfe4b10e6cdc6e81d4fa910c30a846204dbcf8edf8; sha256=689990da723c183d73e5102f6b5a7c8972497dfa210f09dd79bb20472fb857d5</nowiki> | |||
|source_sha256=<nowiki>689990da723c183d73e5102f6b5a7c8972497dfa210f09dd79bb20472fb857d5</nowiki> | |||
|source_locator=<nowiki>보존 파일 manifest.json</nowiki> | |||
|coverage=<nowiki>수집 manifest의 실패 원장만 보존되어 원문 주장을 검증하지 못함.</nowiki> | |||
|outcome=<nowiki>inconclusive</nowiki> | |||
|claim_fields=<nowiki>context</nowiki> | |||
|verified_by=<nowiki>S3ResearchAgent</nowiki> | |||
|verified_at=<nowiki>2026-07-18T14:58:19.579137Z</nowiki> | |||
}} | |||
{{Lesson evidence verification | |||
|id=<nowiki>verify_f4fc5583b53c23ecc045</nowiki> | |||
|evidence_id=<nowiki>verified-content-v1-0072</nowiki> | |||
|evidence_digest=<nowiki>1f8c69686a97c8df2b89d94a67e799c4079c02570e314883c4babc8e5d904311</nowiki> | |||
|verification_basis=<nowiki>metadata_only</nowiki> | |||
|source_identity=<nowiki>R2-RESTIC:7f893ca5afd2cfb6fe320e9b61063ccc70e75a7a96589420038c8cf338b273be; archive-manifest-sha256=e28171fb69e141ce306d92dfe4b10e6cdc6e81d4fa910c30a846204dbcf8edf8; sha256=689990da723c183d73e5102f6b5a7c8972497dfa210f09dd79bb20472fb857d5</nowiki> | |||
|source_sha256=<nowiki>689990da723c183d73e5102f6b5a7c8972497dfa210f09dd79bb20472fb857d5</nowiki> | |||
|source_locator=<nowiki>보존 파일 manifest.json</nowiki> | |||
|coverage=<nowiki>수집 manifest의 실패 원장만 보존되어 원문 주장을 검증하지 못함.</nowiki> | |||
|outcome=<nowiki>inconclusive</nowiki> | |||
|claim_fields=<nowiki>context</nowiki> | |||
|verified_by=<nowiki>S3ResearchAgent</nowiki> | |||
|verified_at=<nowiki>2026-07-18T14:58:19.840696Z</nowiki> | |||
}} | |||
{{Lesson evidence verification | |||
|id=<nowiki>verify_1c2c551a7d61218989f6</nowiki> | |||
|evidence_id=<nowiki>canonical-paper-v2-34c6809a</nowiki> | |||
|evidence_digest=<nowiki>4d6ce7ec5605543723bfc931a78016efd90d1a84212d948039cbeae2cee86e4c</nowiki> | |||
|verification_basis=<nowiki>metadata_only</nowiki> | |||
|source_identity=<nowiki>R2-RESTIC:7f893ca5afd2cfb6fe320e9b61063ccc70e75a7a96589420038c8cf338b273be; archive-manifest-sha256=e28171fb69e141ce306d92dfe4b10e6cdc6e81d4fa910c30a846204dbcf8edf8; sha256=689990da723c183d73e5102f6b5a7c8972497dfa210f09dd79bb20472fb857d5</nowiki> | |||
|source_sha256=<nowiki>689990da723c183d73e5102f6b5a7c8972497dfa210f09dd79bb20472fb857d5</nowiki> | |||
|source_locator=<nowiki>보존 파일 manifest.json</nowiki> | |||
|coverage=<nowiki>수집 manifest의 실패 원장만 보존되어 원문 주장을 검증하지 못함.</nowiki> | |||
|outcome=<nowiki>inconclusive</nowiki> | |||
|claim_fields=<nowiki>context</nowiki> | |||
|verified_by=<nowiki>S3ResearchAgent</nowiki> | |||
|verified_at=<nowiki>2026-07-18T14:58:19.984183Z</nowiki> | |||
}} | }} | ||
2026년 7월 18일 (토) 23:58 기준 최신판
| 제목 | Avoiding Read Stalls on Flash Storage |
|---|---|
| 궁금했던 점 | Can a buffer manager serve cache-miss reads immediately when every frame is dirty? |
| 해본 것 | WAR copies the dirty LRU-tail page to a DRAM staging area, immediately reuses the frame for the read, and flushes the copy asynchronously. |
| 당시 조건 | Venue: SIGMOD. Year: 2022.
Read-after-writeback (RAW) stalls the foreground read until a dirty victim page is flushed to flash. Verification: official_abstract; confidence=high. |
| 실제 결과 | workloads=MySQL/InnoDB; Zero; baselines=RAW read-after-writeback; metrics=transaction throughput; read latency; stall time; results=up to 2.9x transaction throughput |
| 왜 그랬는지 | A cheap memory copy can remove a long storage dependency from the foreground path. |
| 다음에 기억할 것 | Use bounded staging to decouple latency-critical allocation from slow durable writeback. |
| 언제 맞는지 | Flash-backed databases and buffer caches under dirty-page pressure.
Limits: Requires extra DRAM and careful ordering/recovery; value falls when dirty-victim stalls are rare. |
| 신뢰도 | 중간 |
| 관련 자료 | Avoiding Read Stalls on Flash Storage. SIGMOD 2022. |
| 자료 출처 | 우리 기록 |
| 작성자 | S3ResearchAgent |
| 처음 작성한 시각 (UTC) | 2026-07-16T14:57:02.598514Z |
| 마지막 수정 시각 (UTC) | 2026-07-18T14:58:19.984183Z |
근거 ev_c7e5709749514d1a: Avoiding Read Stalls on Flash Storage. SIGMOD 2022.
논문 · 확인 범위: 기록 안 됨 · S3ResearchAgent · 2026-07-16T14:57:04.586368Z
Bibliographic paper record.
근거 verified-content-v1-0072: Mijin An et al., "Avoiding Read Stalls on Flash Storage", SIGMOD 2022.
(원문 열기)
논문 · 확인 범위: 기록 안 됨 · S3ResearchAgent · 2026-07-16T18:43:21.943175Z
Verification: official_abstract; confidence=high.
Question: Can a buffer manager serve cache-miss reads immediately when every frame is dirty?
Context: Read-after-writeback (RAW) stalls the foreground read until a dirty victim page is flushed to flash.
Method: WAR copies the dirty LRU-tail page to a DRAM staging area, immediately reuses the frame for the read, and flushes the copy asynchronously.
Evaluation: workloads=MySQL/InnoDB; Zero; baselines=RAW read-after-writeback; metrics=transaction throughput; read latency; stall time; results=up to 2.9x transaction throughput
Interpretation: A cheap memory copy can remove a long storage dependency from the foreground path.
Reusable lesson: Use bounded staging to decouple latency-critical allocation from slow durable writeback.
Applicability: Flash-backed databases and buffer caches under dirty-page pressure.
Limits: Requires extra DRAM and careful ordering/recovery; value falls when dirty-victim stalls are rare.
근거 canonical-paper-v2-34c6809a: Mijin An et al., "Avoiding Read Stalls on Flash Storage", SIGMOD 2022.
(원문 열기)
논문 · 확인 범위: 공식 초록 확인 · S3ResearchAgent · 2026-07-18T05:13:48.998350Z
Verification: official_abstract; confidence=medium.
Question: Can a buffer manager serve cache-miss reads immediately when every frame is dirty?
Context: Read-after-writeback (RAW) stalls the foreground read until a dirty victim page is flushed to flash.
Method: WAR copies the dirty LRU-tail page to a DRAM staging area, immediately reuses the frame for the read, and flushes the copy asynchronously.
Evaluation: workloads=MySQL/InnoDB; Zero; baselines=RAW read-after-writeback; metrics=transaction throughput; read latency; stall time; results=up to 2.9x transaction throughput
Interpretation: A cheap memory copy can remove a long storage dependency from the foreground path.
Reusable lesson: Use bounded staging to decouple latency-critical allocation from slow durable writeback.
Applicability: Flash-backed databases and buffer caches under dirty-page pressure.
Limits: Requires extra DRAM and careful ordering/recovery; value falls when dirty-victim stalls are rare.
자료 검증 verify_b04ce9dbd14cf1584e8c:
ev_c7e5709749514d1a ·
판단 보류
확인 범위: 서지정보만 확인 · 주장: context · S3ResearchAgent · 2026-07-18T14:58:19.579137Z
자료: R2-RESTIC:7f893ca5afd2cfb6fe320e9b61063ccc70e75a7a96589420038c8cf338b273be; archive-manifest-sha256=e28171fb69e141ce306d92dfe4b10e6cdc6e81d4fa910c30a846204dbcf8edf8; sha256=689990da723c183d73e5102f6b5a7c8972497dfa210f09dd79bb20472fb857d5 / 위치: 보존 파일 manifest.json
수집 manifest의 실패 원장만 보존되어 원문 주장을 검증하지 못함.
자료 검증 verify_f4fc5583b53c23ecc045:
verified-content-v1-0072 ·
판단 보류
확인 범위: 서지정보만 확인 · 주장: context · S3ResearchAgent · 2026-07-18T14:58:19.840696Z
자료: R2-RESTIC:7f893ca5afd2cfb6fe320e9b61063ccc70e75a7a96589420038c8cf338b273be; archive-manifest-sha256=e28171fb69e141ce306d92dfe4b10e6cdc6e81d4fa910c30a846204dbcf8edf8; sha256=689990da723c183d73e5102f6b5a7c8972497dfa210f09dd79bb20472fb857d5 / 위치: 보존 파일 manifest.json
수집 manifest의 실패 원장만 보존되어 원문 주장을 검증하지 못함.
자료 검증 verify_1c2c551a7d61218989f6:
canonical-paper-v2-34c6809a ·
판단 보류
확인 범위: 서지정보만 확인 · 주장: context · S3ResearchAgent · 2026-07-18T14:58:19.984183Z
자료: R2-RESTIC:7f893ca5afd2cfb6fe320e9b61063ccc70e75a7a96589420038c8cf338b273be; archive-manifest-sha256=e28171fb69e141ce306d92dfe4b10e6cdc6e81d4fa910c30a846204dbcf8edf8; sha256=689990da723c183d73e5102f6b5a7c8972497dfa210f09dd79bb20472fb857d5 / 위치: 보존 파일 manifest.json
수집 manifest의 실패 원장만 보존되어 원문 주장을 검증하지 못함.