Date: Sat, 20 Oct 2018 11:39:47 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 232463] EBR slice cannot be added partitions to Message-ID: <bug-232463-227-3I6EVKREFk@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-232463-227@https.bugs.freebsd.org/bugzilla/> References: <bug-232463-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D232463 --- Comment #7 from Andrey V. Elsukov <ae@FreeBSD.org> --- (In reply to bourne.identity@hotmail.com from comment #6) > a) > What do you mean 'works well under FreeBSD' when you cannot add/delete any > partitions in the EBR slice ? I mean that it can read EBR scheme and use such partitions. And since there= is no need in such partitions, by default FreeBSD doesn't support modification= of them. FreeBSD supports BSD label and GPT, and can live well without EBR. > b) > Suggesting GPT because EBR is non-functional under FreeBSD adds an unwant= ed > twist. GPT is not what people need. People usually need MBR (particularly > under FreeBSD), which provides multiple benefits: I have several hundreds of FreeBSD installations and none of them use MBR/E= BR. And all works good for me. So, at least I'm and several other people in my company usually don't need MBR. >=20 > 1) GPT has no limit on number of partitions, and a GPT disk is permitted = to > be a jungle. The MBR schema on the other hand is 3 primary partitions (ea= ch > of which can host OS root) + a sub-divisible EBR (which cannot host OS ro= ot). >=20 > 2) MBR permits use of boot0cfg, the tidiest boot manager. >=20 > Unless a disk really is > 2TB, GPT must not be used. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-232463-227-3I6EVKREFk>