If you have waded through my previous post about adding a larger drive to an lvm volume running on an mdadm RAID array, you'll have seen it's a bit of a fiddly, complex process. I have been fiddling around a bit with ZFS on Linux on my old desktop machine (Core 2 Quad Q9300, 8GB RAM). I had a couple of old 1TB drives, and added the 2TB drive that I removed from the home theatre PC, mentioned in the previous post. Actually, I had put the 3TB drive in this old box initially, intending it to replace the HTPC. But it's a bit power hungry, using around 90W at idle, and I am having some niggling playback issues with it. But that's another story. So the 3TB WD Red drive gets replaced with the old Samsung 2TB.
With the three drives, I tried creating a ZFS raidz array, basically equivalent to RAID 5. It runs pretty well. Swapping the drives over (from 3TB to 2TB) gave me an opportunity to do the ZFS version of a drive swap.
It was a bit of an anticlimax, really. There was one command, the syntax from the man page is below:
zpool replace [-f] pool device [new_device]
In my case it was something like
sudo zpool replace tank /dev/disk/by-id/scsi-SATA...(the drive removed) /dev/disk/by-id/scsi-SATA....(the 2TB drive)
That started off the resilvering process (resynchronising the data across the drives). If I then were to replace each other drive, one at a time, with the above process, it would resize the array to match the new drive sizes.
The beauty of ZFS is it simplifies things so much. It is the RAID management and file system all in one.
I would have liked to run it in the HTPC, but ZFS is quite resource-hungry, in terms of processing power and memory. Since my HTPC just has a little Atom 330 chip and is maxed out with 4GB of memory (of which only 3GB is visible), I would be staying with mdadm and lvm. There is virtually no noticeable performance penalty with it. Oh well, going through all those steps is not exactly a frequent task.
Monday, November 26, 2012
Adding a larger drive to a software RAID array - mdadm and lvm
The MythTV box I have in the lounge previously had two storage hard drives, in a RAID 1 configuration to prevent data loss in case of a drive failure. The drives were a 3TB Hitachi and a 2TB Samsung. I figured the Samsung drive was getting on a bit now, and it was time a new drive was installed. Might as well make it a 3TB model as well, to take advantage of all the space available on the other one that was sitting unused.
A 3TB Western Digital Red drive was picked up. I chose this as it is designed for use in a NAS environment: always on. It also has low power consumption and a good warranty. I considered a Seagate Barracuda 3TB - they were cheap, performance would be better than the Red, but they are only designed for desktop use, around 8 hours a day powered on. Warranty was pretty short as well.
Removing and replacing the old drive
The drives were configured in a software RAID 1 array, using mdadm, with lvm on top of that. This makes the array portable, and not dependent on a particular hardware controller.
The commands here were adapted from the excellent instructions found here at howtoforge.com.
Fortunately I had enough space on another PC that I was able to back up the contents of the array before starting any of this.
To remove the old drive, which on this machine was /dev/sdc, the following command was issued to mark the drive as failed, in the array /dev/md0:
sudo mdadm --manage /dev/md0 --fail /dev/sdc
Next step is to remove the drive from the array:
sudo mdadm --manage /dev/md0 --remove /dev/sdc
Then, the system could be shut down and the drive removed and replaced with the new one. After powering the system back up, the following command adds the new drive to the array:
sudo mdadm --manage /dev/md0 --add /dev/sdc
The array will then start synchronising the data, copying it to the new drive, which could take a few hours. Note that no partitioning was done on the disk, as I am just using the whole drive in the array.
While the sync is in progress, you can check how it is progressing via:
cat /proc/mdstat
It will show a percentage of completion as well as an estimated time remaining. Once it is done, the array is ready for use! I left the array like this for a day or so, just to make sure everything was working alright.
Expanding the array to fill the space available - the mdadm part
Once the synchronisation has completed, the size of the array was still only 2TB, since that is the largest a RAID 1 array could go when it consists of a 3TB and a 2TB drive. We need to tell mdadm to expand the array to fill the available space. More information on this can be found here.
This is where things got complicated for me. It is to do with the superblock format version used in the array. More detail can be found at this page of the Linux RAID wiki.
To sum up, the array I had was created with the version 0.90 superblock. The version was found by entering
sudo mdadm --detail /dev/md0
The problem, potentially, was that if I grew the array to larger than 2TB it may not work. As quoted by the wiki link above:
Now, Mythbuntu 12.04 runs the 3.2 kernel, so according to that it should be OK supporting up to 4TB. But I wasn't 100% sure on that, and couldn't find any references elsewhere about it. I decided the safest way to go about this was to convert the array to a later version of the superblock, that didn't have that size limitation. Besides, it would save time in the future in case of trying to repeat this with a drive larger than 4TB.
Following the suggestion of the wiki, I decided to update to a version 1.0 superblock, as it would store the superblock information in the same place as the 0.90.
Note: if you are trying this yourself, and the array is already version 1.0 or later, then the command to grow it is just as below (may not want to do it with 0.90 superblock and larger than 2TB):
mdadm --grow /dev/md0 --size=max
Since I was going to change the superblock version, it involved stopping the array and recreating it with the later version.
Once again, to check the details of the array at the moment:
sudo mdadm --detail /dev/md0
Now, since the array is in use by MythTV, I thought it safest to stop the program:
sudo service mythtv-backend stop
Also, I unmounted where the array was mounted:
sudo umount /var/lib/mythtv
Since the data is in an LVM volume on top of the array, I deactivated that as well (the volume is named raid1 in this instance):
sudo lvchange -a n raid1
The array is now ready to be stopped:
sudo mdadm --stop /dev/md0
Now it can be re-created, specifying the metadata (superblock) version, the RAID level, and the number and names of the drives used:
sudo mdadm --create /dev/md0 --metadata=1.0 --level=1 --raid-devices=2 /dev/sdb /dev/sdc
The array will now start resynchronising. This took a number of hours for me, as there were around 770GB of recordings there. The RAID wiki link included --assume-clean in the above command, which would have skipped the resync. I elected to leave it out, for safety's sake.
Progress can be monitored with:
cat /proc/mdstat
The lvm volume can be restarted:
sudo lvchange -a y raid1
and the unmounted volumes can be re-mounted:
sudo mount -a
Check if they are all there with the
mount
command. The mythtv service can also be restarted:
sudo service mythtv-backend start
When the array is recreated, the UUID value of the array will be different. You can get the new value with:
sudo mdadm --detail /dev/md0
Edit the /etc/mdadm/mdadm.conf file, and change the UUID value in it to the new value. This will enable the array to be found on next boot.
Another thing to do before rebooting is to run
sudo update-initramfs -u
I didn't do this at first, and after rebooting, the array showed up named /dev/md127 rather than /dev/md0. Running the above command and rebooting again fixed it for me.
Expanding the array to fill the space available - the lvm part
Quite a long-winded process, isn't it? Using the lvm command to show the lvm physical volumes:
sudo pvdisplay
showed the array was still 1.82TiB (2TB). It needed to be extended. The following command will fill the volume to the available space:
sudo pvresize -v /dev/md0
To check the results, again run:
sudo pvdisplay
Now, running:
sudo vgdisplay
gave the following results for me:
--- Volume group ---
VG Name raid1
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 5
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 3
Open LV 2
Max PV 0
Cur PV 1
Act PV 1
VG Size 2.73 TiB
PE Size 4.00 MiB
Total PE 715397
Alloc PE / Size 466125 / 1.78 TiB
Free PE / Size 249272 / 973.72 GiB
VG UUID gvfheX-ifvl-yW9h-v4L2-eyzs-95fe-sng2oN
A 3TB Western Digital Red drive was picked up. I chose this as it is designed for use in a NAS environment: always on. It also has low power consumption and a good warranty. I considered a Seagate Barracuda 3TB - they were cheap, performance would be better than the Red, but they are only designed for desktop use, around 8 hours a day powered on. Warranty was pretty short as well.
Removing and replacing the old drive
The drives were configured in a software RAID 1 array, using mdadm, with lvm on top of that. This makes the array portable, and not dependent on a particular hardware controller.
The commands here were adapted from the excellent instructions found here at howtoforge.com.
Fortunately I had enough space on another PC that I was able to back up the contents of the array before starting any of this.
To remove the old drive, which on this machine was /dev/sdc, the following command was issued to mark the drive as failed, in the array /dev/md0:
sudo mdadm --manage /dev/md0 --fail /dev/sdc
Next step is to remove the drive from the array:
sudo mdadm --manage /dev/md0 --remove /dev/sdc
Then, the system could be shut down and the drive removed and replaced with the new one. After powering the system back up, the following command adds the new drive to the array:
sudo mdadm --manage /dev/md0 --add /dev/sdc
The array will then start synchronising the data, copying it to the new drive, which could take a few hours. Note that no partitioning was done on the disk, as I am just using the whole drive in the array.
While the sync is in progress, you can check how it is progressing via:
cat /proc/mdstat
It will show a percentage of completion as well as an estimated time remaining. Once it is done, the array is ready for use! I left the array like this for a day or so, just to make sure everything was working alright.
Expanding the array to fill the space available - the mdadm part
Once the synchronisation has completed, the size of the array was still only 2TB, since that is the largest a RAID 1 array could go when it consists of a 3TB and a 2TB drive. We need to tell mdadm to expand the array to fill the available space. More information on this can be found here.
This is where things got complicated for me. It is to do with the superblock format version used in the array. More detail can be found at this page of the Linux RAID wiki.
To sum up, the array I had was created with the version 0.90 superblock. The version was found by entering
sudo mdadm --detail /dev/md0
The problem, potentially, was that if I grew the array to larger than 2TB it may not work. As quoted by the wiki link above:
The version-0.90 superblock limits the number of component devices within an array to 28, and limits each component device to a maximum size of 2TB on kernel version [earlier than] 3.1 and 4TB on kernel version 3.1 [or later].
Now, Mythbuntu 12.04 runs the 3.2 kernel, so according to that it should be OK supporting up to 4TB. But I wasn't 100% sure on that, and couldn't find any references elsewhere about it. I decided the safest way to go about this was to convert the array to a later version of the superblock, that didn't have that size limitation. Besides, it would save time in the future in case of trying to repeat this with a drive larger than 4TB.
Following the suggestion of the wiki, I decided to update to a version 1.0 superblock, as it would store the superblock information in the same place as the 0.90.
Note: if you are trying this yourself, and the array is already version 1.0 or later, then the command to grow it is just as below (may not want to do it with 0.90 superblock and larger than 2TB):
mdadm --grow /dev/md0 --size=max
Since I was going to change the superblock version, it involved stopping the array and recreating it with the later version.
Once again, to check the details of the array at the moment:
sudo mdadm --detail /dev/md0
Now, since the array is in use by MythTV, I thought it safest to stop the program:
sudo service mythtv-backend stop
Also, I unmounted where the array was mounted:
sudo umount /var/lib/mythtv
Since the data is in an LVM volume on top of the array, I deactivated that as well (the volume is named raid1 in this instance):
sudo lvchange -a n raid1
The array is now ready to be stopped:
sudo mdadm --stop /dev/md0
Now it can be re-created, specifying the metadata (superblock) version, the RAID level, and the number and names of the drives used:
sudo mdadm --create /dev/md0 --metadata=1.0 --level=1 --raid-devices=2 /dev/sdb /dev/sdc
The array will now start resynchronising. This took a number of hours for me, as there were around 770GB of recordings there. The RAID wiki link included --assume-clean in the above command, which would have skipped the resync. I elected to leave it out, for safety's sake.
Progress can be monitored with:
cat /proc/mdstat
The lvm volume can be restarted:
sudo lvchange -a y raid1
and the unmounted volumes can be re-mounted:
sudo mount -a
Check if they are all there with the
mount
command. The mythtv service can also be restarted:
sudo service mythtv-backend start
When the array is recreated, the UUID value of the array will be different. You can get the new value with:
sudo mdadm --detail /dev/md0
Edit the /etc/mdadm/mdadm.conf file, and change the UUID value in it to the new value. This will enable the array to be found on next boot.
Another thing to do before rebooting is to run
sudo update-initramfs -u
I didn't do this at first, and after rebooting, the array showed up named /dev/md127 rather than /dev/md0. Running the above command and rebooting again fixed it for me.
Expanding the array to fill the space available - the lvm part
Quite a long-winded process, isn't it? Using the lvm command to show the lvm physical volumes:
sudo pvdisplay
showed the array was still 1.82TiB (2TB). It needed to be extended. The following command will fill the volume to the available space:
sudo pvresize -v /dev/md0
To check the results, again run:
sudo pvdisplay
Now, running:
sudo vgdisplay
gave the following results for me:
--- Volume group ---
VG Name raid1
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 5
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 3
Open LV 2
Max PV 0
Cur PV 1
Act PV 1
VG Size 2.73 TiB
PE Size 4.00 MiB
Total PE 715397
Alloc PE / Size 466125 / 1.78 TiB
Free PE / Size 249272 / 973.72 GiB
VG UUID gvfheX-ifvl-yW9h-v4L2-eyzs-95fe-sng2oN
Running:
sudo lvdisplay
gives the following result:
--- Logical volume ---
LV Name /dev/raid1/tv
VG Name raid1
LV UUID Dokbch-ZJkg-QmRW-d9vR-wfM8-BFxb-3Z0krs
LV Write Access read/write
LV Status available
# open 1
LV Size 1.70 TiB
Current LE 445645
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 252:0
I have a couple of smaller logical volumes also in this volume group, that I have not shown. That's why there's a bit of a difference between the Alloc PE value in the volume group, and the Current LE value in the logical volume. As you can see from the lines shown in bold text, the volume group raid1 has 249272 physical extents (PE) free, and the logical volume /dev/raid1/tv is currently sized 445645. To use all space, I made the size 249272+445645, which is 694917.
The command to resize a logical volume is lvresize. Logical.
sudo lvresize -l 694917 /dev/raid1/tv
Alternatively, if you want to avoid all the maths, an alternative command is
sudo lvresize -l +100%FREE /dev/raid1/tv
That command just tells lvm to use 100% of the free space. I didn't try it myself (I only found it after running the command before it).
Now, after that has been run, to check the results, enter:
sudo lvdisplay
The results:
--- Logical volume ---
LV Name /dev/raid1/tv
VG Name raid1
LV UUID Dokbch-ZJkg-QmRW-d9vR-wfM8-BFxb-3Z0krs
LV Write Access read/write
LV Status available
# open 1
LV Size 2.65 TiB
Current LE 694917
Segments 2
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 252:0
and
sudo vgdisplay
gives:
--- Volume group ---
VG Name raid1
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 6
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 3
Open LV 2
Max PV 0
Cur PV 1
Act PV 1
VG Size 2.73 TiB
PE Size 4.00 MiB
Total PE 715397
Alloc PE / Size 715397 / 2.73 TiB
Free PE / Size 0 / 0
VG UUID gvfheX-ifvl-yW9h-v4L2-eyzs-95fe-sng2oN
No free space shown; the lvm volume group is using the whole mdadm array, which in turn is using the whole of the two disks.
The final step for me was to grow the partition that is on the logical volume. I had formatted it with XFS, as it is good with large video files. XFS allows increasing size on a mounted partition, so the command used was:
sudo xfs_growfs -d /var/lib/mythtv
Finally, it is complete!
Tuesday, August 21, 2012
Upgrading MythTV to Mythbuntu 12.04 64-bit
As described in the previous post, the time had come to upgrade my MythTV installation. It had been installed using Mythbuntu 10.10, 32-bit. I wanted to move to the most recent version, currently Mythbuntu 12.04. There were two options available to me: upgrading the current installation, or a new install of the latest version, and copying the previous MythTV database over to it. The first option was not too appealing. Doing a distribution upgrade is a fingers-crossed, hope-this-works process a good part of the time - although I have had pretty good fortune with it on my desktop PC. If I were to go this route, I couldn't just upgrade from 10.10 -> 12.04. It would have to be 10.10 -> 11.04 -> 11.10 -> 12.04. Three complete system upgrades in succession, which would likely leave a lot of cruft left over in the installation. Lots of points of failure. The final nail in the coffin was that I wanted to move to a 64-bit installation, to take advantage of the full 4GB of memory that was installed in the system.
So a clean install it was. To prepare, I copied a number of setup files to a safe place that wouldn't be overwritten during the install. Files like:
Not all the files would end up being needed, but I felt safer having them handy, just in case.
The installation process started from a USB stick loaded with the Mythbuntu 12.04 installer, since I don't have an optical drive in it. No room, with three drives already there. I also hooked up a monitor instead of a TV, because that needs extra setup to output to a component connection.
Since there was some left over free space on the SSD, I installed to that, leaving the 10.10 install intact for now. It went remarkably smoothly. One thing I noted was that at the beginning, there is an option to update the installer. I clicked that, and the system seemed to do nothing for quite a while. Opening up a terminal window and running "top" showed that it was in fact doing something, so I waited until it finished. Once done, the installation process could begin. It would have been nice for it to have some sort of indication that it was doing something, though.
Partway through the process, it prompted for what sort of remote control is being used. I selected "Windows Media Center remote", and the thing was set up automatically. Brilliant! Didn't need that LIRC setup file listed above.
To get the system outputting to my TV properly, I just copied the old xorg.conf file to the /etc/X11 directory (I renamed the existing file, in case I needed it again) and rebooted with a sense of hope and anxiety. A minute or so later, the screen came to life! It worked!
The big one, that I was dreading, was getting the RAID array to be seen by the new install. I still consider myself quite the mdadm novice, so I was pleasantly surprised to find that the RAID array was picked up by the new install quite easily - after installing mdadm and lvm2. This command:
sudo mdadm --assemble --scan
was all that was needed for it to scan for any drives, re-assemble the array, and write a new mdadm.conf file. Easy!
Next was seeing if LVM could find the volumes created. Running
sudo lvm pvscan
sudo lvm vgscan
sudo lvm lvscan
detected all the physical volumes, volume groups, and logical volumes, respectively. Mounting the logical volume that held the recordings was successful - I could see them all. Adding the device entry to /etc/fstab seemed to work, eventually. On the first reboot it came up with an error message, mentioning there were serious problems with the mount. Not sure what it was, but a reboot afterwards seemed to make it happy. I had installed xfsprogs, to manage and defragment XFS filesystems; maybe that helped.
Going through some of the MythTV screens brought up some error messages that it couldn't write to the drive - it turned out to be a permissions issue for the files and directories on the array. Entering
sudo chown -R mythtv:mythtv /var/lib/mythtv
changed the ownership back to the mythtv user, and it seemed happy again.
Bringing the previous database over was a painless process as well. I followed the instructions here and here and the new database came over without drama.
So far it all looks good. I may have a tweak of the VDPAU settings to see if playback can be improved any - it looks fine, but the settings have just been carried over from the previous 0.23 version. Things may have changed in the current 0.25 release.
Now that the system is updated to 12.04, which is a Long Term Support (LTS) release of Ubuntu, I won't be caught out with an obsolete version after 18 months like I was with 10.10.
As a side note, one of the main reasons for moving to 64-bit was because the Zotac IONITX-A-U motherboard, with an Atom 330, was only showing 3GB of RAM installed, even though I had two, 2GB sticks in there. I thought this was a 32 bit software issue. After installing the 64-bit OS, the free memory remained the same. Even in the BIOS, it only reported 3072MB. Strange. A bit of searching around revealed this thread on Zotac's supprt forums. As it turns out, if 4GB is installed, 512MB is reserved for system use, and then there is the amount used by the onboard Nvidia ION graphics - which I had set to the maximum allowed 512MB. So only 3GB visible. It's OK, it still runs fine, but it would have been nice to be able to use a little extra.
So a clean install it was. To prepare, I copied a number of setup files to a safe place that wouldn't be overwritten during the install. Files like:
- mdadm.conf, from /etc/mdadm, which had the RAID configuration information.
- xorg.conf, from /etc/X11, which had the custom modeline used to output to my (now ancient) CRT TV.
- ssmtp.conf, from /etc/ssmtp, for email notification in the case of errors.
- apcupsd.conf, from /etc/apcupsd, the setup of the APC UPS monitoring software.
- hardware.conf, from /etc/lirc, used by LIRC to set up the Media Centre remote control.
- the MythTV database password, from /etc/mythtv/config.xml
Not all the files would end up being needed, but I felt safer having them handy, just in case.
The installation process started from a USB stick loaded with the Mythbuntu 12.04 installer, since I don't have an optical drive in it. No room, with three drives already there. I also hooked up a monitor instead of a TV, because that needs extra setup to output to a component connection.
Since there was some left over free space on the SSD, I installed to that, leaving the 10.10 install intact for now. It went remarkably smoothly. One thing I noted was that at the beginning, there is an option to update the installer. I clicked that, and the system seemed to do nothing for quite a while. Opening up a terminal window and running "top" showed that it was in fact doing something, so I waited until it finished. Once done, the installation process could begin. It would have been nice for it to have some sort of indication that it was doing something, though.
Partway through the process, it prompted for what sort of remote control is being used. I selected "Windows Media Center remote", and the thing was set up automatically. Brilliant! Didn't need that LIRC setup file listed above.
To get the system outputting to my TV properly, I just copied the old xorg.conf file to the /etc/X11 directory (I renamed the existing file, in case I needed it again) and rebooted with a sense of hope and anxiety. A minute or so later, the screen came to life! It worked!
The big one, that I was dreading, was getting the RAID array to be seen by the new install. I still consider myself quite the mdadm novice, so I was pleasantly surprised to find that the RAID array was picked up by the new install quite easily - after installing mdadm and lvm2. This command:
sudo mdadm --assemble --scan
was all that was needed for it to scan for any drives, re-assemble the array, and write a new mdadm.conf file. Easy!
Next was seeing if LVM could find the volumes created. Running
sudo lvm pvscan
sudo lvm vgscan
sudo lvm lvscan
detected all the physical volumes, volume groups, and logical volumes, respectively. Mounting the logical volume that held the recordings was successful - I could see them all. Adding the device entry to /etc/fstab seemed to work, eventually. On the first reboot it came up with an error message, mentioning there were serious problems with the mount. Not sure what it was, but a reboot afterwards seemed to make it happy. I had installed xfsprogs, to manage and defragment XFS filesystems; maybe that helped.
Going through some of the MythTV screens brought up some error messages that it couldn't write to the drive - it turned out to be a permissions issue for the files and directories on the array. Entering
sudo chown -R mythtv:mythtv /var/lib/mythtv
changed the ownership back to the mythtv user, and it seemed happy again.
Bringing the previous database over was a painless process as well. I followed the instructions here and here and the new database came over without drama.
So far it all looks good. I may have a tweak of the VDPAU settings to see if playback can be improved any - it looks fine, but the settings have just been carried over from the previous 0.23 version. Things may have changed in the current 0.25 release.
Now that the system is updated to 12.04, which is a Long Term Support (LTS) release of Ubuntu, I won't be caught out with an obsolete version after 18 months like I was with 10.10.
As a side note, one of the main reasons for moving to 64-bit was because the Zotac IONITX-A-U motherboard, with an Atom 330, was only showing 3GB of RAM installed, even though I had two, 2GB sticks in there. I thought this was a 32 bit software issue. After installing the 64-bit OS, the free memory remained the same. Even in the BIOS, it only reported 3072MB. Strange. A bit of searching around revealed this thread on Zotac's supprt forums. As it turns out, if 4GB is installed, 512MB is reserved for system use, and then there is the amount used by the onboard Nvidia ION graphics - which I had set to the maximum allowed 512MB. So only 3GB visible. It's OK, it still runs fine, but it would have been nice to be able to use a little extra.
My MythTV system - the story so far
For the past 18 moths or so I've been running a MythTV system in the lounge, which has been an excellent performer. It has liberated us from TV advertisements and from having to be home in time to watch a particular show. It has been slowly enhanced and upgraded over that time to be quite a capable machine, exceeding what could be purchased from a store.
Following on from one of the earlier build posts, one thing done was purchasing a larger wireless antenna. For under $20, it allowed the antenna to be moved to a position with better reception to the wireless router, and with a stronger signal. There have been very few connection dropouts since putting that in. The eventual goal is to have a hard-wired ethernet connection, but that will be some time down the track if I ever get the house wired up for it.
Another issue was with a hard drive upgrade. Originally with the 2TB Samsung disk, I upgraded it to a Hitachi 5K3000 3TB drive. It ran well for about three months, but then I came down to the lounge one morning and the system wasn't happy. There were drive errors of one kind or another. I grabbed the 2TB Samsung drive again (which had been serving a happy retirement in my desktop PC), and luckily was able to copy all the recordings over to it. It was fortunate that I hadn't filled the extra space either.
So the system was back to its original storage drive, until the warranty fix came back from Hitachi. About three weeks later, a replacecment drive showed up - this time it was a 3TB 7K3000, the next model up. Also, since this happened after the Thailand floods, one of those drives was now worth nearly $400, quite a bit different from the ~$160 I paid.
Now I had a refurbished 3TB drive and a 2TB drive with a year's heavy usage already on it. This made me a little nervous. It was time to move to a RAID1 system. I used the linux mdadm software RAID, with some LVM volumes on top of it. It is a while back now, but the install went OK I can't quite remember the tutorial I used, but these two have quite a lot of information on doing so. The performance hit from running RAID and LVM was not noticeable on the system, either. If desired, you can also set up email notifications if a drive fails or some other problem arises with the array - see here, here and here. One thing to note if you use gmail to send the notifications: if your password has a "#"in it, ssmtp will read the rest of the line as a comment and you'll get all sorts of strange errors. Oh yes, it's best to set up a secondary gmail account to do this, with nothing important in it, since you have to keep the password in a text file.
Since the system worked well, I didn't bother with updating it. It wasn't open to the wider internet (to access via MythWeb). But it was time for a change, and Mythbuntu 10.10 was no longer supported. It was time for an upgrade to a newer version - which will be detailed in another post.
Following on from one of the earlier build posts, one thing done was purchasing a larger wireless antenna. For under $20, it allowed the antenna to be moved to a position with better reception to the wireless router, and with a stronger signal. There have been very few connection dropouts since putting that in. The eventual goal is to have a hard-wired ethernet connection, but that will be some time down the track if I ever get the house wired up for it.
Another issue was with a hard drive upgrade. Originally with the 2TB Samsung disk, I upgraded it to a Hitachi 5K3000 3TB drive. It ran well for about three months, but then I came down to the lounge one morning and the system wasn't happy. There were drive errors of one kind or another. I grabbed the 2TB Samsung drive again (which had been serving a happy retirement in my desktop PC), and luckily was able to copy all the recordings over to it. It was fortunate that I hadn't filled the extra space either.
So the system was back to its original storage drive, until the warranty fix came back from Hitachi. About three weeks later, a replacecment drive showed up - this time it was a 3TB 7K3000, the next model up. Also, since this happened after the Thailand floods, one of those drives was now worth nearly $400, quite a bit different from the ~$160 I paid.
Now I had a refurbished 3TB drive and a 2TB drive with a year's heavy usage already on it. This made me a little nervous. It was time to move to a RAID1 system. I used the linux mdadm software RAID, with some LVM volumes on top of it. It is a while back now, but the install went OK I can't quite remember the tutorial I used, but these two have quite a lot of information on doing so. The performance hit from running RAID and LVM was not noticeable on the system, either. If desired, you can also set up email notifications if a drive fails or some other problem arises with the array - see here, here and here. One thing to note if you use gmail to send the notifications: if your password has a "#"in it, ssmtp will read the rest of the line as a comment and you'll get all sorts of strange errors. Oh yes, it's best to set up a secondary gmail account to do this, with nothing important in it, since you have to keep the password in a text file.
Since the system worked well, I didn't bother with updating it. It wasn't open to the wider internet (to access via MythWeb). But it was time for a change, and Mythbuntu 10.10 was no longer supported. It was time for an upgrade to a newer version - which will be detailed in another post.
Subscribe to:
Posts (Atom)