Date: Mon, 20 Nov 2000 08:49:43 -0800 From: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> To: Stijn Hoop <stijn@win.tue.nl> Cc: FreeBSD <freebsd@kiwi-computer.com>, Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca>, stable@FreeBSD.ORG Subject: Re: Removal of Disklabel Message-ID: <200011201650.eAKGoYV69653@cwsys.cwsent.com> In-Reply-To: Your message of "Mon, 20 Nov 2000 17:03:56 %2B0100." <20001120170356.C74393@pcwin002.win.tue.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20001120170356.C74393@pcwin002.win.tue.nl>, Stijn Hoop
writes:
> On Mon, Nov 20, 2000 at 08:58:50AM -0600, FreeBSD wrote:
> > The problem with the fdisk slices is that there is only room for 4 ...
> > disklabel gives us 8, no wait.. 6 if you have a swap and 5 if you don't.
> >
> > I've never been a fan of this. May I make a recommendation (flame away,
> > boys): redo disklabel while we're at it. it seems counter-intuitive to
> > me, as well as wasteful, to make partition "c" the whole disk and skip "d"
> > altogether. IMHO, "da0s1" should refer to the whole disk, "da0s1a" should
> > be the first physical partition, "da0s1b" the second partition, etc. down
> > to "h". This gives us 8 partitions of any type: swap or FS.
>
> Hear, hear! I would really like to see this. Installing FreeBSD is that
> much more confusing due to the two-layered hierarchy... And even more so
> due to the conventions with the partitions (c, d, etc). If we cannot do
> away with the two layers, at least make the second layer more intuitive.
> What argument, other than 'it's been this way for ages' is there for the
> confusing a-h convention? And what arguments are there for disklabel
> on the i386 anyway?
>
> I'd like to see FreeBSD do the same as Linux on the i386 - use only
> the partition table, along with extended partitions. Do away with disklabel
> *on that platform*.
>
> Yes of course the alpha would differ from i386 in disk geometry then. But
> since the differences in setting up the alpha/i386 are already there, why
> the pretense in keeping them 'the same'?
>
> One of the most FAQs I've heard from linux'ees that tried FreeBSD is
> 'why can't I install to an extended partition?' Fact is when I hear that
> question, I also wonder myself...
Extended partitions are the subdivision of one of the four partitions
in the fdisk table. Disklabel does that. We could rename disklabel
slices to extended partitions. IMO for most people the fdisk and
disklabel interfaces (commands) are redundant. All of this should be
done through sysinstall. Just as SVR4 has sysadm, and other O/S's have
condoned and supported by the vendor approaches to sysdmin, we should
encourage the use of sysinstall for all sysadmin activities. Sure keep
fdisk and disklabel around for those of us who like the bits-and-bytes.
The short of it is that sysinstall should have one interface for
configuring disks, not two as it currently does. That one interface
should make the user think that we have a unified disk partitioning
look-and-feel just like NT and Linux do.
To hide the architecture even further, device names in /dev would be
hidden by the use of symlinks or hard links. Those who want to
reference ad0s1a can. The rest of us can use names like disk0a or hd0a
("a" specifies the first FreeBSD partition/slice found on the disk).
The disk0a or hd0a names would be independent of the type of device
driver being used SCSI, IDE, etc., it would just be a generic name.
The current naming convention would become esoteric and could be used
if needed.
In a world where most people don't care about the architecture of an
operating system, I think that this would put a friendlier face on
FreeBSD.
Regards, Phone: (250)387-8437
Cy Schubert Fax: (250)387-5766
Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca
Open Systems Group, ITSD, ISTA
Province of BC
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011201650.eAKGoYV69653>