Difference between pages "ZFS Install Guide" and "IPv4 calculations"

(Difference between pages)
(Installing the ZFS userspace tools and kernel modules)
 
 
Line 1: Line 1:
== Introduction ==
+
WARNING: Work in progress. Do not edit this article unless you are the original author.
  
This tutorial will show you how to install Funtoo on ZFS (rootfs). This tutorial is meant to be an "overlay" over the [[Funtoo_Linux_Installation|Regular Funtoo Installation]]. Follow the normal installation and only use this guide for steps 2, 3, and 8.
 
  
=== Introduction to ZFS ===
+
= Refresh on TCP/IP model =  
  
Since ZFS is a new technology for Linux, it can be helpful to understand some of its benefits, particularly in comparison to BTRFS, another popular next-generation Linux filesystem:
+
When the ARPANet (a packet oriented network) was born in those good old seventies, engineers had to solve the problem of making computers being able to exchange packets of information over the network and they invented in 1974 something you are now using to view this page: TCP/IP! TCP/IP is a collection of various network protocols, being organized as a stack. Just like your boss does not do everything in the company and delegates at lower levels which in turn delegates at an even more lower level, no protocol in the TCP/IP suite takes all responsibilities, they are working together in a hierarchical and cooperative manner.  A level of the TCP/IP stack knows what its immediate lower subordinate can do for it and whatever it will do will be done the right way and will not worry about the manner the job will be done.  Also the only problem for a given level of the stack is to fulfill its own duties and deliver the service requested  by the upper layer, it does not have to worry about the ultimate goal of what upper levels do.
 +
 
 +
<illustration goes here TCP/IP model>
  
* On Linux, the ZFS code can be updated independently of the kernel to obtain the latest fixes. btrfs is exclusive to Linux and you need to build the latest kernel sources to get the latest fixes.
+
The above illustration sounds horribly familiar : yes, it is sounds like this good old OSI model. Indeed it is a tailored view of the original OSI model and it works the exact same way: so the data sent by an application A1 (residing on computer C1) to another application A2 (residing on computer C2) goes through C1's TCP/IP stack (from top to bottom), reach the C1's lower layers that will take the responsibility to move the bits from C1 to C2 over a physical link (electrical or lights pulses, radio waves...sorry no quantum mechanism yet) . C2's lower layers will receive the bits sent by C1 and pass  what has been received to the C2's TCP/IP  stack (bottom to top) which will pass the data to A2. If C1 and C2 are not on the same network the process is a bit more complex because it involves relays (routers) but the global idea remains the same. Also there is no shortcuts in the process : both TCP/IP stacks are crossed in their whole, either from top to bottom for the sender or  bottom to top for the receiver. The transportation process in itself is also absolutely transparent from an application's point of view:  A1 knows it can rely on the TCP/IP stack to transmits some data to A2, ''how'' the data is transmitted is not its problem, A1 just assumes the data can be transmitted by some means. The TCP/IP stack is also loosely coupled to a particular network technology because its frontier is precisely the physical transportation of bits over a medium and so the physical network's technology,  just the same way A1 does not care about how the TCP/IP stack will move the data from one computer to another. The TCP/IP stack itself does not care about the details about how the bits are physically moved and thus it can work with any network technology no matter the technology is Ethernet, Token Ring or FDDI for example.  
  
* ZFS is supported on multiple platforms. The platforms with the best support are Solaris, FreeBSD and Linux. Other platforms with varying degrees of support are NetBSD, Mac OS X and Windows. btrfs is exclusive to Linux.
+
= The Internet layer and the IP protocol =
  
