Guys Without wishing to sound like the list police (no-one expects the list police!!) this has drifted off topic into a fairly unimportant area.....I've made my decision and will live with the consequences for now. As I'm currently 10 hours into a circa 40 hour 20TB data copy you can all rest assured nothing short of a catastrophic failure is going to change the current setup......when I get another test box in a couple of weeks I'll revisit. Until then thanks for all the help but can we let this lie please. Tony On 26 May 2015 at 21:11, Wols Lists <antlists@xxxxxxxxxxxxxxx> wrote: > On 26/05/15 15:08, Mikael Abrahamsson wrote: >> On Tue, 26 May 2015, Another Sillyname wrote: >> >>> Very easy to understand......any way that requires entering the swaps >>> into /etc/fstab therefore means that if any drive and it's contained >>> swap fails the reboot can fail (plus the overhead of all those uuid >>> numbers in fstab). My way means that as the swaps don't get loaded >>> unless the drive is alive the reboot has more resilience. >> >> If you have RAID1 for swap, you only need a single component drive to >> work for the RAID1 to be able to start. It also means any drive can fail >> and your swap information still works. > > And you're wasting a lot of disk space. What's important to you (that a > live swap disk shouldn't fail) is not important to me and doesn't seem > to be important to Another Sillyname. > > My disk drives have 32Gb swap partitions. Overkill? Dunno. But I'd > rather linux raid 0's them for 64Gb swap than mdadm raid 1's them for > 32Gb swap. I have a couple of 20Gb tmpfs partitions :-) > > I don't know why Another Sillyname wants to chain his swap partitions, > but it's his choice. Maybe like me, his system gets rebooted a couple of > times a day, and failure to start is a far more real risk than failure > in use. He's running Fedora - that seems likely then ... > > Cheers, > Wol -- 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
