Date: Sat, 19 Aug 2000 21:09:02 +0200 From: Siegbert Baude <siegbert.baude@gmx.de> To: "freebsd-questions@freebsd.org" <freebsd-questions@freebsd.org> Subject: Need information for FAQ about: Layout of slices, using extended partitions; fdisk information about non-FBSD slices Message-ID: <399EDB4E.684F6CD4@gmx.de>
next in thread | raw e-mail | index | archive | help
Hello,
first I apologize for the length of this mail. But I searched the list and
similar questions are asked often, but got never any in-depth answers. I would
like to make this thread end in a FAQ about treating extended slices in FreeBSD.
So I spent the last week gathering information and checking with FreeBSD tools.
If the things I claim about fdisk, donīt root in my dumb stupidity, maybe we can
improve the behaviour of fundamental tools also. So please be patient and read
the whole stuff, I really digged into this and acquainted myself with some
fundamental articles about partition tables, so I think my points are worth
thinking. Maybe somebody with indepth sight can shed some light onto this.
I marked the questions with I) II) ... . Things between are just thoughts and
maybe necessary information. Proposals to improve things will end my rant.
What I did until now:
I tried to use an extended slice on my second IDE IBM disk for FreeBSD. Until
now it was used as FAT32. Things work with fdisk, disklabel, MAKEDEV, newfs, but
I stumbled over some fundamental points I would like to clarify.
To learn how things are done, I looked at my first disk (also IBM IDE), which
was sliced by Linux fdisk. I think there are some inconsistencies in the output
of fdisk, although everything works (if you really know what to do; things
arenīt very easy until now).
The CHS-translation detected by the kernel is different to my BIOS settings.
From the 3 possibilities offered by my disk (LBA, LARGE, NORMAL) I chose LBA in
the BIOS, which is explicit:
C 790 H 255 S 63
But my dmesg:
ad0: 6197MB <IBM-DHEA-36481> [12592/16/63] at ata0-master using UDMA33
I) Are this CHS-values used for anything within FreeBSD? The dmesg output below
(marked with ***) makes me believe, that everything is calculated in LBA. But
then fdisk can be fed with CHS-values only, to explicitly define end and
beginning of a slice (but there you can also define your own CHS translation, so
things will work; but they wonīt by default).
II) How can I tell the kernel to use the correct mapping? LINT says itīs
possible for the old wd driver, but how to achieve with the atadisk driver?
III) C/H/S 12592/16/63 is the LARGE-proposal of my disk. Why does the kernel
choose this one and not the LBA-translation as in the BIOS? The disk was
formatted with LBA, so the relevant entries in the MBR should refer to this
logical geometry (I didnīt check the actual entries in the MBR with a disk
editor, but Ranish Partition Manager and Linux fdisk both show the entries of
the primary slices like the following (I really would appreciate an output like
this with some FBSD tools; are there any?):
Cyl Head Sect Cyl Head Sect
Pri1 Windows FAT-32 0 1 1 65 254 63
Pri2 Windows NTFS 66 0 1 131 254 63
Pri3 FreeBSD 132 0 1 197 254 63
Pri4 Extended 198 0 1 789 254 63
Log5 Linux ext2fs 198 1 1 213 254 63
Ext6 Extended 214 0 1 279 254 63
Log6 BeOS 214 1 1 279 254 63
Ext7 Extended 280 0 1 411 254 63
Log7 Linux ext2fs 280 1 1 411 254 63
Ext8 Extended 412 0 1 477 254 63
Log8 Linux ext2fs 412 1 1 477 254 63
Ext9 Extended 478 0 1 543 254 63
Log9 FreeBSD 478 1 1 543 254 63
Ext10 Extended 544 0 1 675 254 63
Log10 Windows FAT-32 544 1 1 675 254 63
Ext11 Extended 676 0 1 773 254 63
Log11 Windows Fat-32 676 1 1 773 254 63
Ext12 Extended 774 0 1 789 254 63
Log12 Linux Swap 774 1 1 789 254 63
III continued) Out of the end Heads and Sector information (254/63), you can see
the mapping of the disk (254+1=255/63), but nevertheless the kernel uses 16/63.
Why?
IV) With which tool can you achieve the piece of information, you will get, when
booting with -v option, as printed below? Without rebooting, of course, as you
normally donīt like to reboot just to get some system information. Booting
normal i.e. without -v option will hide this piece of information.
I checked this with Ranish Partition Manager and Linux fdisk, all give identical
output. Everything is in perfect match with the table written above:
***
ad0s1: type 0xb, start 63, end = 1060289, size 1060227 : OK
ad0s2: type 0x7, start 1060290, end = 2120579, size 1060290 : OK
ad0s3: type 0xa5, start 2120580, end = 3180869, size 1060290 : OK
ad0s4: type 0x5, start 3180870, end = 12691349, size 9510480 : OK
ad0s5: type 0x83, start 3180933, end = 3437909, size 256977 : OK
ad0<extended>: type 0x5, start 3437910, end = 4498199, size 1060290 : OK
ad0s6: type 0xeb, start 3437973, end = 4498199, size 1060227 : OK
ad0<extended>: type 0x5, start 4498200, end = 6618779, size 2120580 : OK
ad0s7: type 0x83, start 4498263, end = 6618779, size 2120517 : OK
ad0<extended>: type 0x5, start 6618780, end = 7679069, size 1060290 : OK
ad0s8: type 0x83, start 6618843, end = 7679069, size 1060227 : OK
ad0<extended>: type 0x5, start 7679070, end = 8739359, size 1060290 : OK
ad0s9: type 0xa5, start 7679133, end = 8739359, size 1060227 : OK
ad0<extended>: type 0x5, start 8739360, end = 10859939, size 2120580 : OK
ad0s10: type 0xb, start 8739423, end = 10859939, size 2120517 : OK
ad0<extended>: type 0x5, start 10859940, end = 12434309, size 1574370 : OK
ad0s11: type 0xb, start 10860003, end = 12434309, size 1574307 : OK
ad0<extended>: type 0x5, start 12434310, end = 12691349, size 257040 : OK
ad0s12: type 0x82, start 12434373, end = 12691349, size 256977 : OK
***
Now compare with the following output of fdisk:
su-2.04# fdisk /dev/ad0s4
fdisk: can't get disk parameters on /dev/ad0s4; supplying dummy ones
******* Working on device /dev/ad0s4 *******
parameters extracted from in-core disklabel are:
cylinders=1 heads=1 sectors/track=1 (1 blks/cyl)
parameters to be used for BIOS calculations are:
cylinders=1 heads=1 sectors/track=1 (1 blks/cyl)
Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 131,(Linux filesystem)
start 63, size 256977 (125 Meg), flag 0
beg: cyl 198/ sector 1/ head 1;
end: cyl 213/ sector 63/ head 254
The data for partition 2 is:
sysid 5,(Extended DOS)
start 257040, size 1060290 (517 Meg), flag 0
beg: cyl 214/ sector 1/ head 0;
end: cyl 279/ sector 63/ head 254
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>
su-2.04# fdisk /dev/ad0s5
fdisk: can't get disk parameters on /dev/ad0s5; supplying dummy ones
******* Working on device /dev/ad0s5 *******
parameters extracted from in-core disklabel are:
cylinders=1 heads=1 sectors/track=1 (1 blks/cyl)
parameters to be used for BIOS calculations are:
cylinders=1 heads=1 sectors/track=1 (1 blks/cyl)
Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
<UNUSED>
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>
su-2.04#
V) According to dmesg, the ext2fs lives in ad0s5 not in ad0s4. This is the
before-mentioned inconsistency of fdisk output (or is this an inconsistency in
my partition table? In FreeBSDīs file system design?).
VI) Why canīt fdisk get disk parameters in the above examples? Is this normal?
VII) Why does fdisk speak in each its output and its manpage of partitions, when
UNIX is used to speak of slices?
VIII) fdisk applied on slices works only for FBSD slices. With other types it
will produce garbage (compare the examples below). Said positive it works on all
FBSD-partitons, ad0 itself (you will get the partition table within the MBR) and
ad0s4 (the first extended slice). I think the reason for this is (just an
assumption, reading C-code especially about file systems is horrifying for me,
at least until now) that fdisk treats the beginning of the slice, given as
argument to it, as slice table, which is working fine for ad0 and ad0s4, because
those two actually contain a slice table. But for the others this is not true,
because e.g. ad0s6 starts on 214/1/1 and not on 214/0/1 where the partition
table entry resides. Astonishing enough this works for BSD partitions e.g. ad0s3
and ad0s9 (how do you achieve this? Is the partition table information repeated
at the beginning of ad0s9? Or does fdisk work in a completely different manner
than I assume?).
Look at:
su-2.04# fdisk ad0s9
******* Working on device /dev/ad0s9 *******
parameters extracted from in-core disklabel are:
cylinders=65 heads=255 sectors/track=63 (16065 blks/cyl)
parameters to be used for BIOS calculations are:
cylinders=65 heads=255 sectors/track=63 (16065 blks/cyl)
Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
<UNUSED>
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
sysid 165,(FreeBSD/NetBSD/386BSD)
start 63, size 1060227 (517 Meg), flag 80 (active)
beg: cyl 478/ sector 1/ head 1;
end: cyl 543/ sector 63/ head 254
su-2.04#
This is fine (note also the correct CHS translation), but compare with:
su-2.04# fdisk ad0s6
fdisk: can't get disk parameters on /dev/ad0s6; supplying dummy ones
******* Working on device /dev/ad0s6 *******
parameters extracted from in-core disklabel are:
cylinders=1 heads=1 sectors/track=1 (1 blks/cyl)
parameters to be used for BIOS calculations are:
cylinders=1 heads=1 sectors/track=1 (1 blks/cyl)
Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 138,(unknown)
start 1726010214, size 3224462993 (1574444 Meg), flag c3
beg: cyl 429/ sector 38/ head 81;
end: cyl 258/ sector 12/ head 14
The data for partition 2 is:
sysid 89,(unknown)
start 544370546, size 1684107116 (822317 Meg), flag ad
beg: cyl 200/ sector 1/ head 102;
end: cyl 370/ sector 5/ head 195
The data for partition 3 is:
sysid 79,(QNX 4.2 Tertiary)
start 1936028272, size 1851859059 (904228 Meg), flag 69
beg: cyl 288/ sector 39/ head 110;
end: cyl 32/ sector 59/ head 83
The data for partition 4 is:
sysid 121,(unknown)
start 1650815520, size 779382639 (380557 Meg), flag 79
beg: cyl 357/ sector 43/ head 32;
end: cyl 367/ sector 52/ head 32
su-2.04#
This is just plain garbage. There is a BeOS filesystem on this slice, but itīs
the same for all other slices with different file systems.
Linuxī ext2fs is somehow special, look at:
su-2.04# fdisk ad0s7
fdisk: can't get disk parameters on /dev/ad0s7; supplying dummy ones
******* Working on device /dev/ad0s7 *******
parameters extracted from in-core disklabel are:
cylinders=1 heads=1 sectors/track=1 (1 blks/cyl)
parameters to be used for BIOS calculations are:
cylinders=1 heads=1 sectors/track=1 (1 blks/cyl)
fdisk: invalid fdisk partition table found
Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
<UNUSED>
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
sysid 165,(FreeBSD/NetBSD/386BSD)
start 1, size 0 (0 Meg), flag 80 (active)
beg: cyl 1/ sector 1/ head 0;
end: cyl 0/ sector 0/ head 0
su-2.04#
VIII continued) This is the same for all slices with ext2fs on it except ad0s5.
I donīt understand this output. Why is FBSD assuming an ufs on it? Why is there
no garbage in the output of ad0s5? Are there by accident only zeros in the first
head of the Linux root file system?
Either fdisk should state, that it canīt work on unknown filesystems or even
better to MHO, for logical slices it should evaluate the containing extended
slice. That is for ad0s6 214/0/1 instead of 214/1/1. What really would make
sense, let ad0s6 start on 214/0/1: then you can treat it exactly like ad0 or
ad0s4. The output of fdisk ad0s6 should then be exactly like that of fdisk ad0s4
(i.e. treating the file system as partition 1 and the extended slice, containing
the next file system, as partition 2).
iX) One question left just for curiosity: Why are FreeBSD partitions always
partition 4 within a fdisk output? Wouldnīt partition 1 be more natural?
X) This is a good number for a final question: What was the historical reason
for the design decision to treat ad0s5 as separate slice? In extended slices as
I understand this, you have a chained list of partition tables, each containing
a file system and another extended slice, containing a file system and ...
ad0s4 and ad0s5 should be only one slice. So you should get all information by
querying ad0s4, exactly like ad0s6, ad0s7, ad0s8,...
ad0s5 is dispensable. To be consistent there would be the other possibility of
introducing additional separate numbers for the extended slices themselves (i.e.
without the contained files systems; they would be only one head big then). This
isnīt very useful indeed, as extended slices would be an inconsistent model
compared to primary slices then.
Also I would suggest, that you specify explicit begin and end addresses within
fdisk in LBA form (i.e. is in absolute sectors) in addition to the already
possible CHS-form.
Hope somebody read until here, thanks very much for your patience; I hope we can
improve FreeBSD a little bit, at least the documentation of things, if my
critical points lack any substance.
Ciao
Siegbert
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?399EDB4E.684F6CD4>