* ZFS has the Adaptive Replacement Cache replacement algorithm while btrfs uses the Linux kernel's Last Recently Used replacement algorithm. The former often has an overwhelmingly superior hit rate, which means fewer disk accesses.
+
The goal of this article being more focused on calculation of addresses used at the ''Internet layer'' so  let's forget the gory details about the TCP/IP stack (you can find an extremely detailed discussion in [[How the TCP/IP stack works]]...  still to be written...). From here, we assume you have a good general understanding of its functionalities and how a network transmission works. As you know the ''Internet'' layer is responsible to handle logical addressing issues of a TCP segment (or UDP datagram) that has either to be transmitted over the network to a remote computer or that has been received from the network from a remote computer. That layer is governed by a set of strict set rules called the ''Internet Protocol'' or ''IP'' originally specified by [RFC 791] in september 1981. What is pretty amazing with IP is that, although its original RFC has been amended by several others since 1981, its specification remains absolutely valid! If have a look at [RFC 791] you won't see "obsoleted". Sure IPv4 reached its limits in this first half the XXIst century but will remains in the IT landscape for probably several years to not say decades (you know, the COBOL language....). To finish on historical details, you might find interesting know that TCP/IP was not the original protocol suite used on the ARAPANet, it superseded in 1983 another protocol suite the [http://en.wikipedia.org/wiki/Network_Control_Program Network Control Program] or NCP. NCP looks like, from our point of view, prehistoric however it is of big importance as it established a lot of concepts still in use today : protocol data units, splitting an address in various components, connection management concept (TCP) and so on comes from NCP. Historical reward  for those who are still reading this long paragraph: first, even a user was addressable in NCP messages second even in 1970 the engineers were concerned by network congestions issues ([http://www.cs.utexas.edu/users/chris/think/ARPANET/Timeline this page]) :-)
  
* ZFS has the ZFS Intent Log and SLOG devices, which accelerates small synchronous write performance.
+
Enough of historical background, packet networks history is super interesting but would make this article would just too long. So let's go back to the Internet Protocol! In those good old seventies the engineers who designed the Internet Protocol retained a 32 bits addressing scheme. Why 32 bits and not 64 or 128? In that decade, computers were rare with very limited resources and everyone at that time found that using 32 bits to express the a computer's address on the network would be way far more than enough : 2^32 gives 4,294,967,296 or roughly 4.3 billions (even some briliant visionaries like  [http://en.wikipedia.org/wiki/J._C._R._Licklider J.C.Lickleider] would probably never have imagined the growth and popularity of computer networks at that time).
  
* ZFS handles internal fragmentation gracefully, such that you can fill it until 100%. Internal fragmentation in btrfs can make btrfs think it is full at 10%. Btrfs has no automatic rebalancing code, so it requires a manual rebalance to correct it.
+
== A story of cake ==
  
* ZFS has raidz, which is like RAID 5/6 (or a hypothetical RAID 7 that supports 3 parity disks), except it does not suffer from the RAID write hole issue thanks to its use of CoW and a variable stripe size. btrfs gained integrated RAID 5/6 functionality in Linux 3.9. However, its implementation uses a stripe cache that can only partially mitigate the effect of the RAID write hole.
+
From the beginning, engineers were aware that, also their address pool was ''a priori'' gigantic, it had to be used wisely and address pool exhaution issues had always been in the landscape: between 1977 and 1984, the number of interconnected hosts grew from roughly a hundred to more than a ''thousand'' and it was clear that this would not reach any limit. Indeed even at this time the problem was more ''when'' the pool will be depleted rather than ''if'' it would become depleted. Seen from those good old eighties, the IPv4 pool depletion was not an immediate problem especially altough the issued started be be a bit more critical a decade later (IETF [https://www.arin.net/knowledge/v4_deplete_v6_adopt.pdf forecasted] an IPv4 depletion between 2010 and 2017 in 1993).  
 +
Just like you divide your birthday cake in slices of various sizes depending on your guests' appetite to minimize the waste, the engineers choose to divide the initial IPv4 pool in several slices of various size. Each one of those latter were then exclusively attributed to a given organization who wanted to connect to the ARPAnet by the Government of the United States (ICANN/IANA and Regional Internet Registries came much later at the end of nineties). Okay the ARPAnet became defunct with the split of MILNET in 1984 giving NSFNet later replaced with the Internet as we still know today but the principle of exclusively attributing IPv4 blocks remained the same.  
  
* ZFS send/receive implementation supports incremental update when doing backups. btrfs' send/receive implementation requires sending the entire snapshot.
+
=== Classeful networks ===
  
* ZFS supports data deduplication, which is a memory hog and only works well for specialized workloads. btrfs has no equivalent.
+
To shovel the IPv4 pool depletion problem as much as possible in the future, engineers choose to divide the initial IPv4 pool as a set of various sized blocks each one of those then being exclusively allocated to a given organization depending on her networking needs,. In
  
* ZFS datasets have a hierarchical namespace while btrfs subvolumes have a flat namespace.
 
  
* ZFS has the ability to create virtual block devices called zvols in its namespace. btrfs has no equivalent and must rely on the loop device for this functionality, which is cumbersome.
 
  
The only area where btrfs is ahead of ZFS is in the area of small file
 
efficiency. btrfs supports a feature called block suballocation, which
 
enables it to store small files far more efficiently than ZFS. It is
 
possible to use another filesystem (e.g. reiserfs) on top of a ZFS zvol
 
to obtain similar benefits (with arguably better data integrity) when
 
dealing with many small files (e.g. the portage tree).
 
  
=== Disclaimers ===
 
  
{{fancywarning|This guide is a work in progress. Expect some quirks.}}
 
{{fancyimportant|'''Since ZFS was really designed for 64 bit systems, we are only recommending and supporting 64 bit platforms and installations. We will not be supporting 32 bit platforms'''!}}
 
  
== Video Tutorial ==
 
  
As a companion to the install instructions below, a YouTube video ZFS install tutorial is now available:
 
  
{{#widget:YouTube|id=kxEdSXwU0ZI|width=640|height=360}}
 
  
== Downloading the ISO (With ZFS) ==
+
): RFC 790 introduced in 1981 mentions the notion of ''network classes''. Just because you guests at a party have different appetites so you split a cake in more or less big slices, organizations have various needs so the initial IPv4 address pool has to be divided in a set of more or less big "slices". Depending of their size, those "slices" are said to belong to a ''class'' hence the terminology of ''classeful networks''.  Each organization wanting to connect the ARPAnet had to request the exclusive attribution of an exclusive address block of the IPv4 pool to the Government of the United States (ICANN/IANA and Regional Internet Registries came at the end of nineties), no matter of how it will be used or not internally.
In order for us to install Funtoo on ZFS, you will need an environment that provides the ZFS tools. Therefore we will download a customized version of System Rescue CD with ZFS already included. When booting, use the "alternate"-kernel. The ZFS-module won't work with the default kernel.  
+
  
<pre>
+
= Classful and classless networks =
Name: sysresccd-4.0.0_zfs_0.6.2.iso  (522 MB)
+
Release Date: 2014-01-18
+
md5sum 5a6530088e63b516765f78076a2e4859
+
</pre>
+
  
 +
Those addresses follows the thereafter logic:
  
'''[http://ftp.osuosl.org/pub/funtoo/distfiles/sysresccd/ Download System Rescue CD with ZFS]'''<br />
+
{| class="wikitable"
 +
|-
 +
| colspan="2" | '''32 bits (fixed length)'''
 +
|-
 +
| '''Network''' part (variable length of N bits ) || '''Host''' part (length : 32 - N bits)
 +
|}
  
== Creating a bootable USB from ISO ==
+
* The network address : this part is uniquely assigned amongst all of the organizations in the world (i.e. No one in the world can hold the same network part) 
After you download the iso, you can do the following steps to create a bootable USB:
+
* The host address : unique within a given network part
  
<console>
+
So in theory we can have something like this (remember the network nature is not to be unique, it hs to be be a collection of networks  :
Make a temporary directory
+
# ##i##mkdir /tmp/loop
+
  
Mount the iso
+
* Network 1 Host 1
# ##i##mount -o ro,loop /root/sysresccd-4.0.0_zfs_0.6.2.iso /tmp/loop
+
*
  
Run the usb installer
 
# ##i##/tmp/loop/usb_inst.sh
 
</console>
 
  
That should be all you need to do to get your flash drive working.
+
Just like your birthday cake is divided in more or less smaller parts depending on how guests' appetite, the IPv4 address space has also been divided into more or less smaller parts just because organizations needs more or less computers on their networks. How to make this possible? Simply by dedicating a variable number of bits to the network part! Do you see the consequence? An IPv4 address being '''always''' 32 bits wide, the more bits you dedicate to the network part the lesser you have for the host part and vice-versa, this is a tradeoff, always. Basically, having more bits in :
 +
* the network part : means more networks possible at the cost of having less hosts per network 
 +
* the host part : means less networks but more hosts per network
  
When you are booting into system rescue cd, make sure you select the '''alternative 64 bit kernel'''. ZFS support was specifically added to the alternative 64 bit kernel rather than the standard 64 bit kernel.
+
It might sounds a bit abstract but let's take an example : imagine we dedicate only 8 bits for the network part and the remaining 24 for the hosts part. What happens?  First if we only
  
== Creating partitions ==
+
There are two ways to partition your disk: You can use your entire drive and let ZFS automatically partition it for you, or you can do it manually.
+
  
We will be showing you how to partition it '''manually''' because if you partition it manually you get to create your own layout, you get to have your own separate /boot partition (Which is nice since not every bootloader supports booting from ZFS pools), and you get to boot into RAID10, RAID5 (RAIDZ) pools and any other layouts due to you having a separate /boot partition.
+
Is the network part assigned by each organization to itself? Of course not! Assignment are coordinated at the worldwide level by what we call Regional Internet Registries or RIRs which, in turn, can delegate assignments to third-parties located within their geographic jurisdiction. Those latter are called Local Internet Registries or LIRs (the system is detailed in RFC 7020). All of those RIRs are themselves put under the responsibility of now now well-known Internet Assigned Numbers Authority or [http://www.iana.org IANA]. As of 2014 five RIR exists :
 
+
==== gdisk (GPT Style) ====
+
* ARIN (American Registry for Internet Numbers) : covers North America
 
+
* LACNIC (Latin America and Caribbean Network Information Centre): covers South America and the Caribbean
'''A Fresh Start''':
+
* RIPE-NCC (Réseaux IP Européens / or RIPE Network Coordination Centre): covers Europe, Russia and middle east
 
+
* Afrinic (Africa Network Information Center) : covers the whole Africa
First lets make sure that the disk is completely wiped from any previous disk labels and partitions.
+
* APNIC (Asian and Pacific Network Information Centre) : covers oceania and far east.
We will also assume that <tt>/dev/sda</tt> is the target drive.<br />
+
 
+
<console>
+
# ##i##gdisk /dev/sda
+
 
+
Command: ##i##x ↵
+
Expert command: ##i##z ↵
+
About to wipe out GPT on /dev/sda. Proceed?: ##i##y ↵
+
GPT data structures destroyed! You may now partition the disk using fdisk or other utilities.
+
Blank out MBR?: ##i##y ↵
+
</console>
+
 
+
{{fancywarning|This is a destructive operation. Make sure you really don't want anything on this disk.}}
+
 
+
Now that we have a clean drive, we will create the new layout.
+
 
+
'''Create Partition 1''' (boot):
+
<console>
+
Command: ##i##n ↵
+
Partition Number: ##i##↵
+
First sector: ##i##↵
+
Last sector: ##i##+250M ↵
+
Hex Code: ##i##↵
+
</console>
+
 
+
'''Create Partition 2''' (BIOS Boot Partition):
+
<console>Command: ##i##n ↵
+
Partition Number: ##i##↵
+
First sector: ##i##↵
+
Last sector: ##i##+32M ↵
+
Hex Code: ##i##EF02 ↵
+
</console>
+
 
+
'''Create Partition 3''' (ZFS):
+
<console>Command: ##i##n ↵
+
Partition Number: ##i##↵
+
First sector: ##i##↵
+
Last sector: ##i##↵
+
Hex Code: ##i##bf00 ↵
+
 
+
Command: ##i##p ↵
+
 
+
Number  Start (sector)    End (sector)  Size      Code  Name
+
  1            2048          514047  250.0 MiB  8300  Linux filesystem
+
  2          514048          579583  32.0 MiB    EF02  BIOS boot partition
+
  3          579584      1953525134  931.2 GiB  BF00  Solaris root
+
 
+
Command: ##i##w ↵
+
</console>
+
 
+
 
+
=== Format your boot volume ===
+
Format your separate <tt>/boot</tt> partition:
+
<console>
+
# ##i##mkfs.ext2 /dev/sda1
+
</console>
+
 
+
=== Encryption (Optional) ===
+
If you want encryption, then create your encrypted vault(s) now by doing the following:
+
 
+
<console>
+
# ##i##cryptsetup luksFormat /dev/sda3
+
# ##i##cryptsetup luksOpen /dev/sda3 vault_1
+
</console>
+
 
+
=== Create the zpool ===
+
We will first create the pool. The pool will be named `tank` and the disk will be aligned to 4096 (using ashift=12)
+
<console># ##i##zpool create -f -o ashift=12 -o cachefile= -O compression=on -m none -R /mnt/funtoo tank /dev/sda3</console>
+
 
+
{{fancyimportant|If you are using encrypted root, change '''/dev/sda3 to /dev/mapper/vault_1'''.}}
+
 
+
{{fancynote| '''ashift<nowiki>=</nowiki>12''' should be use if you have a newer, advanced format disk that has a sector size of 4096 bytes. If you have an older disk with 512 byte sectors, you should use '''ashift<nowiki>=</nowiki>9''' or don't add the option for auto detection.}}
+
 
+
{{fancynote| If you have a previous pool that you would like to import, you can do a: '''zpool import -f -R /mnt/funtoo <pool_name>'''.}}
+
 
+
=== Create the zfs datasets ===
+
We will now create some datasets. For this installation, we will create a small but future proof amount of datasets. We will have a dataset for the OS (/), and your swap. We will also show you how to create some optional datasets: <tt>/home</tt>, <tt>/var</tt>, <tt>/usr/src</tt>, and <tt>/usr/portage</tt>.
+
 
+
<console>
+
Create some empty containers for organization purposes, and make the dataset that will hold /
+
# ##i##zfs create -p tank/os/funtoo
+
# ##i##zfs create -o mountpoint=/ tank/os/funtoo/root
+
 
+
Optional, but recommended datasets: /home
+
# ##i##zfs create -o mountpoint=/home tank/os/funtoo/home
+
 
+
Optional datasets: /usr/src, /usr/portage/{distfiles,packages}
+
# ##i##zfs create -o mountpoint=/usr/src tank/os/funtoo/src
+
# ##i##zfs create -o mountpoint=/usr/portage -o compression=off tank/os/funtoo/portage
+
# ##i##zfs create -o mountpoint=/usr/portage/distfiles tank/os/funtoo/portage/distfiles
+
# ##i##zfs create -o mountpoint=/usr/portage/packages tank/os/funtoo/portage/packages
+
</console>
+
 
+
=== Create your swap zvol ===
+
'''Make your swap +1G greater than your RAM. An 8G machine would have 9G of SWAP (This is kinda big though). For machines with this much memory, You could just make it 2G if you don't have any problems.'''
+
<console>
+
# ##i##zfs create -o sync=always -o primarycache=metadata -o secondarycache=none -o volblocksize=4K -V 1G tank/swap
+
</console>
+
 
+
=== Format your swap zvol ===
+
<console>
+
# ##i##mkswap -f /dev/zvol/tank/swap
+
# ##i##swapon /dev/zvol/tank/swap
+
</console>
+
 
+
Now we will continue to install funtoo.
+
 
+
== Installing Funtoo ==
+
[[Funtoo_Linux_Installation|Download and extract the Funtoo stage3 and continue installation as normal.]]
+
 
+
Then once you've extracted the stage3, chroot into your new funtoo environment:
+
<console>
+
Go into the directory that you will chroot into
+
# ##i##cd /mnt/funtoo
+
 
+
Mount your boot drive
+
# ##i##mount /dev/sda1 /mnt/funtoo/boot
+
 
+
Bind the kernel related directories
+
# ##i##mount -t proc none /mnt/funtoo/proc
+
# ##i##mount --rbind /dev /mnt/funtoo/dev
+
# ##i##mount --rbind /sys /mnt/funtoo/sys
+
 
+
Copy network settings
+
# ##i##cp /etc/resolv.conf /mnt/funtoo/etc/
+
 
+
chroot into your new funtoo environment
+
# ##i##env -i HOME=/root TERM=$TERM chroot /mnt/funtoo /bin/bash --login
+
 
+
Place your mountpoints into your /etc/mtab file
+
# ##i##cat /proc/mounts > /etc/mtab
+
 
+
Sync your tree
+
# ##i##emerge --sync
+
</console>
+
 
+
=== Add filesystems to /etc/fstab ===
+
 
+
Before we continue to compile and or install our kernel in the next step, we will edit the <tt>/etc/fstab</tt> file because if we decide to install our kernel through portage, portage will need to know where is your <tt>/boot</tt> so that it can place the files in there. We also need to update <tt>/etc/mtab</tt> so our system knows what is mounted
+
 
+
{{File
+
|/etc/fstab|<pre>
+
# <fs>                  <mountpoint>    <type>          <opts>          <dump/pass>
+
 
+
/dev/sda1              /boot          ext2            defaults        0 2
+
/dev/zvol/tank/swap    none            swap            sw              0 0
+
</pre>}}
+
 
+
== Kernel Configuration ==
+
To speed up this step, you can install "bliss-kernel" since it's already properly configured for ZFS and a lot of other configurations. The kernel is also compiled and ready to go. To install {{Package|sys-kernel/bliss-kernel}} type the following:
+
 
+
<console>
+
# ##i##emerge -av bliss-kernel
+
</console>
+
 
+
Now make sure that your <tt>/usr/src/linux symlink</tt> is pointing to this kernel by typing the following:
+
<console>
+
# ##i##eselect kernel list
+
Available kernel symlink targets:
+
[1]  linux-3.10.10-FB.01 *
+
</console>
+
You should see a star next to the bliss-kernel version you installed. In this case it was 3.10.10-FB.01. If it's not set, you can type '''eselect kernel set #'''.
+
 
+
== Installing the ZFS userspace tools and kernel modules ==
+
Emerge {{Package|sys-fs/zfs}}, {{Package|sys-kernel/spl}}, and {{Package|sys-fs/zfs-kmod}}:
+
<console># ##i##emerge -av zfs spl zfs-kmod</console>
+
 
+
{{fancynote| SPL = Solaris Porting Layer}}
+
Check to make sure that the zfs tools are working, the <code>zpool.cache</code> file that you copied before should be displayed.
+
 
+
<console>
+
# ##i##zpool status
+
# ##i##zfs list
+
</console>
+
 
+
If everything worked, continue.
+
 
+
== Install the bootloader ==
+
=== GRUB 2 ===
+
Before you do this, make sure this checklist is followed:
+
* Installed kernel and kernel modules
+
* Installed zfs package from the tree
+
* <code>/dev</code>, <code>/proc</code>, <code>/sys</code> are mounted in the chroot environment
+
 
+
Once all this is checked, let's install grub2. First we need to enable the "libzfs" use flag so zfs support is compiled for grub2.
+
 
+
<console># ##i##echo "sys-boot/grub libzfs" >> /etc/portage/package.use</console>
+
 
+
Then we will compile grub2:
+
 
+
<console># ##i##emerge -av grub</console>
+
 
+
Once this is done, you can check that grub is version 2.00 by doing the following command:
+
<console>
+
# ##i##grub-install --version
+
grub-install (GRUB) 2.00
+
</console>
+
 
+
Now try to install {{Package|sys-boot/grub}}:
+
<console>
+
# ##i##grub-install --recheck /dev/sda
+
</console>
+
 
+
You should receive the following message:
+
<console>
+
Installation finished. No error reported.
+
</console>
+
 
+
If not, then go back to the above checklist.
+
 
+
=== LILO ===
+
Before you do this, make sure the following checklist is followed:
+
* <code>/dev</code>, <tt>/proc</tt> and <tt>/sys</tt> are mounted.
+
* Installed the {{Package|sys-fs/zfs}} package from the tree.
+
Once the above requirements are met, LILO can be installed.
+
 
+
Now we will install {{Package|sys-boot/lilo}}.
+
<console># ##i##emerge -av sys-boot/lilo</console>
+
Once the installation of LILO is complete we will need to edit the lilo.conf file.
+
{{File
+
|/etc/lilo.conf|<pre>
+
boot=/dev/sda
+
prompt
+
timeout=4
+
default=Funtoo
+
 
+
image=/boot/bzImage
+
      label=Funtoo
+
      read-only
+
      append="root=tank/os/funtoo/root"
+
      initrd=/boot/initramfs
+
</pre>}}
+
All that is left now is to install the bootcode to the MBR.
+
 
+
This can be accomplished by running:
+
<console># ##i##/sbin/lilo</console>
+
If it is successful you should see:
+
<console>
+
Warning: LBA32 addressing assumed
+
Added Funtoo + *
+
One warning was issued
+
</console>
+
 
+
== Create the initramfs ==
+
There are two ways to do this, you can use genkernel, or you can use my bliss initramfs creator. I will show you both.
+
 
+
=== genkernel ===
+
<console>
+
# ##i##emerge -av sys-kernel/genkernel
+
# You only need to add --luks if you used encryption
+
# ##i##genkernel --zfs --luks initramfs
+
</console>
+
 
+
=== Bliss Initramfs Creator ===
+
If you are encrypting your drives, then add the "luks" use flag to your package.use before emerging:
+
 
+
<console>
+
# ##i##echo "sys-kernel/bliss-initramfs luks" >> /etc/portage/package.use
+
</console>
+
 
+
Now install the creator:
+
 
+
<console>
+
# ##i##emerge bliss-initramfs
+
</console>
+
 
+
 
+
Then go into the install directory, run the script as root, and place it into /boot:
+
<console># ##i##cd /opt/bliss-initramfs
+
# ##i##./createInit
+
# ##i##mv initrd-<kernel_name> /boot
+
</console>
+
'''<kernel_name>''' is the name of what you selected in the initramfs creator, and the name of the outputted file.
+
 
+
== Using boot-update ==
+
=== /boot on separate partition ===
+
If you created a separate non-zfs partition for boot then configuring boot-update is almost exactly the same as a normal install except that auto detection for root does not work. You must tell boot-update what your root is.
+
==== Genkernel ====
+
If your using genkernel you must add 'real_root=ZFS=<root>' and 'dozfs' to your params.
+
Example entry for boot.conf:
+
<console>
+
"Funtoo ZFS" {
+
        kernel vmlinuz[-v]
+
        initrd initramfs-genkernel-x86_64[-v]
+
        params real_root=ZFS=tank/os/funtoo/root
+
        params += dozfs=force
+
        # Also add 'params += crypt_root=/dev/sda3' if you used encryption
+
        # Adjust the above setting to your system if needed
+
}
+
</console>
+
 
+
==== Bliss Initramfs Creator ====
+
If you used the Bliss Initramfs Creator then all you need to do is add 'root=<root>' to your params.
+
Example entry for boot.conf:
+
<console>
+
"Funtoo ZFS" {
+
        kernel vmlinuz[-v]
+
        initrd initrd[-v]
+
        params root=tank/os/funtoo/root quiet
+
        # If you have an encrypted device with a regular passphrase,
+
        # you can add the following line
+
        params += enc_root=/dev/sda3 enc_type=pass
+
}
+
</console>
+
 
+
After editing /etc/boot.conf, you just need to run boot-update to update grub.cfg
+
<console># ##i##boot-update</console>
+
 
+
=== /boot on ZFS ===
+
TBC - pending update to boot-update to support this
+
 
+
== Final configuration ==
+
=== Add the zfs tools to openrc ===
+
<console># ##i##rc-update add zfs boot</console>
+
 
+
=== Clean up and reboot ===
+
We are almost done, we are just going to clean up, '''set our root password''', and unmount whatever we mounted and get out.
+
 
+
<console>
+
Delete the stage3 tarball that you downloaded earlier so it doesn't take up space.
+
# ##i##cd /
+
# ##i##rm stage3-latest.tar.xz
+
 
+
Set your root password
+
# ##i##passwd
+
>> Enter your password, you won't see what you are writing (for security reasons), but it is there!
+
 
+
Get out of the chroot environment
+
# ##i##exit
+
 
+
Unmount all the kernel filesystem stuff and boot (if you have a separate /boot)
+
# ##i##umount -l proc dev sys boot
+
 
+
Turn off the swap
+
# ##i##swapoff /dev/zvol/tank/swap
+
 
+
Export the zpool
+
# ##i##cd /
+
# ##i##zpool export tank
+
 
+
Reboot
+
# ##i##reboot
+
</console>
+
 
+
{{fancyimportant|'''Don't forget to set your root password as stated above before exiting chroot and rebooting. If you don't set the root password, you won't be able to log into your new system.'''}}
+
 
+
and that should be enough to get your system to boot on ZFS.
+
 
+
== After reboot ==
+
=== Create initial ZFS Snapshot ===
+
Continue to set up anything you need in terms of /etc configurations. Once you have everything the way you like it, take a snapshot of your system. You will be using this snapshot to revert back to this state if anything ever happens to your system down the road. The snapshots are cheap, and almost instant.
+
 
+
To take the snapshot of your system, type the following:
+
<console># ##i##zfs snapshot -r tank@install</console>
+
 
+
To see if your snapshot was taken, type:
+
<console># ##i##zfs list -t snapshot</console>
+
 
+
If your machine ever fails and you need to get back to this state, just type (This will only revert your / dataset while keeping the rest of your data intact):
+
<console># ##i##zfs rollback tank/os/funtoo/root@install</console>
+
 
+
{{fancyimportant|'''For a detailed overview, presentation of ZFS' capabilities, as well as usage examples, please refer to the [[ZFS_Fun|ZFS Fun]] page.'''}}
+
 
+
[[Category:HOWTO]]
+
[[Category:Filesystems]]
+
[[Category:Featured]]
+
 
+
__NOTITLE__
+

Revision as of 20:17, January 24, 2014

WARNING: Work in progress. Do not edit this article unless you are the original author.


Refresh on TCP/IP model

When the ARPANet (a packet oriented network) was born in those good old seventies, engineers had to solve the problem of making computers being able to exchange packets of information over the network and they invented in 1974 something you are now using to view this page: TCP/IP! TCP/IP is a collection of various network protocols, being organized as a stack. Just like your boss does not do everything in the company and delegates at lower levels which in turn delegates at an even more lower level, no protocol in the TCP/IP suite takes all responsibilities, they are working together in a hierarchical and cooperative manner. A level of the TCP/IP stack knows what its immediate lower subordinate can do for it and whatever it will do will be done the right way and will not worry about the manner the job will be done. Also the only problem for a given level of the stack is to fulfill its own duties and deliver the service requested by the upper layer, it does not have to worry about the ultimate goal of what upper levels do.

<illustration goes here TCP/IP model>

The above illustration sounds horribly familiar : yes, it is sounds like this good old OSI model. Indeed it is a tailored view of the original OSI model and it works the exact same way: so the data sent by an application A1 (residing on computer C1) to another application A2 (residing on computer C2) goes through C1's TCP/IP stack (from top to bottom), reach the C1's lower layers that will take the responsibility to move the bits from C1 to C2 over a physical link (electrical or lights pulses, radio waves...sorry no quantum mechanism yet) . C2's lower layers will receive the bits sent by C1 and pass what has been received to the C2's TCP/IP stack (bottom to top) which will pass the data to A2. If C1 and C2 are not on the same network the process is a bit more complex because it involves relays (routers) but the global idea remains the same. Also there is no shortcuts in the process : both TCP/IP stacks are crossed in their whole, either from top to bottom for the sender or bottom to top for the receiver. The transportation process in itself is also absolutely transparent from an application's point of view: A1 knows it can rely on the TCP/IP stack to transmits some data to A2, how the data is transmitted is not its problem, A1 just assumes the data can be transmitted by some means. The TCP/IP stack is also loosely coupled to a particular network technology because its frontier is precisely the physical transportation of bits over a medium and so the physical network's technology, just the same way A1 does not care about how the TCP/IP stack will move the data from one computer to another. The TCP/IP stack itself does not care about the details about how the bits are physically moved and thus it can work with any network technology no matter the technology is Ethernet, Token Ring or FDDI for example.

The Internet layer and the IP protocol

The goal of this article being more focused on calculation of addresses used at the Internet layer so let's forget the gory details about the TCP/IP stack (you can find an extremely detailed discussion in How the TCP/IP stack works... still to be written...). From here, we assume you have a good general understanding of its functionalities and how a network transmission works. As you know the Internet layer is responsible to handle logical addressing issues of a TCP segment (or UDP datagram) that has either to be transmitted over the network to a remote computer or that has been received from the network from a remote computer. That layer is governed by a set of strict set rules called the Internet Protocol or IP originally specified by [RFC 791] in september 1981. What is pretty amazing with IP is that, although its original RFC has been amended by several others since 1981, its specification remains absolutely valid! If have a look at [RFC 791] you won't see "obsoleted". Sure IPv4 reached its limits in this first half the XXIst century but will remains in the IT landscape for probably several years to not say decades (you know, the COBOL language....). To finish on historical details, you might find interesting know that TCP/IP was not the original protocol suite used on the ARAPANet, it superseded in 1983 another protocol suite the Network Control Program or NCP. NCP looks like, from our point of view, prehistoric however it is of big importance as it established a lot of concepts still in use today : protocol data units, splitting an address in various components, connection management concept (TCP) and so on comes from NCP. Historical reward for those who are still reading this long paragraph: first, even a user was addressable in NCP messages second even in 1970 the engineers were concerned by network congestions issues (this page) :-)

Enough of historical background, packet networks history is super interesting but would make this article would just too long. So let's go back to the Internet Protocol! In those good old seventies the engineers who designed the Internet Protocol retained a 32 bits addressing scheme. Why 32 bits and not 64 or 128? In that decade, computers were rare with very limited resources and everyone at that time found that using 32 bits to express the a computer's address on the network would be way far more than enough : 2^32 gives 4,294,967,296 or roughly 4.3 billions (even some briliant visionaries like J.C.Lickleider would probably never have imagined the growth and popularity of computer networks at that time).

A story of cake

From the beginning, engineers were aware that, also their address pool was a priori gigantic, it had to be used wisely and address pool exhaution issues had always been in the landscape: between 1977 and 1984, the number of interconnected hosts grew from roughly a hundred to more than a thousand and it was clear that this would not reach any limit. Indeed even at this time the problem was more when the pool will be depleted rather than if it would become depleted. Seen from those good old eighties, the IPv4 pool depletion was not an immediate problem especially altough the issued started be be a bit more critical a decade later (IETF forecasted an IPv4 depletion between 2010 and 2017 in 1993). Just like you divide your birthday cake in slices of various sizes depending on your guests' appetite to minimize the waste, the engineers choose to divide the initial IPv4 pool in several slices of various size. Each one of those latter were then exclusively attributed to a given organization who wanted to connect to the ARPAnet by the Government of the United States (ICANN/IANA and Regional Internet Registries came much later at the end of nineties). Okay the ARPAnet became defunct with the split of MILNET in 1984 giving NSFNet later replaced with the Internet as we still know today but the principle of exclusively attributing IPv4 blocks remained the same.

Classeful networks

To shovel the IPv4 pool depletion problem as much as possible in the future, engineers choose to divide the initial IPv4 pool as a set of various sized blocks each one of those then being exclusively allocated to a given organization depending on her networking needs,. In





): RFC 790 introduced in 1981 mentions the notion of network classes. Just because you guests at a party have different appetites so you split a cake in more or less big slices, organizations have various needs so the initial IPv4 address pool has to be divided in a set of more or less big "slices". Depending of their size, those "slices" are said to belong to a class hence the terminology of classeful networks. Each organization wanting to connect the ARPAnet had to request the exclusive attribution of an exclusive address block of the IPv4 pool to the Government of the United States (ICANN/IANA and Regional Internet Registries came at the end of nineties), no matter of how it will be used or not internally.

Classful and classless networks

Those addresses follows the thereafter logic:

32 bits (fixed length)
Network part (variable length of N bits ) Host part (length : 32 - N bits)
  • The network address : this part is uniquely assigned amongst all of the organizations in the world (i.e. No one in the world can hold the same network part)
  • The host address : unique within a given network part

So in theory we can have something like this (remember the network nature is not to be unique, it hs to be be a collection of networks  :

  • Network 1 Host 1


Just like your birthday cake is divided in more or less smaller parts depending on how guests' appetite, the IPv4 address space has also been divided into more or less smaller parts just because organizations needs more or less computers on their networks. How to make this possible? Simply by dedicating a variable number of bits to the network part! Do you see the consequence? An IPv4 address being always 32 bits wide, the more bits you dedicate to the network part the lesser you have for the host part and vice-versa, this is a tradeoff, always. Basically, having more bits in :

  • the network part : means more networks possible at the cost of having less hosts per network
  • the host part : means less networks but more hosts per network

It might sounds a bit abstract but let's take an example : imagine we dedicate only 8 bits for the network part and the remaining 24 for the hosts part. What happens? First if we only


Is the network part assigned by each organization to itself? Of course not! Assignment are coordinated at the worldwide level by what we call Regional Internet Registries or RIRs which, in turn, can delegate assignments to third-parties located within their geographic jurisdiction. Those latter are called Local Internet Registries or LIRs (the system is detailed in RFC 7020). All of those RIRs are themselves put under the responsibility of now now well-known Internet Assigned Numbers Authority or IANA. As of 2014 five RIR exists :

  • ARIN (American Registry for Internet Numbers) : covers North America
  • LACNIC (Latin America and Caribbean Network Information Centre): covers South America and the Caribbean
  • RIPE-NCC (Réseaux IP Européens / or RIPE Network Coordination Centre): covers Europe, Russia and middle east
  • Afrinic (Africa Network Information Center) : covers the whole Africa
  • APNIC (Asian and Pacific Network Information Centre) : covers oceania and far east.