Functionality Backported From Bosco

One of the key features of the upcoming release of Bedrock, Bosco, is a much faster brc. This has been backported to Momo for those who would like the performance improvement without having to wait for Bosco's release.

Note that this backport has had minimal testing and may be potentially problematic. If you experience problems, rolling back to Momo's brc is advisable.

Benchmarks

To get an idea of the kind of performance improvement, the time to run cat /etc/issue >dev/null was tested "natively" without using brc at all (as a control), with the new Bosco brc and with the old Momo brc. The "native" example was run several times before running any testing was done to ensure the contents of the file being read were already in RAM.

On an desktop using a Intel Core i5-3550 (quad core, 3.30Ghz), in a Debian squeeze client, the results were as follows:

time cat /etc/issue >/dev/null
cat /etc/issue > /dev/null 0.00s user 0.00s system 0% cpu 0.001 total
time brc-bosco squeeze cat /etc/issue >/dev/null
brc-bosco squeeze cat /etc/issue > /dev/null 0.00s user 0.00s system 0% cpu 0.001 total
time brc-momo squeeze cat /etc/issue >/dev/null
brc-momo squeeze cat /etc/issue > /dev/null 0.00s user 0.07s system 14% cpu 0.478 total

Thus, on that system, Momo's brc causes an almost half-second delay. The backported Bosco's brc's overhead was sufficiently small that with time's resolution was insufficient to notice any change between using brc and not using brc at all. Moreover, the CPU utilization for the new brc was, like the time it took, below time's resolution. Momo's brc had a 14% cpu utilization overhead.

On an laptop using a Intel Core i3-2310M (dual core, hyperthreading, 2.10Ghz), in a Debian squeeze client, the results were as follows:

time cat /etc/issue >/dev/null
cat /etc/issue > /dev/null 0.00s user 0.00s system 46% cpu 0.002 total
time brc-bosco squeeze cat /etc/issue >/dev/null
brc-bosco squeeze cat /etc/issue > /dev/null 0.00s user 0.00s system 53% cpu 0.002 total
time brc-momo squeeze cat /etc/issue >/dev/null
brc-momo squeeze cat /etc/issue > /dev/null 0.00s user 0.07s system 61% cpu 2.025 total

The results are similar on the slower machine: the new brc has a negligible CPU usage and time delay, compared to the very noticeable delay caused by Momo's brc. Quite a noticeable improvement.

Upgrade instructions

Make a slight change to (the core Bedrock's) /etc/init.d/rcS to ensure the mount points are set up early, as the new brc will make the assumption that they are. Be careful not to edit a client's /etc/init.d/rcS but the core Bedrock's: from a client (with a full editor) you can probably access this at somewhere such as /var/chroot/bedrock/etc/init.d/rcS, depending on how you set up your Bedrock Linux install.

At line 157 (just above the "DEVICE_MANAGER = "udev" line), add the following:
```
announce "Setting up mounts for clients..."
brs
result
```
Then, at the very bottom of the script, remove the if block about "$AUTO_BRS" = "1", as it will no longer serve any benefit.

Back up the old brc just in case.

cp /opt/bedrock/bin/brc /opt/bedrock/bin/brc-old

Download this file somewhere (such as to /usr/src/brc) and cd to that directory.
Run the following to compile the new brc:
```
gcc brc.c -o brc -static -lcap
```
If it complains that you are missing a required library (such as sys/capability.h), install the corresponding package and try again. On debian, this package would be libcap-dev.
Double-check that the new binary was statically compiled. Ensure ldd tells you "not a dynamic executable"
```
ldd brc
```
If you do not already have it, install the package that contains the "setcap" command in one of your clients. For example, this would be the libcap2-bin package on Debian-based systems.
Run a shell, as root, from the client that has the setcap command. You are about to (temporarily) break brc, and if you are not already in a root shell which has normal access to setcap you may have to fix things either with brc-old or falling back to brroot. Be sure to cd to the directory which contains the newly-compiled brc.
In this root shell, move the newly-compiled brc over the old brc.
```
cp brc /opt/bedrock/bin/brc
```
Set the cap_sys_chroot capability (both effective and permitted, but not inherited):
```
setcap cap_sys_chroot=ep /opt/bedrock/bin/brc
```
At this point, you should be good to go. You probably don't have to reboot or do anything to tell the system about the new brc. For kicks, perhaps benchmark it. Run a shell in a client of your choice, then run (changing "client" below to the client the shell is in, such that the brc command is running the exact same version of cat on the exact same file):
- time cat /etc/issue >/dev/null
- time brc client cat /etc/issue >/dev/null
- time brc-old client cat /etc/issue >/dev/null

Rolling back the backport

If you have trouble with the backported brc and would like to roll it back, it is quite easy to do.

First, get to a root prompt. brroot should be resilient against whatever problems the new brc could cause, and on the off chance even that is insufficient, boot a Live distro and mount the filesystem.

Copy the backup brc over the new one

cp /opt/bedrock/bin/brc-old /opt/bedrock/bin/brc

The alterations to the init script should be safe to keep, as the worst they can do is slightly slow down your boot time. If you would like to revert them irrelevant, with your text editor of choice, go to line 157 of /etc/init.d/rcS in the core Bedrock and delete the three lines you created in step one of the upgrade instructions ("Setting up mounts for clients..."). Then, to the bottom of the file, append:
```
if [ "$AUTO_BRS" = "1" ]
then
	announce "Running brs (background)..."
	brs &
	result
fi
```
At this point, you should be good to go. You probably do not have to reboot, but it would be advisable here just in case.