All posts by Dave

Canceling ZFS zpool replace when a new drive fails

In my case I had a bad SATA cable instead of a bad drive, but the end result was the same: a failed zpool replace.

It’s surprisingly easy to fix:
zpool detach /path/to/device

After this it will keep resilvering without the new device, but that didn’t stop me from replacing the bad cable, reinitializing the drive, and doing another zpool replace that started without delay.

Prioritizing OpenZFS resilvering so that it isn’t so slow (ZFS on Linux)

I went to replace an aging drive with a brand new one, so I issued a

zpool replace poolname olddisk1 newdisk1

Sweet. It worked. Err….

zpool status

7.19G scanned out of 10.2T at 46.0M/s, 64h23m to go
1.73G resilvered, 0.07% done

What the hell? That’s ridiculously slow.

Turns out there is a default priority setting in the ZFS kernel module that is tunable via sysfs. It defaults to 2 clock ticks of delay and setting it to 0 essentially sets it at the same priority as other I/O:
echo 0 > /sys/module/zfs/parameters/zfs_resilver_delay


54.6G scanned out of 10.2T at 87.8M/s, 33h35m to go
13.2G resilvered, 0.52% done

Still slow, but not as bad as 46MB/s. Sheesh.

Update:

There is another parameter that greatly increases the resilvering throughput:
echo 0 > /sys/module/zfs/parameters/zfs_scan_idle

The effect it had on my latest drive replacement was enormous:
885G scanned out of 8.99T at 431M/s, 5h29m to go

Fixing dwww prohibiting LAN access

dwww ships with access to localhost only, but that may not become evident until you try to actually use it from another host. In this case I was trying to browse some documentation from a tablet. Its configuration for Apache is under:

/etc/apache2/conf-available/dwww.conf

To change its access permissions, alter the lines that begin with “Require ip” to your own subnet and uncomment them (remove the # at the beginning of the line). If you’re on a network beginning in 10. use a /16 CIDR prefix, if you’re on a 192.168. use /24.

Reducing screen brightness at night on Linux with xcalib

xcalib (debian package) has saved my eyes quite a few times on long nights. It can reduce effective screen brightness below minimum settings by altering the contrast. I usually reduce the contrast to 70% in a totally dark room:
xcalib -a -co 70
The -a option is to alter the current setting. -co is the contrast level in percentage.

Another fun thing it can do for night reading is color inversion with the -i option:
xcalib -a -i
To undo inversion, just run that command again to invert the inversion.

To reset changes made with xcalib, use the -c option to get back to normal:
xcalib -c

Chromium (or Google Chrome) on Debian (or Ubuntu) asking for login keyring password

I don’t store passwords in my browser so this feature is completely useless to me. I don’t even have “Offer to save your web passwords” checked in chrome://settings. Yet every time I launch Chromium I am prompted for my password to unlock my login keyring. I’m done with that.

1.) Copy the chromium.desktop file to our local applications folder:
cp /usr/share/applications/chromium.desktop ~/.local/share/applications/
If using the official Google Chrome, copy that .desktop file instead:
cp /usr/share/applications/google-chrome.desktop ~/.local/share/applications/

2.) Edit this newly copied file to add the –password-store=basic flag on the line beginning in ‘Exec’ (near the bottom of the file):
Exec=/usr/bin/chromium --password-store=basic --enable-remote-extensions %U
For offical Google Chrome, there will be multiple lines beginning with Exec. The first one in the file should be changed to this:
Exec=/usr/bin/google-chrome-stable --password-store=basic %U

I also added the –enable-remote-extensions flag so that Chromium again loads extensions. This is not necessary for official Google Chrome.

3.) Tell our system that we trust this new .desktop file by giving it execute permissions:
chmod +x ~/.local/share/applications/chromium.desktop
For official Google Chrome:
chmod +x ~/.local/share/applications/google-chrome.desktop

4.) If running gnome-shell, hit Alt+F2 and type the r key and hit Enter/Return to restart the window manager (and reload the local applications folder).

No more asking for login keyring passwords!

Chromium on Debian not loading extensions anymore

For some reason this happened:

chromium-browser (55.0.2883.75-4) unstable; urgency=medium

* External extensions are now disabled by default. Chromium will only load
extensions that are explicitly specified with the –load-extension command
line option passed into CHROMIUM_FLAGS. See the chromium-lwn4chrome
package for an example of how to do this.
* You can also use the –enable-remote-extensions command line argument to
chromium, which will bypass this restriction.

Not only that — they completely broke the launcher script in doing so:
echo " --enable-remote-extensions Allow extensions from remote sites

Missing something? It’s a close-quote. Nice one to release out into the wild. They fixed it a little while later but it was interesting to see.

So to get Chromium acting as it used to, we can do this:

1.) Copy the chromium.desktop file to our local applications folder:
cp /usr/share/applications/chromium.desktop ~/.local/share/applications/

2.) Edit this newly copied file to add the –enable-remote-extensions flag on the line beginning in ‘Exec’ (near the bottom of the file):
Exec=/usr/bin/chromium --enable-remote-extensions %U

3.) Tell our system that we trust this new .desktop file by giving it execute permissions:
chmod +x ~/.local/share/applications/chromium.desktop

4.) If running gnome-shell, hit Alt+F2 and type the r key and hit Enter/Return to restart the window manager (and reload the local applications folder).

At this point you will have Chromium back to normal loading your extensions.

Update on CenturyLink DSL Connection Problems

In CenturyLink DSL connection problems I described a problem where my modem would hangup with no pppd exit status whenever my connection was saturated. I suspected a problem at the DSLAM and called CenturyLink support. They agreed to put me on a blacklist of subscribers for whom line-monitoring software causes issues. This had to get approved by a tier 3 technician. While it prevented the problem from happening every time, I still saw connection drops when downloading large files at a high speed. I needed my own solution and it was a bit of a depressing one. My ADSL service is quoted as 12Mbps downlink and dsl_status reports 15.870 Mb/s down / 892 Kb/s up. However, I’ve found through much trial and error that my line is only capable of sustaining 10Mbps. I employed OpenWRT’s qos-scripts to limit my WAN downstream link to 10000kbps. Since then I haven’t seen a connection drop by a simple ‘modem hangup’ with no exit status. I have seen ‘leave showtime’ in the kernel log a few times, which is a similarly terse way of announcing a disconnection, but haven’t tied it to any cause. I have also had LCP timeouts, which is to be begrudgingly expected. I can now download my server backups and other large files without having to constantly monitor my connection, although my effective connection speed is disappointing.