Bug 169539

Summary: [geom] [patch] fix ability to run gmirror on MSI MegaRaid (/dev/ar* vs /dev/gm*)
Product: Base System Reporter: Alter <alter>
Component: kernAssignee: freebsd-bugs (Nobody) <bugs>
Status: Open ---    
Severity: Affects Only Me Keywords: patch
Priority: Normal    
Version: Unspecified   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
file.diff none

Description Alter 2012-06-29 11:40:04 UTC
LSI MegaRaid controller
    * always modifies last sector of attached disks.
    * can't boot from disks without its own (LSI) metadata.
    * there is no passthrough option to expose disk as non-raid storage. 
This makes impossible to boot from GMIRROR array on this controller.
Since ar* handle LSI metadata in r/o mode, I can't maintain array without BIOS.
This in unacceptable.
Using gmirror also becomes impossible.

Fix: Fast solution:
http://alter.org.ua/en/soft/fbsd/gmirror/
(patch for CURRENT is attached)
 Update gmirror with special patch. Now it can optionally store its metadata in the previous sector. You can use -o 1 option with 'label' and 'insert' to place gmirror metadata in alternative location.
gmirror attempts to load metadata from last sector. If this attempt fails, it tries previous one. gmirror shall not ovewrite last sector if metadata is stored in previous. So, we have compatibility option for ar*.
 Setup BIOS to use all drives as separate STRIPE arrays (one disk in each one).
    Use gmirror with -o 1 option to setup proper array.
---
Right solution (imho):
I think, would be nice to add some API or library to report presence and location of some known metadata.
Use this API in all RAID tools (atacontrol, gmirror) to check and warn about presence of incompatible matadata on disks.
And (if required to workaroud some hardware issues) place metadata in alternative locations.

Patch attached with submission follows:
How-To-Repeat: 1) config GMIRROR on boot disk
2) reboot
ok, now we have no valid metadata at all (neither gm*, nor ar*)
system cannot boot
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2012-07-16 03:43:17 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-geom

Over to maintainer(s).
Comment 2 Alexander Motin freebsd_committer freebsd_triage 2013-01-15 01:40:23 UTC
I don't think that hacking gmirror to move its metadata is a right
approach to the problem. It will make metadata detection complicated and
depending on some external knowledge. Why just not partition the disks
and not use gmirror on top of partition table? If partition will not use
the last sector of the disk, controller should be happy and gmirror
won't need any hacks.

-- 
Alexander Motin
Comment 3 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 07:58:59 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped
Comment 4 Graham Perrin freebsd_committer freebsd_triage 2022-10-17 12:35:55 UTC
Keyword: 

    patch
or  patch-ready

– in lieu of summary line prefix: 

    [patch]

* bulk change for the keyword
* summary lines may be edited manually (not in bulk). 

Keyword descriptions and search interface: 

    <https://bugs.freebsd.org/bugzilla/describekeywords.cgi>