mirror of
https://github.com/seaweedfs/seaweedfs.git
synced 2026-10-06 22:41:56 +02:00
* filer: keep a ranged read in random mode through its contiguous tail A far ReadAt on a fresh ReaderPattern left the sequential counter at -1, so the next buffer of the same ranged request landed on the frontier and flipped the verdict straight back to sequential — readChunkSliceAt then paid a whole-chunk fetch for the remainder of the range. Drop the counter to -ModeChangeLimit when random mode is entered so the verdict needs sustained sequential evidence to undo, matching the hysteresis an established sequential stream already gets. Generated with [Devin](https://devin.ai) Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com> * s3: pin small ranged GETs to range reads A ranged GET whose first read lands within SeqTolerance of offset 0 is judged sequential immediately, and even a far-starting range could flip back mid-request; either way readChunkSliceAt downloads each covered chunk in full, multiplying disk reads for small ranged reads (measured ~7x). Pin random mode for ranged requests no larger than SeqTolerance so all of the request's buffer reads stay range fetches. Larger ranges keep the dynamic pattern, where whole-chunk fetches amortize. Generated with [Devin](https://devin.ai) Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com> * filer: fetch only the part of a chunk the view covers Replaces the PinRandomMode size heuristic with a per-chunk coverage rule. ViewFromVisibleIntervals already clips chunk views to the request window, so a view that is not IsFullChunk() is one the request only partially needs; fetch it as a range regardless of the detected read pattern. This closes the holes a request-size pin left open: ranges larger than SeqTolerance no longer revert to whole-chunk downloads once their buffers look sequential, and ranges that fully cover a chunk keep the shared whole-chunk path instead of fetching 256KiB slices piecemeal. Prefetch (MaybeCache) skips clipped views so it cannot amplify a range read either. PinRandomMode is dropped: no caller needs it once coverage drives the fetch choice. Range fetches route through fetchChunkDataFn so tests observe them the same way as whole-chunk downloads. * filer: keep ciphered chunks on the whole-chunk path A range fetch cannot save bytes for a ciphered chunk: readEncryptedUrl always downloads and decrypts the whole blob before slicing. Sending partial views of ciphered chunks through fetchChunkRange would repeat the full download per buffer, so they keep the shared whole-chunk path where one download serves every buffer. Prefetch stays enabled for them for the same reason. * filer: keep compressed chunks on the whole-chunk path Like ciphered chunks, a range request on a compressed chunk makes the volume server read and decompress the whole needle, so range-per-buffer would repeat the full backend read for each 256KiB window. Route them through the shared whole-chunk path via ChunkView.CanRangeFetch. * filer: fall back to range fetch when a chunk exceeds the reader budget A ciphered or compressed chunk larger than readerCacheSizeMB can never be read through the whole-chunk path — the budget rejects the buffer — so its partial views must still range-fetch or the GET fails outright. --------- Co-authored-by: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>
70 lines
2.3 KiB
Go
70 lines
2.3 KiB
Go
package filer
|
|
|
|
import (
|
|
"sync/atomic"
|
|
)
|
|
|
|
type ReaderPattern struct {
|
|
isSequentialCounter int64
|
|
readFrontier int64 // highest (offset+size) observed across reads
|
|
}
|
|
|
|
const ModeChangeLimit = 3
|
|
|
|
// SeqTolerance: a read whose start is within this many bytes of the current read
|
|
// frontier still counts as sequential. Using a tolerance window rather than
|
|
// strict contiguity absorbs reordered/concurrent readahead (multiple ReadAt can
|
|
// be in flight at once) while still rejecting far random jumps.
|
|
const SeqTolerance = 8 << 20 // 8 MiB
|
|
|
|
// For streaming read: only cache the first chunk
|
|
// For random read: only fetch the requested range, instead of the whole chunk
|
|
|
|
func NewReaderPattern() *ReaderPattern {
|
|
return &ReaderPattern{
|
|
isSequentialCounter: 0,
|
|
readFrontier: 0,
|
|
}
|
|
}
|
|
|
|
func (rp *ReaderPattern) MonitorReadAt(offset int64, size int) {
|
|
// Advance the frontier to max(frontier, offset+size) and capture, in the same
|
|
// CAS loop, the pre-image this read is judged against. Reading the frontier
|
|
// inside the loop (rather than once up front) keeps `diff` below comparing
|
|
// against the freshest value even if a concurrent readahead advances the
|
|
// frontier while we loop. Lock-free, consistent with the rest of this type.
|
|
end := offset + int64(size)
|
|
var frontier int64
|
|
for {
|
|
frontier = atomic.LoadInt64(&rp.readFrontier)
|
|
if end <= frontier || atomic.CompareAndSwapInt64(&rp.readFrontier, frontier, end) {
|
|
break
|
|
}
|
|
}
|
|
|
|
// near = this read starts within SeqTolerance of where reads had reached.
|
|
// Hysteresis (the ±ModeChangeLimit counter) keeps a single outlier read from
|
|
// flipping the mode.
|
|
diff := offset - frontier
|
|
if diff < 0 {
|
|
diff = -diff
|
|
}
|
|
counter := atomic.LoadInt64(&rp.isSequentialCounter)
|
|
if diff <= SeqTolerance {
|
|
if counter < ModeChangeLimit {
|
|
atomic.AddInt64(&rp.isSequentialCounter, 1)
|
|
}
|
|
} else if counter <= 0 {
|
|
// Entering random mode is a strong verdict: drop to the bottom of
|
|
// the window so the contiguous tail of one ranged request cannot
|
|
// flip it back on the next buffer read and pay a whole-chunk fetch.
|
|
atomic.StoreInt64(&rp.isSequentialCounter, -ModeChangeLimit)
|
|
} else {
|
|
atomic.AddInt64(&rp.isSequentialCounter, -1)
|
|
}
|
|
}
|
|
|
|
func (rp *ReaderPattern) IsRandomMode() bool {
|
|
return atomic.LoadInt64(&rp.isSequentialCounter) < 0
|
|
}
|