ZFS root - Revision history

Foobarz at 14:44, 24 September 2012

Foobarz — Mon, 24 Sep 2012 14:44:46 GMT

← Older revision		Revision as of 14:44, 24 September 2012
Line 649:		Line 649:
	</pre>		</pre>
	Remove /etc/zfs/zpool.cache on shutdown. This is recommended because if it is present when you import a pool, it might use this old cache to determine the device filenames in the pool, which may have changed filenames since the last boot, especially the non-persistent /dev/sd* device filenames. It is safest to avoid any usage of the zpool.cache file at boot in initramfs, zfs module load, and at zpool import of other pools.		Remove /etc/zfs/zpool.cache on shutdown. This is recommended because if it is present when you import a pool, it might use this old cache to determine the device filenames in the pool, which may have changed filenames since the last boot, especially the non-persistent /dev/sd* device filenames. It is safest to avoid any usage of the zpool.cache file at boot in initramfs, zfs module load, and at zpool import of other pools.

			It is also possible to prevent <code>/etc/zfs/zpool.cache</code> from ever being created by using the zfs module option 'spa_config_path=' to tell the zfs module not to use any zpool.cache file (a blank filename). To set this zfs module option, do the following:
			<pre>
			echo options zfs spa_config_path= > /etc/modprobe.d/zfs.conf
			cp -a /etc/modprobe.d /boot/initrd-tree/etc
			</pre>
			If zfs is built into the kernel (see [http://slackwiki.com/ZFS_root_%28builtin%29 ZFS root (builtin)]), then this zfs module option is set as a kernel parameter: <code>zfs.spa_config_path=</code>

	In /etc/rc.d/rc.6:		In /etc/rc.d/rc.6:

Foobarz at 08:39, 24 September 2012

Foobarz — Mon, 24 Sep 2012 08:39:14 GMT

← Older revision		Revision as of 08:39, 24 September 2012
Line 748:		Line 748:
	boot: vmlinuz rescue		boot: vmlinuz rescue
	</pre>		</pre>
			In the rescue mode of the initrd, after you have mounted your zfs-root as readonly=on to /mnt, then "exit" to continue booting.

	In the ~~rescue mode of~~ the initrd, ~~after~~ you ~~have mounted your zfs-root~~ as ~~readonly=on to~~ /~~mnt~~, ~~then~~ "~~exit~~" ~~to continue booting~~.		An alternative rescue shell on the initrd can be started as follows:
			<pre>
			boot: vmlinuz rdinit=/bin/sh
			</pre>
			This puts you into a sh shell inside the initrd, and the normal /init script is not run at all. In this shell, you can fix problems and then attempt to start the system normally as follows:
			<pre>
			exec /init
			</pre>
			This runs the normal rdinit program, "execing" it so that it takes process ID (PID) 1 of your sh shell, which is the required PID for the init program.

	In other emergency command lines, you might need to run the lines at the end of init starting from: <code>udevadm info --cleanup-db; udevadm control --exit</code>		In other emergency command lines, you might need to run the lines at the end of init starting from: <code>udevadm info --cleanup-db; udevadm control --exit</code>
	If you don't run those udevadm commands, two runs of udevd fight each other and it is slow; you have to wait 2 minutes twice for timeouts (4 minutes).		If you don't run those udevadm commands, two runs of udevd could fight each other and it is slow; you have to wait 2 minutes twice for timeouts (4 minutes).
	The last line in init is run like: <code>exec switch_root /mnt /sbin/init 1</code>		The last line in init is run like: <code>exec switch_root /mnt /sbin/init 1</code>

Line 761:		Line 770:
	zfs set readonly=on zfs-root		zfs set readonly=on zfs-root
	</pre>		</pre>
			If you are using <code>mountpoint=legacy</code> for zfs-root, then you may want to use <code>readonly=off</code> and use the options to the <code>mount</code> command to control ro\|rw mounting. With <code>mountpoint=legacy</code> and <code>readonly=on</code> used together, there can be a contradiction between how the kernel actually mounts zfs-root (ro according to the readonly property) and how the userspace mount command and /etc/mtab attempt to mount the zfs-root (if you give <code>-o rw</code>). The kernel might actually mount ro, even when you have told the mount command to mount rw. The /etc/mtab can erroneously report rw, while the kernel's /proc/mounts file reports the actual mount as ro. Again, the two methods of mounting a zfs fs, either "legacy" <code>mount</code> command or by using the <code>zfs set mountpoint</code> can conflict with each other on the mode of mounting. If you create a zfs filesystem under zfs-root, like <code>zfs create "zfs-root/movies"</code> and then try to mount it, it may have inherited <code>mountpoint=legacy</code> and <code>readonly=on</code> from zfs-root, and it may mount ro even if you use the rw mount option: in this case, you have to do another command <code>mount -o remount,rw "zfs-root/movies"</code> to make it actually switch to rw (kind of weird!).

	A bug in unpatched grep 2.13 build 1, found slackware 14.0rc1, causes problems when processing files stored on ZFS but rarely shows problems on other filesystems; the bug does not handle sparse files on zfs and btrfs correctly and results in chaos with slackpkg, compiling kernel modules, and possibly many other things. You must downgrade grep to 2.12 or use the patched grep 2.13 build 2 in slackware 14.0rc2 or later.		A bug in unpatched grep 2.13 build 1, found slackware 14.0rc1, causes problems when processing files stored on ZFS but rarely shows problems on other filesystems; the bug does not handle sparse files on zfs and btrfs correctly and results in chaos with slackpkg, compiling kernel modules, and possibly many other things. You must downgrade grep to 2.12 or use the patched grep 2.13 build 2 in slackware 14.0rc2 or later.

Foobarz at 08:42, 19 September 2012

Foobarz — Wed, 19 Sep 2012 08:42:03 GMT

Show changes

Foobarz at 09:58, 16 September 2012

Foobarz — Sun, 16 Sep 2012 09:58:56 GMT

← Older revision		Revision as of 09:58, 16 September 2012
Line 259:		Line 259:
	zfs set mountpoint=legacy zfs-root		zfs set mountpoint=legacy zfs-root
	</pre>		</pre>
	Later in the wiki, it is shown how to mount using "zfs mount" for mountpoint=none, and regular "mount" for mountpoint=legacy. Using mountpoint=legacy is probably the preferred setting for the zfs-root because you can use the normal mount and umount commands and do no have to change slackware /etc/rc.d/* scripts much, if any. The normal slackware scripts handle a root filesystem's mounting and remounting using the normal mount command.		Later in the wiki, it is shown how to mount using "zfs mount" for mountpoint=none, and regular "mount" for mountpoint=legacy. Using mountpoint=legacy is probably the preferred setting for the zfs-root because you can use the normal mount and umount commands and do not have to change slackware /etc/rc.d/* scripts much, if any. The normal slackware scripts handle a root filesystem's mounting and remounting using the normal mount command.

	On creation, the zpool zfs-~~pool~~ is "imported" and has a zpool status that can be viewed:		On creation, the zpool zfs-root is "imported" and has a zpool status that can be viewed:
	<pre>		<pre>
	zpool status zfs-root		zpool status zfs-root

Foobarz at 08:07, 16 September 2012

Foobarz — Sun, 16 Sep 2012 08:07:20 GMT

Show changes

Foobarz at 07:59, 14 September 2012

Foobarz — Fri, 14 Sep 2012 07:59:36 GMT

← Older revision		Revision as of 07:59, 14 September 2012
Line 664:		Line 664:
	<pre>		<pre>
	#!/bin/sh		#!/bin/sh
	exec ~~/usr~~/bin/true		exec /bin/true
	</pre>		</pre>
			Or, it can be:
			<pre>
			#!/bin/sh
			exit 0
			</pre>
			Or, you just do (LOL!):
			<pre>
			ln -s /bin/true /sbin/fsck.zfs
			</pre>
			Got the idea, right!

	This fsck helper has the advantage that you do not need to alter <code>rc.S</code> as much, or at all if you use zfs property <code>mountpoint=legacy</code> and the regular <code>mount</code> command on your zfs-root. With these ideas, no slackware /etc/rc.d/* files really need editing, but it is up to you how you want to experiment.		This fsck helper has the advantage that you do not need to alter <code>rc.S</code> as much, or at all if you use zfs property <code>mountpoint=legacy</code> and the regular <code>mount</code> command on your zfs-root. With these ideas, no slackware /etc/rc.d/* files really need editing, but it is up to you how you want to experiment.

Foobarz at 06:50, 14 September 2012

Foobarz — Fri, 14 Sep 2012 06:50:06 GMT

← Older revision		Revision as of 06:50, 14 September 2012
Line 654:		Line 654:


	For ZFS, you cannot run fsck on it. It doesn't support that kind of filesystem check. The rc.S script will complain a lot in many places about not being able to run fsck on the zfs-root. To disable all attempts of run fsck, we can simply create a file that acts as a flag in /etc/rc.d/rc.S to tell it to skip fsck:		For ZFS, you cannot run fsck on it. It doesn't support that kind of filesystem check. The rc.S script will complain a lot in many places about not being able to run fsck on the zfs-root. To disable all attempts to run fsck, we can simply create a file that acts as a flag in /etc/rc.d/rc.S to tell it to skip fsck:
	<pre>		<pre>
	touch /etc/fastboot		touch /etc/fastboot
Line 660:		Line 660:

	This fastboot file is normally a run-once temporary file, and it is deleted near the bottom inside rc.S. Edit rc.S and stop it from deleting /etc/fastboot. We would like it to always skip all fsck. Edit /etc/rc.d/rc.S, and find the "rm" of fastboot, and do not have it removed!		This fastboot file is normally a run-once temporary file, and it is deleted near the bottom inside rc.S. Edit rc.S and stop it from deleting /etc/fastboot. We would like it to always skip all fsck. Edit /etc/rc.d/rc.S, and find the "rm" of fastboot, and do not have it removed!

			An alternative to using /etc/fastboot is to make the file <code>/sbin/fsck.zfs</code> that always just "does nothing successfully":
			<pre>
			#!/bin/sh
			exec /usr/bin/true
			</pre>
			This fsck helper has the advantage that you do not need to alter <code>rc.S</code> as much, or at all if you use zfs property <code>mountpoint=legacy</code> and the regular <code>mount</code> command on your zfs-root. With these ideas, no slackware /etc/rc.d/* files really need editing, but it is up to you how you want to experiment.

	We are getting close, and have finished all editing, so make /boot/initrd.gz and install lilo:		We are getting close, and have finished all editing, so make /boot/initrd.gz and install lilo:

Foobarz at 04:06, 9 September 2012

Foobarz — Sun, 09 Sep 2012 04:06:47 GMT

← Older revision		Revision as of 04:06, 9 September 2012
Line 48:		Line 48:
	When you need to change boot to cd or disk, try changing "order=dc" or hitting F12 at boot prompt and select the CD/DVD boot option.		When you need to change boot to cd or disk, try changing "order=dc" or hitting F12 at boot prompt and select the CD/DVD boot option.

	Note: The support for booting drives using if=scsi is not included with current versions of qemu. Booting scsi requires the 8xx_64.rom option-rom, which can be downloaded at [http://www.lsi.com/downloads/Public/Host%20Bus%20Adapters/Host%20Bus%20Adapters%20Common%20Files/lsi_bios.zip LSI.com]. Unzip it, and then:		Note: The support for booting drives using if=scsi is not included with current versions of qemu. Booting scsi requires the 8xx_64.rom option-rom, which can be downloaded at
			[http://www.lsi.com/downloads/Public/Host%20Bus%20Adapters/Host%20Bus%20Adapters%20Common%20Files/lsi_bios.zip LSI.com]. Unzip it, and then:
	<pre>		<pre>
	cp 8xx_64.rom /usr/share/qemu		cp 8xx_64.rom /usr/share/qemu
Line 124:		Line 125:
	Now that we have the spl and zfs packages on the host, it is possible to copy them into your local slackware64 mirror and then generate your own install DVD image that includes them. For example, change to the directory that contains the slackware README files, and create a "addon" directory and copy the spl and zfs slackware packages into there. Then, generate the DVD image using a command such as $( ./mirror-slackware-current.sh -i ) from where you have this script configured to maintain your local mirror. We can also just continue to access them inside the installer using qemu's virtfs option. When you are going to do a real installation onto real hardware, you need to generate and burn your own DVD that includes the packages.		Now that we have the spl and zfs packages on the host, it is possible to copy them into your local slackware64 mirror and then generate your own install DVD image that includes them. For example, change to the directory that contains the slackware README files, and create a "addon" directory and copy the spl and zfs slackware packages into there. Then, generate the DVD image using a command such as $( ./mirror-slackware-current.sh -i ) from where you have this script configured to maintain your local mirror. We can also just continue to access them inside the installer using qemu's virtfs option. When you are going to do a real installation onto real hardware, you need to generate and burn your own DVD that includes the packages.

	It is time to begin the installation of slackware64 on a ZFS root, assuming either you have regenerated dvd.iso with zfs packages in addon/* or we access the zfs packages while in the installer using qemu's virtfs to the host's packages directory. ZFS supports creating complex data storage configurations such as pools (similar to a volume group) backed by one or more of various kinds of virtual devices (similar to disks and raid arrays) and containing one or more datasets (similar to mounted filesystems, logical volume devices, or snapshots). But here, we keep it simple and will install on just a single disk device. On a real ZFS installation, users will typically want to use the ZFS ~~raidz1~~ or ~~raidz2~~ virtual device types for reliability against hard drive failures.		It is time to begin the installation of slackware64 on a ZFS root, assuming either you have regenerated dvd.iso with zfs packages in addon/* or we access the zfs packages while in the installer using qemu's virtfs to the host's packages directory. ZFS supports creating complex data storage configurations such as pools (similar to a volume group) backed by one or more of various kinds of virtual devices (similar to disks and raid arrays) and containing one or more datasets (similar to mounted filesystems, logical volume devices, or snapshots). But here, we keep it simple and will install on just a single disk device.

			Note: On a real ZFS installation, users will typically want to use the ZFS mirror or raidz virtual device (vdev) types for reliability against hard drive failures. For example, a good configuration might be to use a USB memory stick (and a backup stick) for /boot that is plugged into an on-motherboard "Type A" USB connector. Then, use four whole hard drives in a raidz2 vdev as the initial storage space in the root zpool. At a later time, to add more storage space, additional whole four-drive raidz2 vdevs of the same size could be added to the zpool. It is recommended to only add the same vdev type (disk, mirror, or raidz\|1\|2\|3) and size to a zpool since zfs stripes across the vdevs, and vdevs of different types/sizes do not stripe together optimally. After adding a vdev to your zpool, you might need to copy the new /etc/zfs/zpool.cache to your initrd-tree or initramfs-source (and rebuild/reinstall them) if you are using the cachefile to import your zpool. Using mirror vdevs would be similar to a raid10. Using 4-disk raidz2 vdevs would give the same storage space as raid10 while fully reliable against any double-disk failure; however, the raidz2 parity calculations results in higher CPU usage and/or lower performance. Because raidz vdevs cannot be grown by adding hard drives to them, and vdevs in a zpool are striped, it is important with ZFS to decide what type and size of vdev will be used in a zpool as the units of add-on storage space; it could be difficult to alter this decision later. Finally, on a real installation with raidz, data scrub should be scheduled to actively search for "latent defects" on the hard drives so that unknown read/write errors do not become known later during a disk swap/rebuild and result in the zpool becoming faulted (lost).

	<pre>		<pre>

Foobarz at 17:54, 4 September 2012

Foobarz — Tue, 04 Sep 2012 17:54:28 GMT

← Older revision		Revision as of 17:54, 4 September 2012
Line 48:		Line 48:
	When you need to change boot to cd or disk, try changing "order=dc" or hitting F12 at boot prompt and select the CD/DVD boot option.		When you need to change boot to cd or disk, try changing "order=dc" or hitting F12 at boot prompt and select the CD/DVD boot option.

	Note: The support for booting drives using if=scsi is not included with current versions of qemu. Booting scsi requires the 8xx_64.rom option-rom, which can be downloaded at http://www.lsi.com/downloads/Public/Host ~~Bus Adapters~~/Host ~~Bus Adapters Common Files~~/lsi_bios.zip. Unzip it, and then:		Note: The support for booting drives using if=scsi is not included with current versions of qemu. Booting scsi requires the 8xx_64.rom option-rom, which can be downloaded at [http://www.lsi.com/downloads/Public/Host%20Bus%20Adapters/Host%20Bus%20Adapters%20Common%20Files/lsi_bios.zip LSI.com]. Unzip it, and then:
	<pre>		<pre>
	cp 8xx_64.rom /usr/share/qemu		cp 8xx_64.rom /usr/share/qemu

Foobarz at 17:40, 4 September 2012

Foobarz — Tue, 04 Sep 2012 17:40:07 GMT

Show changes