On 11/10/2013 5:08 PM, Ivan Lezhnjov IV wrote: > > On Nov 10, 2013, at 10:12 PM, Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx> wrote: > >> USB is not a storage protocol. USB devices often disconnect/reconnect >> for no apparent reason. We see this frequently with the little vendor >> USB disk drives (Seagate/WD) and also generic disk enclosures. USB is >> not a proper protocol for md/RAID storage. You may have continual >> problems with this setup. >> >> If the laptop has an eSATA port use eSATA. If not, drop in an eSATA >> PCMCIA card. This should be much more reliable than USB for this >> application. > > Actually, it's a good piece of advice. Now all I need is to figure out if I I can do this with the hardware I've got. > > However, I feel compelled to say that my USB drives (I have had several… 4 to be precise, now 5) have been incredibly reliable throughout all these years. No connection problems whatsoever, no flakiness/flapping of any kind. Very solid and reliable as for a home, midrange 7 years old laptop and three 7 years old drives. I've been using them for all sorts of things, from backups to torrents and storing virtual machine disk images, etc. Very reliable. The only concern I have is that performance sometimes may not be enough, but by and large it is not a problem for me and so I get by just fine. > > Installing an eSATA PCMCIA card is actually a great idea, and I almost falmpaced when I realized I could've probably resolved performance issues long time ago and the solution was in front of me all this time, but then again the problem was from a pressing character and so I have been really content most of the time with what I have. > >> >>>> Also, I see little/no value in running a scheduled mdadm check on a >>>> RAID1 array. Any problems with RAID1 will be due to one of the disks >>>> beginning to fail in some mode, usually requiring sector relocation. >>>> Most drives do this automatically until they run out of spare sectors, >>>> at which point md will throw write errors. Monitoring SMART data and/or >>>> running SMART self analysis on a schedule is much more effective here, >>>> as you will become aware of a problem sooner, and have the opportunity >>>> to correct it before it shows up in md. >>> >>> Bare with me, I know very little about how RAID works so I can sometimes make totally absurd statements. That being said, I intend to monitor SMART values and I'm wondering now why does it make sense to run check on other types of RAID? I assume 5/6/10 mostly? >>> >>> I'm also wondering if it is advised to run check with filesystem mounted and in use, or unmounted? >> >> Instead of using a connection method known to cause problems with >> storage, and then attempting to mitigate such damage with array/fs >> checks after the fact, why not simply avoid the problem in the first >> place? Use eSATA, or build/buy a little NFS/Samba NAS filer. >> > > As I said in my particular configuration it is a pretty solid connection. You've been lucky so far. I hope your luck holds. > No experience with NAS filers here, but I'm definitely looking this option up as well (already googled it up and reading a description). Network Attached Storage, A.K.A a dedicated file server "appliance". "NAS" is a catch-all term these days for a dedicated file serving device, whether NFS, Samba, Windows CIFS, etc. I mentioned this option because it gives you a dedicated storage server, and decouples the sleep mode of your laptop from your bulk storage. There are DIY kits and full retail NAS boxen on the market that use very little power. Here you would configure the drives to spin down, but not put the system into sleep, as the mainboard uses less than 10W anyway. > What about filesystem state? Does it matter if a filesystem is mounted when check is run? I'm not an EXT user. See "man e2fsck". With XFS you can check while mounted using "xfs_repair -n [device]", but no repairs will be performed, you simply get a report. To repair a damaged XFS filesystem use the same command sans "-n" on the unmounted filesystem. xfs_repair will abort if the filesystem is mounted, and "-n" is not specified. xfs_repair is not to be automated via script/cron. It is only to be run if/when errors are encountered, usually after a crash, power loss, controller failure, etc. -- Stan -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
