Date: Sun, 17 Feb 2013 00:17:28 +0100 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: "Robert N. M. Watson" <rwatson@FreeBSD.org>, "freebsd-arch@FreeBSD.org Arch" <freebsd-arch@freebsd.org> Subject: Re: FDT on x86 and for non-fdtbus devices. Message-ID: <20130216231728.GC2023@garage.freebsd.pl> In-Reply-To: <E11BFB94-8653-44F5-A3B0-6951170A22A6@xcllnt.net> References: <03A622DA-EFD4-4984-8FC3-CD8B4832C32E@xcllnt.net> <alpine.BSF.2.00.1302141031480.65091@fledge.watson.org> <8606E19D-98A2-4E2C-A9E3-5056C1BAC34E@bsdimp.com> <B0375E90-369C-4F9C-AAB9-2106C7D68623@FreeBSD.org> <E11BFB94-8653-44F5-A3B0-6951170A22A6@xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--QRj9sO5tAVLaXnSD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 14, 2013 at 09:00:25AM -0800, Marcel Moolenaar wrote: >=20 > On Feb 14, 2013, at 6:45 AM, Robert N. M. Watson <rwatson@FreeBSD.org> wr= ote: >=20 > >> But I'm curious why your specific example wouldn't already live in the= FDT for your board.... > >=20 > >=20 > > We want to put hardware configuration parameters in the on-board FDT. > >=20 > > We want to put software configuration parameters in the kernel targeted= for the board. >=20 > /nod >=20 > I think it's a feature to instantiate GEOMs from the FDT. > Creating a mirrored disk configuration when the disks are > already in use cannot in general be done using tasting. > The assumption that the last sector is free is invalid > with GPT and it has created conformance problems for us > already. Being able to construct the gmirror GEOM from the > FDT eliminates the need to scribble meta-data on the disk > and as such allows us to mirror 2 GPT disks at the disk > level without instantaneously becoming non-conformant. Gmirror is not the best example, but gstripe or gconcat could be configured this way. I know gmirror is not the subject here, but for those interested explanation of why gmirror is not the best example is below. The metadata is needed not only for tasting and configuring two disks as a one gmirror provider, but also for other stuff, like: - tracking synchronization progress, - being able to tell which provider is out-of-date (on first write after one of the disks break we bump a counter in other disks metadata, so we can tell when the system is rebooted and disk is available again that it needs synchronization), - being able to tell that system crashed/failed when gmirror was writing and components can be out of sync, - being able to tell which mirror component was offlined by the administrator. etc. Ideally we would also support dirty bitmap that could speed up synchronization and also needs some space (much more than single sector). --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --QRj9sO5tAVLaXnSD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEgE4cACgkQForvXbEpPzRaMACgvMrF3BLehHv0UQs83jU8fZ8h TzsAoIhMSUN3GmjFij8bcL0awaHln9Eu =zsmm -----END PGP SIGNATURE----- --QRj9sO5tAVLaXnSD--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130216231728.GC2023>