History log of /freebsd-9.3-release/sys/boot/common/bcache.c
Revision Date Author Comments
(<<< Hide modified files)
(Show modified files >>>)
# 267654 19-Jun-2014 gjb

Copy stable/9 to releng/9.3 as part of the 9.3-RELEASE cycle.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

# 225736 22-Sep-2011 kensmith

Copy head to stable/9 as part of 9.0-RELEASE release cycle.

Approved by: re (implicit)


# 136097 03-Oct-2004 stefanf

Use the correct printf specifier.

PR: 47187


# 119483 25-Aug-2003 obrien

Use __FBSDID().
Also some minor style cleanups.


# 91218 25-Feb-2002 bde

Removed mounds of unused variables.


# 87634 10-Dec-2001 jhb

Add support for writing blocks to the loader's disk cache.

PR: kern/32389
Submitted by: Jonathan Mini <mini@haikugeek.com>
Sponsored by: ClickArray, Inc.


# 87599 10-Dec-2001 obrien

Update to C99, s/__FUNCTION__/__func__/,
also don't use ANSI string concatenation.


# 64187 03-Aug-2000 jhb

Cleanup warnings. Most of these are signed/unsigned warnings, as well as
some added const's.


# 58080 14-Mar-2000 dcs

bcache_strategy() now receives an unit number, and keep track of what
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>


# 50477 27-Aug-1999 peter

$Id$ -> $FreeBSD$


# 43600 04-Feb-1999 dcs

Silence a warning.
PR: bin/9754


# 41254 19-Nov-1998 paul

This fixes a bug in the bcache code whereby false cache hits occur
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.


# 40875 03-Nov-1998 msmith

Add BootForth hooks; if BOOT_FORTH is defined, pass every line read
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).


# 40835 02-Nov-1998 msmith

Ok, the entry aging algorithm sucked; 1s time resolution is not enough for
LRU. Use a 31-bit counter instead. If we decide to do heavy I/O through
the bootloader this will have to be revisited.


# 40834 02-Nov-1998 msmith

Implement a simple LRU block cache. By default this is initialised to 16k,
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.