On 09/27/2014 09:52 PM, lee wrote: > Linux-Fan <Ma_Sys.ma@web.de> writes: >> On 09/22/2014 03:23 AM, lee wrote: >>> Linux-Fan <Ma_Sys.ma@web.de> writes: >>>> On 09/21/2014 08:41 PM, lee wrote: >>>>> Linux-Fan <Ma_Sys.ma@web.de> writes: >>>>>>> On 09/20/2014 04:55 PM, lee wrote: >>> >>> I've seen the smart info show incredible numbers for the hours and for >>> the temperature. Hence I can only guess which of the values are true >>> and which aren't, so I'm simply ignoring them. And I never bothered to >>> try to relate them to a disk failure. When a disk has failed, it has >>> failed and what the smart info says is irrelevant. >> >> I always at least try to read/interpret the SMART data. I consider it >> valuable information, although it is sometimes difficult to interpret. >> (Especially Seagate's Raw Read Error Rate and some other attributes). > > How do you know which of the numbers are correct and which aren't? I always check whether they are plausible. I have recorded my computer usage times and the oldest disk has always been in use. My computer usage times sum around the same as the disk "power-on" and they increase on a daily basis which makes me believe the data is correct. For temperature, it gives me weird results which either means they are in Farenheit or just wrong which is why I am ignoring that data at the moment. Other potentially "bad" things are all zero which I read as "SMART has nothing bad to report" etc. [...] >>> You are using two disks and two unreliable connections at the same time >>> because of the RAID. That increases your chances of a connection going >>> bad *and* of a disk failure: A disk which is just sitting there, like a >>> backup disk, is pretty unlikely to go bad while it sits. A non-existent >>> connection cannot go bad at all. >>> >>> When you don't use RAID but a backup, you are very likely to only lose >>> the changes you have made since the last backup in case a disk fails. >>> When you use RAID, you may lose all the data. >> >> I did not know USB was that unreliable -- I am probably going to >> implement these suggestions soon. > > Above doesn't only apply to USB. You could have bad cabling with SATA > disks and increase your chances to lose data through using RAID with > that as well. Well, but SATA and USB are the only means to connect my HDDs which are available in the newest system. Older systems also have IDE but I do not trust it to be more reliable than SATA. Also, I have never experienced a single loss of connection or anything with SATA. > For the last couple days, I've been plagued by an USB mouse failing. It > would work for while and then become unresponsive. Plug it into another > USB port and it works again for some time. In between, the mouse would > go weird and randomly mark text in an xterm. Use another mouse and it > shows the same symptoms. Use another computer (disks switched over) and > the mouse seems to work, at least for a while. > > I've never seen anything like that before and never had problems with > PS/2 connections. So how reliable is USB? All I can tell is that I have not had any problems with either except for the USB 3.0 "sometimes not recognized" issue which was the reason for starting this thread. [...] >> I am no longer sure of the stability of my solution. I am surely also >> going to try the "one connected, one for backup" variant as it would >> simplify the setup and increase stability. > > Take it as a learning experience :) Sure, that is the reason for most of my private computer usage anyway. [...] >> The data consistency is truly an issue. Still, I do not trust ZFS on >> Linux or experimental Btrfs more than MDADM + scrubbing once per month. > > Btrfs seems to have made some advances, and they have declared that the > format it uses to store data is now unlikely to change. I used it for > backups and it didn't give me any problems. I'm considering to actually > use it. > >> Either of these "advanced" technologies add additional complexity which >> I have tried to avoid so far. I did not expect that USB would prove such >> an additional complexity. > > RAID isn't exactly non-complex. And what's more complex: RAID with LVM > with ext4 or btrfs without LVM and without RAID because it has both > built-in? You can eliminate a hardware RAID controller which can fail > and has the disadvantage that you need a compatible controller to access > your data when it does. You can also eliminate LVM. MDADM + EXT4 combines the both technologies I know best of these mentioned above, which is why I chose to go this way. So far, the complexity of an "internal" RAID configuration has not been an issue to manage while the "external" RAID took an additional parameter in an initscript to work correctly. > What's more reliable? I cannot tell which is why I chose the one I found most simple to setup and maintain. >> In the currently running system, all USB works as reliable as I expect >> it: Devices never lose connection and all work with reasonable latency >> (for me). As the external storage is not accessed very often (I only use >> it for a lot of big files which would otherwise need to be deleted and >> additional VMs) the disks sometimes make a silent "click" when they are >> accessed again. > > Try to enable power management for the USB controllers with powertop and > see what happens. Have a backup ready before you do so. Playing with powertop has been on the TODO list for quite a while. I will certainly try it. > Using the disks for VMs? That's all the more reason to have a server? Well, unlike with "server usage" I normally only run one or two VMs at the same time (not enough RAM could be one of the reasons) while having many different images on my HDDs for testing and learning purposes. [...] >> I have not experienced any keyboard lag yet and I did not know that USB >> required polling. The quad core is rarely completely occupied, which is >> probably why I never experienced such problems yet. > > When you play fast games and are used to PS/2 keyboards and then try an > USB keyboard, you'll notice. They even manufacture USB keyboards which > supposedly use a higher polling frequency to reduce the lag. How silly > is that?! Why not just use PS/2? > > Remember the above mouse problem: These computers are awfully slow, so > perhaps they forget about the mouse. Now put some good load on yours > and see what happens to your USB disks ... I will try to reproduce such a mouse or keyboard issue first because that seems easier to do and requires less preperation in terms of backup (I will do it on a dedicated testing machine). [...] >> As far as I can tell, this integrity check is once a month. The "one >> week" refers to the "one failed boot per week" as a result of not >> recognizing the drive. > > It runs once a week on Fedora. Perhaps once a month isn't enough? I do not know, I am just sticking with the Debian default. [...] >> Compared to what is already in the system (two 160 GB disks and two 500 >> GB disks) the "new" USB disks are actually slightly faster. Good 10k rpm >> or 15k rpm disks will of course be much faster, but I do not have any. > > Hm. Why don't you remove those USB disks from their enclosures and use > them to replace the disks you have built-in? Removing the disks from the case is not covered by the warranty. So as long as the warranty period lasts, I will be careful doing that. If it works past the warranty period, I will think about that. > That would reduce the number of disks you're using, you'd have faster > disks, you wouldn't need a server and you'd have no potential problems > with USB connections. You could even swap the 500GB disks into the > enclosures and use them for backups. Agreed. [...] >> Otherwise, I backup important data (which is luckily not that much) to >> 16 GB CF cards formatted with FAT32 (I have taken measures to keep >> UNIX file permissions and special files like FIFOs etc. intact). > > CF cards? FAT32? Do you have a good idea of how reliable this is? I have had a Windows 95 FAT system from 1996 and it still worked. I trust the CF cards to be my most reliable means of storage because they do not contain mechanical parts, use SLC chips (my failed SSD was using MLC) and are specified for some extended temperature ranges as well as some shock resistance. > People taking pictures on such cards don't seem to be too happy with > their reliability. And FAT was designed for floppy disks which could > store 180kB or so. Do you know how quick FAT is with deleting data when > you check a file system and how easily the FS can get damaged? In terms of file systems, FAT32 is rather simple. And rather than any "data-format" failing, I always worry about the programs failing (or going missing) to read the data when it is necessary. Still, I also think about using an EXT-based system and checking if any Windows programs exist to read them (I have read about, but not tried ext2fsd yet). > My experience with FAT is that it is bound to fail sooner than later. I > never used a CF card, only SD cards, though not much. I haven't seen an > SD card failing yet. The only flash memory which I have seen failing were cheap USB sticks and my SSD. Also, I have heard about cheap SD cards failing. My CF cards have never failed. (But my HDDs have also never failed yet. :) ) Linux-Fan -- http://masysma.lima-city.de/
Attachment:
signature.asc
Description: OpenPGP digital signature