The saga continues

[William A. Mahaffey III]

On 10/07/15 22:34, Warren Block wrote:
> On Wed, 7 Oct 2015, William A. Mahaffey III wrote:
>
>> On 10/07/15 19:32, Warren Block wrote:
>>> On Wed, 7 Oct 2015, William A. Mahaffey III wrote:
>>>
>>>>> Please read the warning at the top of that page.  The Handbook 
>>>>> shows the right way of using gmirror(8).  My page on it mirrors 
>>>>> GPT partitions, which is likely to be a problem if one of the 
>>>>> drives ever fails.  If you absolutely have to use gmirror(8) with 
>>>>> GPT, use only one partition per drive.
>>>>>
>>>>
>>>>
>>>> Can I partition the drives using '-s MBR', then mirror some of the 
>>>> partitions & create '-s BSD' slices inside of those mirrors ?
>>>
>>> Ow, my brain.  Why are you simultaneously creating safe data storage 
>>> along with ultra-unsafe data storage?  What is the end goal?
>>>
>>> Multiple mirrors between drive partitions is potentially dangerous. 
>>> Consider that drives often die only a few days or hours apart.  Now 
>>> think of a two-drive system with multiple mirrored partitions.  One 
>>> drive has died.  Put in a new drive, create the multiple partitions 
>>> on it, and add them to the mirrors.  All of them start replicating 
>>> at the same time, putting a big load on the original still-working 
>>> drive.  The drive that is the same age as the drive that failed...
>>
>> Creating the safe storage for the system so I could (hopefully) get 
>> it rebooted & reconstructed if 1 of the 2 HDD's croaks. If your 
>> scenario happens (both HDD's croak almost together, or the 2nd one 
>> croaks under the load of replicating), I'm fried anyway. That also 
>> argues against any mirroring at all, same thing happens if I mirror 
>> both drives as per the handbook.
>
> The difference is that multiple mirrored partitions that are 
> replicating at the same time put both drives under lots of head 
> contention.  It will also make it take much, much longer.

Agreed, naturally I hope to avoid that contingency :-).

>
>>>> Specifically, I would partition each drive into 4 primary 
>>>> partitions, /boot, swap, 1 partition to be mirrored & then sliced 
>>>> up as per the handbook, & 1 partition to be striped & then sliced 
>>>> up ? I would probably mirror /boot as well, if feasible. It seems 
>>>> this might comport w/ all of the restrictions & possible meta-data 
>>>> conflicts, but I am definitely out of my area, hence the questions. 
>>>> TIA & have a good one.
>>>
>>> /boot is a directory in /, the boot partition is just a place to 
>>> store bootcode.  They are separate things.
>>
>> Agreed, bad nomenclature on my part .... it would be boot-partition, 
>> swap, mirrored-partition & striped partition.
>>
>>>
>>> What is the function of the RAID0 here?  Can it be replaced with 
>>> tmpfs or maybe an SSD?
>>
>>
>> To maximize available space for storing movies, etc. I would be 
>> slicing it into 2 slices, for /usr/local & /home. All stuff here 
>> would be backed up elsewhere on the LAN and/or recreatable. I just 
>> want the largest possible pool of GiB's available.
>
> ZFS with a RAIDZ1 is a reasonable compromise.  Three drives instead of 
> two, the space of two drives, any one drive can fail but the array 
> still works.
>


Only 2 SATA slots on the (mini-ITX) mbd, tight case, not much room for 
anything else, thus pretty much stuck w/ 2 HDD's, I think.


-- 

	William A. Mahaffey III

  ----------------------------------------------------------------------

	"The M1 Garand is without doubt the finest implement of war
	 ever devised by man."
                            -- Gen. George S. Patton Jr.