# difference between partitions and slices in FreeBSD context



## m4rtin (Aug 20, 2011)

I installed _FreeBSD 6.4_ as an only operating system to a physical 80GB HDD and made following slices and partitions:


```
1G for / partition - ad0s1a
1G for swap - ad0s1b
1G for /tmp - ad0s1d
1G for /config - ad0s1e
5G for /var - ad0s1f
```

As I understand, a *slice* in FreeBSD context is a division of disk, which is written to MBR. In the example below, there is only one slice(_s1_) created as I understand? Partition should be a division of a slice. In my example there are four partitions: a, b, d, e and f. How to understand this? And where are those partitions defined in the system? Not in the MBR partition table I guess :\


----------



## Beastie (Aug 20, 2011)

m4rtin said:
			
		

> I installed _FreeBSD 6.4_


Any reason you chose a 3 year old branch that is not supported anymore? Just curious.



			
				m4rtin said:
			
		

> ```
> 1G for / partition - ad0s1a
> 1G for swap - ad0s1b
> 1G for /tmp - ad0s1d
> ...


/usr is usually given a separate partition. And unless you're planning to have a server with quite a few databases and a lot of logs, /var should probably be much smaller than 5G. Also, what's /config for?



			
				m4rtin said:
			
		

> As I understand, a *slice* in FreeBSD context is a division of disk, which is written to MBR.


Correct. It's the same as "BIOS partition" and there are 4 of them available in a standard MBR.



			
				m4rtin said:
			
		

> In the example below, there is only one slice(_s1_) created as I understand?
> 
> Partition should be a division of a slice.


Yes.



			
				m4rtin said:
			
		

> In my example there are four partitions: a, b, d, e and f.


That's five. The swap partition is a partition too. It just doesn't have a file system like the rest of them.



			
				m4rtin said:
			
		

> How to understand this?


What exactly?



			
				m4rtin said:
			
		

> And where are those partitions defined in the system? Not in the MBR partition table I guess :\


In the BSD (disk)label, VBR (Volume Boot Record), first block of the slice.


----------



## jem (Aug 20, 2011)

It's common practice in FreeBSD to encapsulate a bsdlabel inside an MBR slice, to retain compatibility with other operating systems that only understand MBR, i.e. Microsoft's OS's.

If you're running FreeBSD exclusively on a system, you can do away with MBR slices and bsdlabel the disk directly, resulting in partition names like ad0a, ad0d, etc.

This is called "dangerously dedicated" mode, which is a bit of a dramatic label and might scare people away from using it unnecessarily.  It was only dangerous if Windows was let anywhere near it.  Unfortunately, the ability to set up dangerously dedicated mode was removed from sysinstall some time ago so you can only set it up if you do a manual installation using Fixit mode.


As the previous poster mentioned, you really should set up a seperate /usr partition.  At the moment /usr is part of your root filesystem, which is only 1GB.  It must be almost full already.


----------



## Bunyan (Aug 20, 2011)

I have an 80 Gb hard disc and this is my label

```
# /dev/ad0s1:
8 partitions:
#        size   offset    fstype   [fsize bsize bps/cpg]
  a:  2097152        0    4.2BSD        0     0     0 
  b:  6668288  2097152      swap                    
  c: 160086465        0    unused        0     0         # "raw" part, don't edit
  d:  4194304  8765440    4.2BSD        0     0     0 
  e: 102400000 12959744    4.2BSD        0     0     0 
  f: 44726721 115359744    4.2BSD        0     0     0
```

The /tmp dir is hidden in the SWAP partition.


----------



## m4rtin (Feb 13, 2012)

*Beastie*,

I use _FreeBSD 6.4_ for JUNOS. This explains the partitioning as well  Juniper routers (at least _M_ and _MX_ series) keep their configuration files and rescue configuration file on a separate partition which is mounted to _/config_.


*jem*,

I think I understand what you mean- slice in _FreeBSD_ terminology is a _primary partition_ in MBR which has _FreeBSD_ partitions encapsulated in it. Am I correct? For example if I boot up the _Ubuntu LiveCD_ in my _FreeBSD_ machine, the MBR looks following:


```
root@ubuntu:~# fdisk -lu

