aboutsummaryrefslogtreecommitdiff
path: root/sys/boot/common/bcache.c
Commit message (Collapse)AuthorAgeFilesLines
* Move sys/boot to stand. Fix all references to new locationWarner Losh2017-11-141-503/+0
| | | | | | | Sponsored by: Netflix Notes: svn path=/head/; revision=325834
* loader: want mechanism to avoid RA with bcacheToomas Soome2017-04-061-3/+9
| | | | | | | | | | | | | | | | | While we have mechanisms in place to protect ourselves against the read behind the disk end, there is still one corner case. As the GPT partition table has backup table at the end of the disk, and we yet do not know the size of the disk (if the wrong size is provided by the firmware/bios), we need to limit the reads to avoid read ahead in such case. Note: this update does add constant into stand.h, so the incremental build will need to get local stand.h updated first. Reviewed by: allanjude Differential Revision: https://reviews.freebsd.org/D10187 Notes: svn path=/head/; revision=316578
* loader: possible NULL pointer dereference in bcache.cToomas Soome2017-02-081-6/+5
| | | | | | | | | | | | | | Coverity detected the possible NULL pointer dereference case. Also updated comment as was suggested in illumos review. CID: 1371008 Reported by: Coverity Reviewed by: allanjude Approved by: allanjude (mentor) Differential Revision: https://reviews.freebsd.org/D9496 Notes: svn path=/head/; revision=313451
* loader: bcache read ahead block count should take account the large sectorsToomas Soome2017-02-061-8/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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: svn path=/head/; revision=313332
* dosfs support in libstand is broken since r298230Toomas Soome2016-12-301-32/+18
| | | | | | | | | | | | | | | | | | | | | | Apparently the libstand dosfs optimization is a bit too optimistic and did introduce possible memory corruption. This patch is backing out the bad part and since this results in dosfs reading full blocks now, we can also remove extra offset argument from dv_strategy callback. The analysis of the issue and the backout patch is provided by Mikhail Kupchik. PR: 214423 Submitted by: Mikhail Kupchik Reported by: Mikhail Kupchik Reviewed by: bapt, allanjude Approved by: allanjude (mentor) MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D8644 Notes: svn path=/head/; revision=310850
* bcache should support reads shorter than sector sizeAllan Jude2016-07-301-1/+3
| | | | | | | | | | | | dosfs (fat file systems) can perform reads of partial sectors bcache should support such reads. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: cem Differential Revision: https://reviews.freebsd.org/D6475 Notes: svn path=/head/; revision=303555
* bcache read ahead may attempt to read past end of diskAllan Jude2016-05-011-8/+39
| | | | | | | | | | | | | The new bcache code does not know the size of the disk, and therefore may attempt to read past the end of the disk while trying to fill its read-ahead cache. This is usually not an issue, it fails gracefully on all of my machines, but some BIOSes seem to retry the reads for up to 30 seconds each, resulting in a long stall during boot Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: jhb, np Differential Revision: https://reviews.freebsd.org/D6109 Notes: svn path=/head/; revision=298900
* A new implementation of the loader block cacheAllan Jude2016-04-181-177/+265
| | | | | | | | | | | | | | | | | | | | The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713 Notes: svn path=/head/; revision=298230
* Use the correct printf specifier.Stefan Farfeleder2004-10-031-1/+3
| | | | | | | PR: 47187 Notes: svn path=/head/; revision=136097
* Use __FBSDID().David E. O'Brien2003-08-251-2/+3
| | | | | | | Also some minor style cleanups. Notes: svn path=/head/; revision=119483
* Removed mounds of unused variables.Bruce Evans2002-02-251-4/+0
| | | | Notes: svn path=/head/; revision=91218
* Add support for writing blocks to the loader's disk cache.John Baldwin2001-12-111-21/+92
| | | | | | | | | PR: kern/32389 Submitted by: Jonathan Mini <mini@haikugeek.com> Sponsored by: ClickArray, Inc. Notes: svn path=/head/; revision=87634
* Update to C99, s/__FUNCTION__/__func__/,David E. O'Brien2001-12-101-1/+1
| | | | | | | also don't use ANSI string concatenation. Notes: svn path=/head/; revision=87599
* Cleanup warnings. Most of these are signed/unsigned warnings, as well asJohn Baldwin2000-08-031-15/+16
| | | | | | | some added const's. Notes: svn path=/head/; revision=64187
* bcache_strategy() now receives an unit number, and keep track of whatDaniel C. Sobral2000-03-151-8/+24
| | | | | | | | | | | | | was the last unit number received. If it changes, it flushes the cache. Add bcache_flash(). The actual fix is sligthly different from the one in the PR. PR: 17098 Submitted by: John Hood <jhood@sitaranetworks.com> Notes: svn path=/head/; revision=58080
* $Id$ -> $FreeBSD$Peter Wemm1999-08-281-1/+1
| | | | Notes: svn path=/head/; revision=50477
* Silence a warning.Daniel C. Sobral1999-02-041-2/+2
| | | | | | | PR: bin/9754 Notes: svn path=/head/; revision=43600
* This fixes a bug in the bcache code whereby false cache hits occurPaul Richards1998-11-191-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the first time block 0 is read. This fix initialises the block numbers to -1 which isn't the most correct thing for a daddr_t but it isn't likely to cause a problem in the boot blocks and it could do with a more thought out fix later. The bug is probably benign on the i386 but on the alpha it can cause initial file opens to fail. This is the cause of the "can't open /boot/boot.conf" errors. It appears on the alpha because of a number of combining factors. On the alpha the LABELSECTOR is 0 so block 0 needs to be read in from the media. The first time this happens you get a false hit because the bc_blkno field is zero initially. Also, the timestamp check against this cache hit succeeds because on the alpha a hacked getsecs() function can return 0 when it starts counting so that the zero initial timestamp + BCACHE_TIMEOUT is greater than the current time until getsecs() has counted passed BCACHE_TIMEOUT. The overall effect is that the first open() that occurs gets a false cache hit and returns garbage to the bd_strategy() function which then fails the open() call. This false hit then stays in the cache until BCACHE_TIMEOUT getsecs() ticks have passed; all open() calls during this time fail. This explains why you can generally access the media by the time you get to interp() and start issuing commands but the earlier attempts to run the boot scripts are failing. It's possible that this is causing the problem switching to the mfsroot floppy as well but I haven't confirmed that. Notes: svn path=/head/; revision=41254
* Add BootForth hooks; if BOOT_FORTH is defined, pass every line readMike Smith1998-11-041-2/+26
| | | | | | | | | | to the Forth interpreter. Instantiate all of our inbuilt commands as Forth words, and handle them being called from there. Add my copyright to the bcache module (oops). Notes: svn path=/head/; revision=40875
* Ok, the entry aging algorithm sucked; 1s time resolution is not enough forMike Smith1998-11-021-7/+16
| | | | | | | | LRU. Use a 31-bit counter instead. If we decide to do heavy I/O through the bootloader this will have to be revisited. Notes: svn path=/head/; revision=40835
* Implement a simple LRU block cache. By default this is initialised to 16k,Mike Smith1998-11-021-0/+227
and will bypass transfers for more than 8k. Blocks are invalidated after 2 seconds, so removable media should not confuse the cache. The 8k threshold is a compromise; all UFS transfers performed by libstand are 8k or less, so large file reads thrash the cache. However many filesystem metadata operations are also performed using 8k blocks, so using a lower threshold gives poor performance. Those of you with an eye for cache algorithms are welcome to tell me how badly this one sucks; you can start with the 'bcachestats' command which will print the contents of the cache and access statistics. Notes: svn path=/head/; revision=40834
generated by cgit v1.3 (git 2.53.0) at 2026-03-11 01:47:22 +0000