Many people seem to be afraid of mixing stable with testing, but frankly, testing is fairly stable in its own right, and with proper preferences and solution checking, you can avoid the "stability drift" that puts your core packages on the unstable path.
"Testing is fairly stable??", you ask. Yes. In order for a package to migrate from unstable to testing, it has to have zero open bugs for 10 consecutive days. Chances are that, especially for the more popular packages, somebody is going to submit a bug report for an unstable version if something is wrong.
Even if you don't want to mix the environments, it's still nice to have the option there in case you run into something that requires a newer version than what is in stable.
Here's what I recommend for setting this up:
First, create the following files in /etc/apt/preferences.d
:
stable.pref
:
# 500 <= P < 990: causes a version to be installed unless there is a
# version available belonging to the target release or the installed
# version is more recent
Package: *
Pin: release a=stable
Pin-Priority: 900
testing.pref
:
# 100 <= P < 500: causes a version to be installed unless there is a
# version available belonging to some other distribution or the installed
# version is more recent
Package: *
Pin: release a=testing
Pin-Priority: 400
unstable.pref
:
# 0 < P < 100: causes a version to be installed only if there is no
# installed version of the package
Package: *
Pin: release a=unstable
Pin-Priority: 50
experimental.pref
:
# 0 < P < 100: causes a version to be installed only if there is no
# installed version of the package
Package: *
Pin: release a=experimental
Pin-Priority: 1
(Don't be afraid of the unstable/experimental stuff here. The priorities are low enough that it's never going to automatically install any of that stuff. Even the testing branch will behave, as it's only going to install the packages you want to be in testing.)
Now, creating a matching set for /etc/apt/sources.list.d
:
stable.list
: Copy from your original /etc/apt/sources.list
. Rename the old file to something like sources.list.orig
.
testing.list
: Same as stable.list
, except with testing
.
unstable.list
: Same as stable.list
, except with unstable
, and remove the security lists.
experimental.list
: Same as unstable.list
, except with experimental
.
You can also add a oldstable
in sources.lists.d
and preferences.d
(use a priority of 1), though this moniker will tend to expire and disappear before the next stable cycle. In cases like that, you can use http://archive.debian.org/debian/
and "hardcode" the Debian version (etch, lenny, etc.).
To install the testing version of a package, simply use aptitude install lib-foobar-package/testing
, or just jump into aptitude's GUI and select the version inside of the package details (hit enter on the package you're looking at).
If you get complaints of package conflicts, look at the solutions first. In most cases, the first one is going to be "don't install this version". Learn to use the per-package accept/reject resolver choices. For example, if you're installing foobar-package/testing, and the first solution is "don't install foobar-package/testing", then mark that choice as rejected, and the other solutions will never veer to that path again. In cases like these, you'll probably have to install a few other testing packages.
If it's getting too hairy (like it's trying to upgrade libc or the kernel or some other huge core system), then you can either reject those upgrade paths or just back out of the initial upgrade altogether. Remember that it's only going to upgrade stuff to testing/unstable if you allow it to.
EDIT: Fixed some priority pins, and updated the list.
With a bit of experimentation I've found four possible solutions.
With each approach, you need to perform the steps and then continue to read more data to fill up the ZFS ARC cache and to trigger the feed from the ARC to the L2ARC. Note that if the data is already cached in memory, or if the compressed size on disk of each block is greater than 32kB, these methods won't generally do anything.
1. Set the documented kernel flag zfs_prefetch_disable
The L2ARC by default refuses to cache data that has been automatically prefetched. We can bypass this by disabling the ZFS prefetch feature. This flag is often a good idea for database workloads anyway.
echo "zfs_prefetch_disable/W0t1" | mdb -kw
..or to set it permananently, add the following to /etc/system
:
set zfs:zfs_prefetch_disable = 1
Now when files are read using dd
, they will still be eligible for the L2ARC.
Operationally, this change also improves the behaviour of reads in my testing. Normally, when ZFS detects a sequential read it balances the throughput among the data vdevs and cache vdevs instead of just reading from cache -- but this hurts performance if the cache devices are significantly lower-latency or higher-throughput than the data devices.
2. Re-write the data
As data is written to a ZFS filesystem it is cached in the ARC and (if it meets the block size criteria) is eligible to be fed into the L2ARC. It's not always easy to re-write data, but some applications and databases can do it live, e.g. through application-level file mirroring or moving of the data files.
Problems:
- Not always possible depending on the application.
- Consumes extra space if there are snapshots in use.
- (But on the bright side, the resulting files are defragmented.)
3. Unset the undocumented kernel flag l2arc_noprefetch
This is based on reading the OpenSolaris source code and is no doubt completely unsupported. Use at your own risk.
Disable the l2arc_noprefetch
flag:
echo "l2arc_noprefetch/W0" | mdb -kw
Data read into the ARC while this flag is disabled will be eligible for the L2ARC even if it's a sequential read (as long the blocks are at most 32k on disk).
Read the file from disk:
dd if=filename.bin of=/dev/null bs=1024k
Re-enable the l2arc_noprefetch
flag:
echo "l2arc_noprefetch/W1" | mdb -kw
4. Read the data randomly
I wrote a Perl script to read files in 8kB chunks pseudorandomly (based on the ordering of a Perl hash). It may also work with larger chunks but I haven't tested that yet.
#!/usr/bin/perl -W
my $BLOCK_SIZE = 8*2**10;
my $MAX_ERRS = 5;
foreach my $file (@ARGV) {
print "Reading $file...\n";
my $size;
unless($size = (stat($file))[7]) {print STDERR "Unable to stat file $file.\n"; next; }
unless(open(FILE, "<$file")) {print STDERR "Unable to open file $file.\n"; next; }
my $buf;
my %blocks;
for(my $i=0;$i<$size/$BLOCK_SIZE;$i++) { $blocks{"$i"} = 0; }
my $errs = 0;
foreach my $block (keys %blocks) {
unless(sysseek(FILE, $block*$BLOCK_SIZE, 0) && sysread(FILE, $buf, $BLOCK_SIZE)) {
print STDERR "Error reading $BLOCK_SIZE bytes from offset " . $block * $BLOCK_SIZE . "\n";
if(++$errs == $MAX_ERRS) { print STDERR "Giving up on this file.\n"; last; }
next;
}
}
close(FILE);
}
Problems:
- This takes a long time and puts a heavy workload on the disk.
Remaining issues
- The above methods will get the data into main memory, eligible for feeding into the L2ARC, but they don't trigger the feed. The only way I know to trigger writing to the L2ARC is to continue reading data to put pressure on the ARC.
- On Solaris 11.3 with SRU 1.3.9.4.0, only rarely does the L2ARC grow the full amount expected. The
evict_l2_eligible
kstat increases even when the SSD devices are under no pressure, indicating that data is being dropped. This remaining rump of uncached data has a disproportionate effect on performance.
Best Answer
The current version of the
developer/golang-15
package has a dependency on Perl 5.22:In your case it apparently was still dependent on Perl 5.20. Either way, the trouble is that the default Solaris 11.3 installation comes with Perl 5.12. Since other packages have a dependency on the Perl runtime as well, the system tries to lock in this version to prevent broken packages. This is done through a Solaris package management feature called Incorporations. The incorporation package serves to prevent unintended upgrades or downgrades of OS packages. However, for certain packages it will provide a loop hole so the administrator can install a different version. By setting
facet.version-lock.runtime/perl-512=false
you effectively told Solaris to release the lock on Perl 5.12, and allow an upgrade to a later version. Subsequent to the Golang install, your default Perl version will change from 5.12 to 5.22:Here is a link to the Oracle documentation that explains this feature in more detail: http://docs.oracle.com/cd/E26502_01/html/E28984/gmias.html