On Tue, Jul 27, 2010 at 8:44 PM, <elekktrett...@exemail.com.au> wrote:
> So, what is the real world advantage of using disklabel, that can't be > done with GPT on 99.99% of all OS install? that is worth breaking > compatibility with other *BSDs - each BSD implements disklabel > differently- and other OSs like Linux - doesn't use disklabel at all but > for Linux to support reading/writing to HAMMER or UFS, it would have to > implement some basic disklabel support. > I don't think the last part is true -- presenting block devices is different that the file systems which live on them and I doubt there would be significant roadblocks to creating UFS or HammerFS on the LVM's which have been imported. Also, if Linux wants to import *BSD's block devices, that's a Linux problem, not *BSD's. That being said, FreeBSD's implementation of gpart is quite smooth IMO although there is no installer support yet and as was noted earlier booting from GPT is a new animal. Universally recognizable block devices like gpt creates I think will grow in importance, and I guess that's also part of why LVM made it's way into Dragonfly although I am curious to know why GEOM wasn't chosen. It's both more powerful, and easier to use IMO. Some examples of that would be gmirror, glabel, gstripe, HAST, etc -- all easier than the Linux equivalents. The mdadm stuff is reliable, but a real PITA. For me anyways, including more GPL tools is a turnoff. As said earlier about something else, I'm sure the work will not get done and there are lots of other things to worry about. If someone has the time and knowledge, would you comment on any difficulties there might be importing GEOM? My feeble C skills are woefully inadequate, so it would be nice to have a rough map of what such a project entails, especially the Danger, Will Robinson markers. If GEOM where to be completed, gpart should be useable too then only the boot bits need to be solved. -- Adam Vande More
