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=
9SIA54G3RY3726&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 <
cryptworks@gmail.com>
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 <michael@butash.net>
> 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 <kevin@fries-biro.com>
>> 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" <michael@butash.net> 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 <michael@butash.net> 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
(text/plain)