Michael W Lucas - FreeBSD Mastery: Storage Essentials

FreeBSD Mastery: Storage Essentials

Copyright 2014 by Michael W Lucas (https://www.michaelwlucas.com)

All rights reserved

BSD Daemon Copyright 1988 by Marshall Kirk McKusick. All rights reserved.

Author: Michael W Lucas

Technical review: Poul-Henning Kamp

Copyediting: Aidan Julianna AJ Powell

Cover art: Beastie Leading the People , illustration copyright 2014 Eddie Sharam, after Liberty Leading the People , 1830, by Eugne Delacroix

www.tiltedwindmillpress.com

All rights reserved. No part of this work may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage or retrieval system, without the prior written permission of the copyright holder and the publisher. For information on book distribution, translations, or other rights, please contact Tilted Windmill Press (accounts@tiltedwindmillpress.com).

The information in this book is provided on an As Is basis, without warranty. While every precaution has been taken in the preparation of this work, neither the author nor Tilted Windmill Press shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the information contained in it.

This book would not exist without the support, encouragement, and tolerance of the FreeBSD community over the last eighteen years. Many people have helped me understand disks, filesystems, and exactly how I destroyed my data. Sadly, Im not man enough to trawl a decade and a half of FreeBSD mailing list archives to gather everyones names, but you either know who you are or you can write a Perl script to extract the relevant data.

The bank that holds my mortgage wants me to pass along their gratitude to iX Systems (http://www.ixsystems.com). I normally assemble test equipment from donations and hand-me-downs. Thanks to iX Systems reasonable rates, I was able to skip the recharge fire extinguisher step of my writing process.

My thanks to the people who bought this book before it was published. I especially want to thank those who bought the book early, read it, and sent me corrections. They are, in alphabetical order: Will Andrews, Lars Engels, Eli Janssen, Peter Jeremy, Ruslan Makhmatkhanov, Alexander Motin, Jens Schweikhardt, Dag-Erling Smrgrav, Jeff Russo, Romain Tartire, and Garrett Wollman.

Lastly, my gratitude to Poul-Henning Kamp. Not only did he write GEOM, he volunteered to tech review this book. For those unfamiliar with the process, tech review pretty much means educate the author about all the stuff he was either too lazy to read or too stupid to understand.

This book would suck a whole lot more without these people.

For Liz

You can arbitrarily replace everything in your computerexcept the hard disk. Memory or mainboard dies? Throw it out, get another. Processor overdoses on Bitcoin mining and explodes? Vacuum up the debris. Slot another in. Preferably one with a bigger fan. But when a hard disk has trouble, even experienced systems administrators sweat. Did the last backup run recently enough? Has the disk problem corrupted the data? Has the data corruption persisted long enough to render all of the backups unusable?

Nothing can completely remove all concerns about disks, but understanding the tools and options for disk management minimizes your worries. This book takes you through FreeBSDs disk management tools and filesystems. FreeBSD has a whole bunch of tools to examine disks and filesystems, and several filesystems to choose from. No filesystem or disk system is perfect, but you can choose the options that best fit your environment.

This book is written for system administrators interested in FreeBSD filesystems. No previous FreeBSD experience is necessary. We will cover FreeBSD 9 and later, although much of the material is relevant for earlier FreeBSD versions.

You must know something about disk technologies. We wont discuss the differences between SATA, SAS, PATA, EIDE, iSCSI, and their innumerable brethren. Anything I write about hardware would go obsolete more quickly than anything else in this book. Ill mention these technologies in passing, but wont make any specific recommendations. Just because I really like my SATA-3 setup in February 2014 doesnt mean you should rush out and buy one in 2016, or even November 2014. Do your own hardware research or, better still, bribe a friend who already has done the work.

Im going assume you have a FreeBSD system on hand for testing. A virtual machine suffices to explore filesystems, and might actually be preferable. Studying filesystems carries unique risks. A single command can destroy the operating system. It doesnt matter if you enter that command from ignorance, curiosity, or malicethe system will still vanish. You should test any disk changes on your disposable system, and be prepared to reinstall the disposable system when you screw up. A snapshot of a cleanly working virtual machine greatly helps in learning disk management. The more systems administration experience you have, the less you need a test systemand the more you want a system to test changes on before you try them in production. Get a test system.

When you blow up your test system, dont panic. As an educational exercise, attempt to recover the system. If that fails, reinstall.

An operating systems storage systems are intimately tied to the underlying hardware. In the last half-century, storage hardware has evolved from punchcards to spinning platters to solid state disks. All hardware, and the operating systems supporting it, carries traces of this history. Before you can understand filesystems, you need to know something about the hardware.

For many years, software authors created filesystems with the idea that the filesystem would go on a physical disk, such as a hard drive or a floppy disk (or a thing called a floppy disk that was actually fairly hard). They designed filesystems to take advantage of the drives physical characteristics. Factors such as the drives rotational speed, number of platters, and spin-up time influenced their designs. Filesystems were often tied tightly to the operating systemremember, DOS meant Disk Operating System!

These assumptions no longer apply, except when they do. A filesystem might reside on a disk, or it might exist as an image file, such as an ISO or a virtual machine disk. You still must understand the basics of how the disk works, however. Even ultramodern filesystems like the Z File System (ZFS) demand that the systems administrator understand physical disks.

Back in the stone age of computing, disks had a clearly defined geometry. Disks were round. They spun. The axle in the middle was called a spindle. An individual disk was called a platter, and each disk drive contained a stack of platters. Each platter had concentric rings of magnetic material, called tracks. As all of the individual disks inside a hard drive were identical, the tracks lined up above one another. A stack of tracks was called a cylinder. Each disk drive had a number of heads, devices that read and wrote data on a track as the platter spun beneath them. Each cylinder was divided into little logical units, called