Bug 169539 - [geom] [patch] fix ability to run gmirror on MSI MegaRaid (/dev/ar* vs /dev/gm*)
Summary: [geom] [patch] fix ability to run gmirror on MSI MegaRaid (/dev/ar* vs /dev/gm*)
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-06-29 11:40 UTC by Alter
Modified: 2017-12-31 22:29 UTC (History)
0 users

See Also:


Attachments
file.diff (16.68 KB, patch)
2012-06-29 11:40 UTC, Alter
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
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 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