Disk /dev/sda: 123.5 GB, 123522416640 bytes
255 heads, 63 sectors/track, 15017 cylinders, total 241254720 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0f800000

  Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *          63   241248104   120624021   a5  FreeBSD
root@ubuntu:~# dd if=/dev/sda bs=512 count=1 2>/dev/null | hexdump -C
00000000  fc 31 c0 8e c0 8e d8 8e  d0 bc 00 7c 89 e6 bf 00  |.1.........|....|
00000010  06 b9 00 01 f3 a5 89 fd  b1 08 f3 ab fe 45 f2 e9  |.............E..|
00000020  00 8a f6 46 bb 20 75 08  84 d2 78 07 80 4e bb 40  |...F. u...x..N.@|
00000030  8a 56 ba 88 56 00 e8 fc  00 52 bb c2 07 31 d2 88  |.V..V....R...1..|
00000040  6f fc 0f a3 56 bb 73 19  8a 07 bf 87 07 b1 03 f2  |o...V.s.........|
00000050  ae 74 0e b1 0b f2 ae 83  c7 09 8a 0d 01 cf e8 c5  |.t..............|
00000060  00 42 80 c3 10 73 d8 58  2c 7f 3a 06 75 04 72 05  |.B...s.X,.:.u.r.|
00000070  48 74 0d 30 c0 04 b0 88  46 b8 bf b2 07 e8 a6 00  |Ht.0....F.......|
00000080  be 7b 07 e8 b2 00 8a 56  b9 4e e8 8e 00 eb 05 b0  |.{.....V.N......|
00000090  07 e8 b0 00 30 e4 cd 1a  89 d7 03 7e bc b4 01 cd  |....0......~....|
000000a0  16 75 0d 30 e4 cd 1a 39  fa 72 f2 8a 46 b9 eb 16  |.u.0...9.r..F...|
000000b0  30 e4 cd 16 88 e0 3c 1c  74 f1 2c 3b 3c 04 76 06  |0.....<.t.,;<.v.|
000000c0  2c c7 3c 04 77 c9 98 0f  a3 46 0c 73 c2 88 46 b9  |,.<.w....F.s..F.|
000000d0  be 00 08 8a 14 89 f3 3c  04 9c 74 0a c0 e0 04 05  |.......<..t.....|
000000e0  be 07 93 c6 07 80 53 f6  46 bb 40 75 08 bb 00 06  |......S.F.@u....|
000000f0  b4 03 e8 59 00 5e 9d 75  06 8a 56 b8 80 ea 30 bb  |...Y.^.u..V...0.|
00000100  00 7c b4 02 e8 47 00 72  86 81 bf fe 01 55 aa 0f  |.|...G.r.....U..|
00000110  85 7c ff be 85 07 e8 19  00 ff e3 b0 46 e8 24 00  |.|..........F.$.|
00000120  b0 31 00 d0 eb 17 0f ab  56 0c be 78 07 e8 eb ff  |.1......V..x....|
00000130  89 fe e8 03 00 be 85 07  ac a8 80 75 05 e8 04 00  |...........u....|
00000140  eb f6 24 7f 53 bb 07 00  b4 0e cd 10 5b c3 8a 74  |..$.S.......[..t|
00000150  01 8b 4c 02 b0 01 56 89  e7 f6 46 bb 80 74 13 66  |..L...V...F..t.f|
00000160  6a 00 66 ff 74 08 06 53  6a 01 6a 10 89 e6 48 80  |j.f.t..Sj.j...H.|
00000170  cc 40 cd 13 89 fc 5e c3  20 20 a0 0a 44 65 66 61  |.@....^.  ..Defa|
00000180  75 6c 74 3a a0 0d 8a 00  05 0f 01 06 07 0b 0c 0e  |ult:............|
00000190  83 a5 a6 a9 0d 0c 0b 0a  09 08 0a 0e 11 10 01 3f  |...............?|
000001a0  bf 44 4f d3 4c 69 6e 75  f8 46 72 65 65 42 53 c4  |.DO.Linu.FreeBS.|
000001b0  66 bb 44 72 69 76 65 20  00 00 80 0f b6 00 80 01  |f.Drive ........|
000001c0  01 00 a5 fe ff ff 3f 00  00 00 2a 27 61 0e 00 00  |......?...*'a...|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200
root@ubuntu:~#
```


In addition, am I correct that there can be up to four slices and each slice will have it's own partitions(there will be a _bsdlabel_ on each VBR)? Last but not least, is such slice/partition approach historical or has it some advantages over MBR partition approach(for example approach the Linux is using)? :OOO


----------



## Beastie (Feb 14, 2012)

m4rtin said:
			
		

> slice in _FreeBSD_ terminology is a _primary partition_ in MBR which has _FreeBSD_ partitions encapsulated in it.
> [...]
> there can be up to four slices and each slice will have it's own partitions(there will be a _bsdlabel_ on each VBR)?


Correct. As long as you're talking about a disk using the MBR scheme. There are other schemes used for different machine architectures. As you can see FreeBSD may be installed on a GPT (GUID Partition Table) disk for example.



			
				m4rtin said:
			
		

> Last but not least, is such slice/partition approach historical or has it some advantages over MBR partition approach(for example approach the Linux is using)?


The MBR is historical and mainly used for compatibility with other systems (DOS/Windows). The slice+partition system in FreeBSD is pretty much the same as DOS/Windows' primary partition+extended-logical partition(s). Correct me if I'm wrong but I believe GNU/Linux distributions are installed on one BIOS partition (equivalent to a BSD slice or DOS/Windows primary partition) and use another for swapping, and also support being installed on partitions like the logical partition of DOS/Windows.
In other words, all OSs use similar systems.


----------



## kpa (Feb 14, 2012)

Debian (and I think also Ubuntu) defaults to one primary partition (slice in BSD terminology) for root partition and then another primary partition (that covers the rest of the disk) for what is called an "extended partition", the "logical" partitions are sub-partitions of this extended partition. A direct analogy for these sub-partitions are the partitions created with bsdlabel(8) if used on an MBR slice.


----------



## m4rtin (Feb 14, 2012)

*Beastie*, *kpa*:

Yes, if I choose _"Separate /home, /usr, /var, and /tmp partitions"_ in _"Partition disks"_ menu during Debian installation to *sda* I end up with one small primary partition and lot of logical ones. Check the _partitions.jpg_ file attached with this post. However, I usually create partitions manually and usually prefer primary partitions instead of logical ones.


----------



## Beastie (Feb 15, 2012)

m4rtin said:
			
		

> I usually create partitions manually and usually prefer primary partitions instead of logical ones.


The only problem is that you can usually create many more logical partitions than primary ones using the MBR scheme. That's practically why GPT was created...


----------



## drhowarddrfine (Feb 15, 2012)

Does GPT/gpart only work with newer drives and/or motherboards? A brief search seems to indicate it's only since 2010 we've been able to use this. I was tinkering with a 4-year old box and couldn't get it to work with the installed drives.


----------



## ahavatar (Feb 15, 2012)

GPT supported PC motherboards with a UEFI BIOS are reletively new (less than 2 years old). My understanding is that on older motherboards you can use GPT data disks but you can't boot GPT system disk unless doing some MBR/GPT hybrid hack.


----------



## phoenix (Feb 15, 2012)

If you install /boot/pmbr into the GPT, then you can boot the disk on any system:
`# gpart bootcode -b /boot/pmbr da0`


----------



## kpa (Feb 15, 2012)

That's the "MBR/GPT hybrid hack" but the MBR part is not kept in sync with the GPT partition table in any way, it's only there to tell MBR only aware BIOSes and tools that there's an MBR slice that covers the whole disk and is bootable.


----------



## drhowarddrfine (Feb 15, 2012)

@kpa - Is that a bad thing or does it not matter? These are ATA drives btw.


----------



## wblock@ (Feb 15, 2012)

drhowarddrfine said:
			
		

> Does GPT/gpart only work with newer drives and/or motherboards?



No, GPT is made to be backwards compatible.  Usually there's a "protective" MBR which an average system sees as an MBR.



> A brief search seems to indicate it's only since 2010 we've been able to use this. I was tinkering with a 4-year old box and couldn't get it to work with the installed drives.



BIOSes that expect a particular layout or do other nonstandard things with MBR disks can fail with GPT disks.


----------



## drhowarddrfine (Feb 15, 2012)

I don't know what I'm doing. I'm just poking things with a stick. I'll get into this, and my own thread shortly.

Could this problem be caused by older hardware? I'm getting this error when I try to mount:

```
g_vfs_done():ada0p1[READ(offset=262144, length=8192)]error = 5
mount: /dev/ada0p1 : Input/output error
```

I need some links to read up on this. I was surprised to see ada0 alongside ad0 when using the cd0 install disk. I looked through the handbook but didn't catch anything at first glance.


----------



## wblock@ (Feb 15, 2012)

That's a read error on the disk.  Install sysutils/smartmontools and run *smartctl -a /dev/ada0*.  However, if that block has just gone bad, it won't show in the reallocated sector count until the system tries to write to it.  Could also be a controller problem.

9.0 went to the ada0 device names for both SATA and ATA drives.  However, the old-style ad0 names are also created for compatibility with existing files.


----------



## aragon (Feb 15, 2012)

kpa said:
			
		

> for what is called an "extended partition", the "logical" partitions are sub-partitions of this extended partition. A direct analogy for these sub-partitions are the partitions created with bsdlabel(8) if used on an MBR slice.


I wouldn't call them direct analogies.  The slice+label design is a well thought out approach of neatly compartmentalizing OS data hierarchically on a disk.  Extended Boot Records are a bit different and quite hacky really.  

Firstly EBRs are not really hierarchical - the partition metadata is stored more like a linked list with each "logical drive" having its own MBR-like data structure at its start that chain links to the next logical drive's MBR-like data structure somewhere else on the disk.

Secondly, to have just one "logical drive" you have to have one extended partition (which is a primary partition in itself).  You also can't have multiple extended partitions to group logical drives together, so if you have multiple OSes needing logical drives of their own, they all have to share the one extended partition.

FreeBSD can store all its OS data, including swap, in one self-contained primary partition.    Linux has to consume at least 2 primary partitions usually, and your disk is left littered with messy penguin bits all over.


----------



## kpa (Feb 15, 2012)

@drhowarddrfine It's a good thing because the MBR partition table can left as it is when the GPT table is modified, the whole purpose of the MBR partition is to enable booting with BIOSes that don't understand GPT and the /boot/pbmr boot loader doesn't care if the MBR slice table matches the GPT partitions or not. 

@aragon Yes, the analogy fails in that an EBR partition can not be used alone without at least one primary MBR partition.


----------



## lbc (Oct 5, 2012)

aragon said:
			
		

> Linux has to consume at least 2 primary partitions usually, and your disk is left littered with messy penguin bits all over.


Today, I've just setup a Linux system that uses no primary partitions at all, everything contained in logical MBR partitions. I even deleted all remaining primary MBR partitions afterwards and the system booted like a charm. Since at least 2004 (before the omnipotent GRUB 2 era), a Linux system would require at most a single primary MBR partition; I can't recall if storing its kernel there was a requirement, or just a side effect of having to store the bulk of its boot manager code in the VBR of a primary MBR partition. Just for the record (pun intended  ).

Apologies if reviving this relatively old thread only to add information perpendicular to its topic is not appreciated ; please let me know if that's the case.


----------



## xtaz (Oct 5, 2012)

phoenix said:
			
		

> If you install /boot/pmbr into the GPT, then you can boot the disk on any system:
> `# gpart bootcode -b /boot/pmbr da0`



Sorry to hijack this thread but just want to ask a quick question about this. I used GPT partitioning myself for the first time when I built a server recently. I'm pretty OCD about liking to keep everything up to date and deleting old stuff, my old server had been updated from 4.1 through to 9.0 but if you looked at it you would assume it was installed at 9.0! As a result I'd like to also keep the protective MBR and bootcode up to date once a year or so just so I know I'm running the latest code. But I don't want to shoot myself in the foot.

Question is is it safe to run this command below on my drive at any time I feel the urge without anything breaking spectacularly? I assume it won't touch any of the GPT table information or partitions and will just rewrite the PMBR and bootcode and will then just quite happily still boot afterwards?


```
gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 ada0
```


```
=>        34  1250263661  ada0  GPT  (596G)
          34        1024     1  freebsd-boot  (512k)
        1058         990        - free -  (495k)
        2048  1228931072     2  freebsd-ufs  (586G)
  1228933120    21330575     3  freebsd-swap  (10G)
```


----------



## wblock@ (Oct 5, 2012)

It's safe.  Best practice would be to only rewrite bootcode if it has actually changed.


----------

