Reclaiming Drives to Build a New RAID
07 January 2018
A couple years ago, I replaced my old spinner drives with matching SSDs. I left the old drives mounted but disconnected the cables. I’ve been watching my photo collection grow and consume about half my live storage, so I figured it was time to bring those slower spinning drives back online, so I can move my archive of old photos off my fast drives and get a little extra room.
I plugged in the first drive, and observed that it fortunately did not try to join the existing RAID arrays.
lsblk showed me a list of drives and partitions and how they were currently used, so I could confidently
cfdisk /dev/sda to wipe and recreate 1 primary partition on the drive as type
fd (Linux raid autodetect). I rebooted to see the new partition table, and then installed and did the second drive (
/dev/sdb in my case).
I setup the new drives in a mirror:
# create a new RAID1 mirror out of those new partitions:
mdadm --create /dev/md2 --level 1 --raid-devices=2 /dev/sda1 /dev/sdb1
# to ensure it's still called md2, and not md127 on reboot
# create a filesystem
mkfs -t ext4 /dev/md2
# mount it to copy
mount /dev/md2 /mnt/new
# migrate all my photos
rsync -av /home/john/Photos/ /mnt/new
After the initial migration, I tested it:
Checked that the array is there with the same name:
cat /proc/mdstat (It initially had not kept the name, and that’s when I learned to
Mounted the new array as
Checked that Digikam still works.
That looked good, so it’s time to make it permanent:
Unmounted the new filesystem
Deleted all the old contents of
Added the new array to the
/etc/fstab to mount it automatically
2018-01-04 Source Local Bash RC
04 January 2018
Today, I’m knocking something off the TODO list: Ensuring a way to have local, non-shared shell initialization across workstations, while still sharing most the code.
07 June 2017
Spamassassin daemon on my server had apparently shutdown, and I hadn’t noticed until I logged in to check email and found thousands of emails in my inbox, instead of having been properly filtered for spam. I cleaned up about 100 messages by hand, but I quickly realized I didn’t want to do this anymore. I found a tip at the Unix StackExchange suggesting that
procmail could be run again on each message file as it sits in the
Maildir, and each would be processed through spamassassin normally and redelivered to the correct mailbox.
To be safe, I moved all the new mail files (
/tmp/mail, fired up
mutt to see them all gone, and then piped each file into
for x in /tmp/mail/\*; do echo $x; procmail < $x; done
mutt, I could see mail starting to appear again in my inbox and in my spam folders.
When the loop was done, and I was sure my inbox looked good, I removed
/tmp/mail, and I was back in business.
Ultrawide Display on Debian Linux
27 November 2016
I picked up a very-slightly-used 34-inch LG 34UM67 display to use on my Debian Linux workstation that I use for processing photos. It’s an IPS display with 2560x1080 pixels, so that should fit nicely with photo work.
The built-in graphics on my Dell T20 only supports VGA, so I also needed to buy a new video card to support HDMI. My needs are modest, so I picked out an Asus ATI Radeon HD6450. I’ve always gone for ATI/AMD and Intel when I could, since their fully open-source versions of drivers have worked well in the past. I’m also not a gamer, so I can skip over Nvidia.
Upon plugging it all together, I needed to ensure I had all the "amdgpu" packages installed from Debian Unstable, so I could get higher resolutions beyond VGA.
It still didn’t recognize the crazy-wide 21:9 aspect ratio out of the box, so I still had some work to do. By default, the display awkwardly stretched the card’s 1920x1080 across the whole screen. That can be fixed in the display: Menu → Quick Settings → Ratio → 1:1, and then you’ll have letter boxes on the sides, but no stretching.
That left me still needing to convince my Xorg xserver to use the rest of the screen, all 2560x1080 pixels. I found a stackexchange article which provided me just about everything I needed.
Generate a modeline for the new resolution:
Create that new modeline dynamically. In my case mine, looked like this:
xrandr --newmode "2560x1080_30.00" 106.75 2560 2640 2896 3232 1080 1083 1093 1102 -hsync +vsync
Add the mode to the HDMI interface. In my case it was named
xrandr --addmode HDMI-0 2560x1080_30.00
Then switch to it:
xrandr --output HDMI-0 --mode 2560x1080_30.00
Once I had proven these settings to work nicely, I obviously wanted to keep them, so I persisted them by creating a file for them in the xorg config directory along-side the existing configs that Debian provides. I called my file
Modeline "2560x1080_30.00" 106.75 2560 2640 2896 3232 1080 1083 1093 1102 -hsync +vsync
Option "PreferredMode" "2560x1080_30.00"
Upon reboot, everything was working, and I was happy for a week or 2, but I noticed performance wasn’t great during fast 2D updates. I was seeing some tearing when I’d play a video in full-screen or even a large window. I dug around a little in the
amdgpu(4) man page and found a couple more options to add to my
Option "TearFree" "on"
Option "ShadowPrimary" "on"
Those final adjustments solved the performance problem for me. I expect those adjustments may only be specific to the cheap card I bought, though.
Next I’ll need to figure out how to speed up my mouse, since it’s such a long way from one side of the screen to the other. I’ll also further rethink the windows I keep beside one another.
I bought the display figuring Linux can be made to do anything, and I was right. I just needed to figure out how.
All the Posts