Arch migration (success!!)

Tue Dec 20 16:38:08 MST 2016

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 <michael at butash.net> 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 <cryptworks at 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 at 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 at 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 at 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 at troubleshooters.com> wrote:
>>>>>
>>>>>> On Mon, 19 Dec 2016 23:17:38 -0700
>>>>>> Michael Butash <michael at 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 at 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 at 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 at 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 at 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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.phxlinux.org/pipermail/plug-discuss/attachments/20161220/60fe5f15/attachment.html>