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
Responsible Changed From-To: freebsd-bugs->freebsd-geom Over to maintainer(s).
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
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
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>