aboutsummaryrefslogtreecommitdiff
path: root/lib/libstand
diff options
context:
space:
mode:
authorToomas Soome <tsoome@FreeBSD.org>2017-02-06 08:58:40 +0000
committerToomas Soome <tsoome@FreeBSD.org>2017-02-06 08:58:40 +0000
commit7a60826b652cf75ae70515ab07ca1ab42dc98379 (patch)
tree10eea6e8aa27d7a71399b302a979a738f9ef8318 /lib/libstand
parentfff006f7c0ac402193144197cdf093ed9eecf741 (diff)
downloadsrc-7a60826b652cf75ae70515ab07ca1ab42dc98379.tar.gz
src-7a60826b652cf75ae70515ab07ca1ab42dc98379.zip
loader: bcache read ahead block count should take account the large sectors
The loader bcache is implementing simple read-ahead to boost the cache. The bcache is built based on 512B block sizes, and the read ahead is attempting to read number of cache blocks, based on amount of the free bcache space. However, there are devices using larger sector sizes than 512B, most obviously the CD media is based on 2k sectors. This means the read-ahead can not be just random number of blocks, but we should use value suitable also for use with larger sectors, as for example, with CD devices, we should read multiple of 2KB. Since the sector size from disk interface is not too reliable, i guess we can just use "good enough" value, so the implementation is rounding down the read ahead block count to be multiple of 16. This means we have covered sector sizes to 8k. In addition, the update does implement the end of cache marker, to help to detect the possible memory corruption - I have not seen it happening so far, but it does not hurt to have the detection mechanism in place. Reviewed by: allanjude Approved by: allanjude (mentor) Differential Revision: https://reviews.freebsd.org/D9179
Notes
Notes: svn path=/head/; revision=313332
Diffstat (limited to 'lib/libstand')
0 files changed, 0 insertions, 0 deletions