The little booger has TB2 and USB3 so something like http://www.newegg.com/Product/Product.aspx?Item=9SIA4P03C27102 would work pretty well for large scale storage expansion. On Tue, Dec 20, 2016 at 3:28 PM, Michael Butash wrote: > Not overly familiar with the macs, but as long as it has a real usb3 or > higher port, I'd consider something like this externally to your 2 internal > spinners, usb 3+ to m.2/nvme drive adapter: > > http://www.newegg.com/Product/Product.aspx?Item=9SIA54G3RY37 > 26&cm_re=m.2_usb-_-9SIA54G3RY3726-_-Product > > Usb3 is 3-4 gigabit practical speed in theory and should sustain decent > enough i/o to make use of that. If it's new enough to have a thunderbolt > 3/usb3.1 connection, those are supposedly 10 gigabit capable for roughly 2x > the throughput. > > Maybe Eric should head to west texas and sue them for infringement, with > Oyen Tech. ;) > > This looked nifty too for thunderbolt3/usb3.1... > > http://www.newegg.com/Product/Product.aspx?Item= > N82E16817245003&cm_re=m.2_usb-_-17-245-003-_-Product > > -mb > > On Tue, Dec 20, 2016 at 1:55 PM, Stephen Partington > wrote: > >> I have done it with my LVMcache based solution without issue. Currently >> am running that on a Mac mini server If i could get a pair of spinners in >> there with an SSD cache i would. >> >> >> On Tue, Dec 20, 2016 at 1:36 PM, Michael Butash >> wrote: >> >>> How does one handle redundant disks *properly* or *officially* with EFI? >>> >>> First/Last time I dealt with EFI was an asus that had 2x SSD's (factory >>> raid 0[!]) that I intended to raid 1 for redundancy vs. performance. It >>> had no legacy boot option at all (shame, asus), so I was forced to work >>> with it. I eventually got my recipe up on it with mdadm, crypto, and lvm >>> with ubuntu after weeks of fiddling with it, but never really figured out a >>> better way to deal with efi partition. I had setup a cronjob to rsync the >>> efi directory, never really tested the actual failure scenario and/or >>> recovery however before I gave up on the laptop otherwise (and job). >>> >>> Maybe that is/was good enough, just wasn't sure how well the efi bios >>> would switch up disks like that, as something at the time made me believe >>> it wouldn't. I've read efi is somewhat fakeraid aware, perhaps that's an >>> option since mdadm works with fakeraids too... >>> >>> Surely I'm not the only one to do redundant disks in desktops, but do >>> seem to be one of an odd few. >>> >>> -mb >>> >>> On Tue, Dec 20, 2016 at 12:06 PM, Kevin Fries >>> wrote: >>> >>>> I suspect the issue was more with UDev and those fancy new drives. I >>>> just wiped then installed Arch on a brand new HP laptop with GPT, zero >>>> issues. I especially like the lack of a separate /boot partition by >>>> reusing the EFI/GPT boot sector. >>>> >>>> Personally, my install was very straightforward and stable as hell. >>>> >>>> Kevin >>>> >>>> On Dec 20, 2016 9:13 AM, "Michael Butash" wrote: >>>> >>>>> I agree, this is why I keep separate /usr partitions, both to allow >>>>> for growth, and to monitor my growth. Another weird thing Arch has such a >>>>> difficult time booting with a separate /usr, more like the dev's ass-u-me >>>>> again no one will *ever* do this... >>>>> >>>>> I started doing it as a means of checks for watching growth over the >>>>> years. In the old days of 8.04, usually a 4gb partition for /usr was fine, >>>>> and less than a gig for actual root (/). Now I fill /usr with at least 6gb >>>>> of data on install it seems, 7-8gb is more the norm. >>>>> >>>>> Use of GPT is/was really trying to keep up with tech, where early days >>>>> of SSD, fdisk was terrible about alignment, where most things can and still >>>>> do say to use GPT. Just no one tells you it is inherently broken still on >>>>> most platforms to consider booting off of. >>>>> >>>>> I'd be more inclined to try EFI, but I'm fond of consistent raid >>>>> approaches, even for boot partitions, where the inflexible FatFS nature of >>>>> EFI partition just rubs me the wrong way as it can't be made natively >>>>> redundant like I can with /boot being on mdraid partitions happily booting >>>>> linux otherwise. Curious what others do with redundancy around EFI desktop >>>>> drives... >>>>> >>>>> Even without another shed of M$ on here, it still finds a way to screw >>>>> things up. >>>>> >>>>> -mb >>>>> >>>>> On Tue, Dec 20, 2016 at 12:09 AM, Steve Litt < >>>>> slitt@troubleshooters.com> wrote: >>>>> >>>>>> On Mon, 19 Dec 2016 23:17:38 -0700 >>>>>> Michael Butash wrote: >>>>>> >>>>>> > I really had no idea GPT was such an anomaly still. Everything I >>>>>> > read was like "just do it!". Not. >>>>>> >>>>>> At this point in time, laptop hard disks still aren't big enough to >>>>>> require EFI, and desktops have multiple disks. So what I do on laptops >>>>>> that can still do MBR is MBR format the hard disk. >>>>>> >>>>>> With my daily driver desktop, with a 4TB disk, and a 3TB disk, and a >>>>>> 256GB SSD, I MBR boot to the SSD, which also contains the whole /usr >>>>>> and /etc tree for easy bootability in these days of symlinked /usr. So >>>>>> I get the advantages of GPT on my large disks, the simple booting of >>>>>> MBR on my SSD: It works fast and beautifully. >>>>>> >>>>>> SteveT >>>>>> >>>>>> Steve Litt >>>>>> December 2016 featured book: Rapid Learning for the 21st Century >>>>>> http://www.troubleshooters.com/rl21 >>>>>> --------------------------------------------------- >>>>>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org >>>>>> To subscribe, unsubscribe, or to change your mail settings: >>>>>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss >>>>> >>>>> >>>>> >>>>> --------------------------------------------------- >>>>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org >>>>> To subscribe, unsubscribe, or to change your mail settings: >>>>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss >>>>> >>>> >>>> --------------------------------------------------- >>>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org >>>> To subscribe, unsubscribe, or to change your mail settings: >>>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss >>>> >>> >>> >>> --------------------------------------------------- >>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org >>> To subscribe, unsubscribe, or to change your mail settings: >>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss >>> >> >> >> >> -- >> A mouse trap, placed on top of your alarm clock, will prevent you from >> rolling over and going back to sleep after you hit the snooze button. >> >> Stephen >> >> >> --------------------------------------------------- >> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org >> To subscribe, unsubscribe, or to change your mail settings: >> http://lists.phxlinux.org/mailman/listinfo/plug-discuss >> > > > --------------------------------------------------- > PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org > To subscribe, unsubscribe, or to change your mail settings: > http://lists.phxlinux.org/mailman/listinfo/plug-discuss > -- A mouse trap, placed on top of your alarm clock, will prevent you from rolling over and going back to sleep after you hit the snooze button. Stephen