Book Review: FreeBSD Mastery: Storage Essentials 75
Saint Aardvark writes If, like me, you administer FreeBSD systems, you know that (like Linux) there is an embarrassment of riches when it comes to filesystems. GEOM, UFS, soft updates, encryption, disklabels — there is a *lot* going on here. And if, like me, you're coming from the Linux world your experience won't be directly applicable, and you'll be scaling Mount Learning Curve. Even if you *are* familiar with the BSDs, there is a lot to take in. Where do you start? You start here, with Michael W. Lucas' latest book, FreeBSD Mastery: Storage Essentials. You've heard his name before; he's written Sudo Mastery (which I reviewed previously), along with books on PGP/GnuPGP, Cisco Routers and OpenBSD. This book clocks in at 204 pages of goodness, and it's an excellent introduction to managing storage on FreeBSD. From filesystem choice to partition layout to disk encryption, with sidelong glances at ZFS along the way, he does his usual excellent job of laying out the details you need to know without every veering into dry or boring. Keep reading for the rest of Saint Aardvark's review.
Do you need to know about GEOM? It's in here: Lucas takes your from "What *is* GEOM, anyway?" (answer: FreeBSD's system of layers for filesytem management) through "How do I set up RAID 10?" through "Here's how to configure things to solve that weird edge-case." Still trying to figure out GUID partitions? I sure was...and then I read Chapter Two. Do you remember disklabels fondly, and wonder whatever happened to them? They're still around, but mainly on embedded systems that still use MBR partitions — so grab this book if you need to deal with them.| FreeBSD Mastery: Storage Essentials | |
| author | Michael W. Lucas |
| pages | 240 |
| publisher | Tilted Windmill Press |
| rating | 9/10 |
| reviewer | Saint Aardvark |
| ISBN | 0692343202 |
| summary | FreeBSD Mastery: Storage Essentials takes you on a deep dive into FreeBSD’s disk management systems. |
The discussion of SMART disk monitoring is one of the best introductions to this subject I've ever read, and should serve *any* sysadmin well, no matter what OS they're dealing with; I plan on keeping it around for reference until we no longer use hard drives. RAID is covered, of course, but so are more complex setups — as well as UFS recovery and repair for when you run into trouble.
Disk encryption gets three chapters (!) full of details on the two methods in FreeBSD, GBDE and GELI. But just as important, Lucas outlines why disk encryption might *not* be the right choice: recovering data can be difficult or impossible, it might get you unwanted attention from adversaries, and it will *not* protect you against, say, an adversary who can put a keylogger on your laptop. If it still make sense to encrypt your hard drive, you'll have the knowledge you need to do the job right.
I said that this covers *almost* everything you need to know, and the big omission here is ZFS. It shows up, but only occasionally and mostly in contrast to other filesystem choices. For example, there's an excellent discussion of why you might want to use FreeBSD's plain UFS filesystem instead of all-singing, all-dancing ZFS. (Answer: modest CPU or RAM, or a need to do things in ways that don't fit in with ZFS, make UFS an excellent choice.) I would have loved to see ZFS covered here — but honestly, that would be a book of its own, and I look forward to seeing one from Lucas someday; when that day comes, it will be a great companion to this book, and I'll have Christmas gifts for all my fellow sysadmins.
One big part of the appeal of this book (and Lucas' writing in general) is that he is clear about the tradeoffs that come with picking one solution over another. He shows you where the sharp edges are, and leaves you well-placed to make the final decision yourself. Whether it's GBDE versus GELI for disk encryption, or what might bite you when enabling soft updates journaling, he makes sure you know what you're getting into. He makes recommendations, but always tells you their limits.
There's also Lucas' usual mastery of writing; well-written explanations with liberal dollops of geek humor that don't distract from the knowledge he's dropping. He's clear, he's thorough, and he's interesting — and that's an amazing thing to say about a book on filesystems.
Finally, the technical review was done by Poul Henning-Kamp; he's a FreeBSD developer who wrote huge parts of the GEOM and GBDE systems mentioned above. That gives me a lot of warm fuzzies about the accuracy of this book.
If you're a FreeBSD (or Linux, or Unix) sysadmin, then you need this book; it has a *lot* of hard-won knowledge, and will save your butt more than you'll be comfortable admitting.
You can purchase FreeBSD Mastery: Storage Essentials from amazon.com. Slashdot welcomes readers' book reviews (sci-fi included) -- to see your own review here, read the book review guidelines, then visit the submission page. If you'd like to see what books we have available from our review library please let us know.
NTFS (Score:1)
Re: (Score:2)
I prefer NTFS as a journaling file system. It provides all the functionality and none of the incompatibility that you get with these niche OS's.
Isn't NTFS kind of frozen in time as of 10 years ago at least? As I understand it, devs are mortally afraid to touch it out of fear of breaking it. No new features of any note for how long, a dozen years? And no new optimizations. Kind of zombified really. But don't believe me, see Microsoft's ADHD ReFS effort, they obviously have ZFS envy but don't quite know what to do about it. Supposedly started with gutting the NTFS code base. Great way to start with a clean sheet guys, or not.
Bottom line, nobody looks
Re: (Score:3)
Isn't NTFS kind of frozen in time as of 10 years ago at least?
AFAIK it gets revisions with every major release. Like the EXT family its backwards compatible, transparently.
No new features of any note for how long, a dozen years?
What big features is it missing aside from the checksumming / self-healing stuff thats already in ReFS? Feature wise its a pretty decent FS; its biggest flaw AFAICT is its bad performance in directories with huge numbers of files.
Re: (Score:2)
Re: (Score:2)
NTFS is metadata only journaling, no data protection. Kinda stone age. But good enough for Windows I guess, meets or exceeds the braindamage quotient for the system as a whole.
Re: (Score:2)
Re:What a crock (Score:5, Interesting)
In real world cases, this scenario happens:
1: Person loses their laptop/USB flash drive/storage media.
2: Someone finds it and examines it, or hands it to someone who can.
3: Stuff is found on there.
4: Front page news.
Just by having some form of disk encryption, preferably something that protects the entire machine (like geli)... that adds a large amount of security. A lost laptop goes from being a major corporate panic to becoming "just" a hardware loss, especially if the laptop has some mechanism like a removable USB flash drive or a TPM chip (which locks out for longer times the more failed guesses are attempted), and not just a passphrase that can be brute forced.
For most people, encryption is a no brainer. Turn it on, set a passphrase, forgot about it, except when after a reboot.
Now when people start mentioning rubber hose decryption (xkcd.com/538), this is generally not something everyone faces. However, there are other tools for that for plausible deniability, such as TC and its successors.
FDE encryption on a laptop that goes places should be considered a must, regardless of OS. Laptops and external media need some protection, and in most cases, the thief will boot the laptop up, see a FDE prompt, shrug, format the box, install a Windows variant, and pass it to another fence somewhere else to be sold.
As always, backups go without saying. Disk encryption and SSDs make this more important, because a TRIM means that the data isn't just marked as gone... it is -gone-, as in the physical cells has been zeroed out by the background garbage collector, and nobody is going to recover them. There are many ways to effectively back data up securely, and that is something left as an exercise to the reader.
Common sense says turn disk encryption on with a laptop, plain and simple.
Re: (Score:2)
What about saved/cached web service passwords/session cookies etc ...
Re: (Score:3)
why disk encryption might *not* be the right choice:
recovering data can be difficult or impossible,
I was concerned about this as well, and frequent crashes on my laptop (battery empty) can ruin a file system (I have made some bad experience with reiser4 in that regard).
However, I tried it, including forced poweroffs while writing, many crashes, etc., and it is fine. You mount the encryption, and recover the file system as usual, and the encryption layer does not influence the recovery at all.
I can recommend ext4 with LUKS (cryptsetup). It is very easy to set up for a single partition. You can choose AES
Re: (Score:2)
This is a variant of the venerable security through obscurity.
Not really.
Security is not an all-or-nothing proposition. In the real world, an adversary will NOT attempt to crack your encrypted filesystem. Instead they will do one of a hundred other attacks, like swapping your laptop with one that has a cloned disk and hardware but an embedded keylogger, or add in a shim between the disk and interface, or install an infected MBR that logs the decryption password, or perform a RAM sniffing attack to steal the keys, or simply extort the keys out of you.
Security is a pr
Storage Mastery 2 will cover ZFS (Score:5, Informative)
That's planned as another book in the Storage Mastery series (with a possible third on networked storage). But, whether that book is written depends on how well this first book is received and what his schedule is like for other books. If the first book doesn't sell enough or garner enough attention, then it will be the last one in that series.
There's a bunch more detail on Michael's blog [michaelwlucas.com] about this.
Not for new users of FreeBSD (Score:3)
Now that ZFS is the default operating system for new installs of FreeBSD 10.x, it sounds like this book documents a lot of hard won technical insights that have been made obsolete by ZFS. Why would I configure RAID 10 for UFS when ZFS provides superior data protection? And so on. It's probably useful for people who have parachuted in and now must maintain a legacy FreeBSD system. It doesn't sound particularly useful for someone who is migrating from Linux to FreeBSD right now, since this is all about how people *used* to configure FreeBSD storage.
Re:Not for new users of FreeBSD (Score:4, Informative)
ZFS is NOT the default in FreeBSD 10. UFS is still the standard.
(I try not to comment on reviews of my books, but a technical statement merits a technical answer.)
==ml
Re: (Score:2)
UFS vs ZFS (Score:5, Informative)
PC-BSD is built atop FreeBSD, but it's unquestionably a different thing than FreeBSD.
There are reasons to use ZFS, and other reasons to use UFS. Sometimes you really DO want UFS on raid-10. It depends entirely on the workload.
UFS has been around for decades now. I can't say it's bug free--nothing is--but most of the code paths have been quite well exercised. ZFS is newer and more complex than UFS, and more actively developed.
UFS is likely to remain the default in mainstream FreeBSD, for licensing reasons if nothing else.
Re: (Score:2)
Re: (Score:2)
All of the CDDL stuff in our tree is in a separate cddl directories. You can get a copy of the tree that does not include them and you can build the system without them. This is a requirement for a number of downstream consumers of FreeBSD.
That said, we do enable DTrace by default and the installer lets you choose UFS or ZFS. I'd recommend ZFS over UFS for anything with a reasonable amount of RAM (not your Raspberry Pi, but anything with a few GBs).
Re: (Score:2)
There are reasons to use ZFS, and other reasons to use UFS.
Like, for example, UFS actually has a repairing FSCK. ZFS fanatics will argue to the ends of the earth that ZFS doesn't need fsck repair because it has built-in raid. Riiiggght.
Bottom line is, ZFS is groovy and all (though no speed daemon) until it breaks. Chances are excellent that you are well and truly screwed.
Re: (Score:2)
Re: (Score:2)
Here you go. [freebsd.org] Please tell me how the poor sod has any hope of getting anything back without a proper repair tool. Oh yeah, I forgot, when your blood runs thick with ZFS koolaid, all those unrecoverable pool errors out there never happened.
Re: UFS vs ZFS (Score:2)
Re: (Score:2)
Don't be an ass. Anybody can search "ZFS unrecoverable" or the like. Up the creek without a fsck. [nas4free.org]
Re: (Score:1)
Re: (Score:2)
ZFS has got "self-healing" and does not need fsck.
Every time I hear this absurb blather repeated I hear "up the creek without a paddle" but hey, it's ok because ZFS is "self-healing". Hah what rubbish. Do you even know what the so-called self-healing is? Recovering data from parity. Now... Suppose you lose a whole stripe, what now? Hmm?
The truth about why ZFS has no repairing fsck is, nobody in that camp is smart enough to write it, especially considering the baroque mess that is ZFS metadata.
Re: (Score:2)
I think there is a mismatch between "self-healing filesystem" and "recovering data".
The "self-healing filesystem" (as I understand in the case of ZFS) is that it makes sure that the filesystem itself is not corrupted, i.e. the *whole* system is automatically healed. This doesn't guarantee recoverability of any single file that might have been corrupted.
Fsck (UFS) usually helps you to (a) heal a corrupted filesystem and (b) helps you to (partially) recover lost data (in case of corrupted files).
ZFS, AFAIK, p
Re: (Score:1)
It is not the task of a filesystem to recover data, but to keep the data as consistent as possible. UFS does not have any protections against bit rot or against hardware failures, so you'll never know if data is broken.
Data recovery is done with backups (which you'll always have, if the data is important for you). There is no way around it.
How exactly does fsck help, if it shows structural inconsistencies to you? It says "blabla... CLEAR [y/n]?" and when you press "y" something is lost and when you say
Re: (Score:2)
Re: (Score:2)
The "self-healing filesystem" (as I understand in the case of ZFS) is that it makes sure that the filesystem itself is not corrupted, i.e. the *whole* system is automatically healed.
False. ZFS "self-healing" has no concept of filesystem structure at all, it only knows about raid parity sets so it can fix a single block dropout or corruption of that sort. But blow big holes in the filesystem the way a head crash or failing flash does and ZFS "self-healing" gets useless fast. And yes, I have seen exactly that kind of corruption with Ext3/4 on multiple occasions and e2fsck has been able to get nearly all the data back. Obviously, if you blow a hole right in the middle of nonredundant data
Re: (Score:2)
But the protection is not perfect. Throw random data into a few adjacent blocks the way a head crash does, and if those blocks happen to be structural metadata, think about how extensive the data loss could be. In most cases, e2fsck and repair damage like that. ZFS can't.
If you need help imagining this, think about the effect of sticking a pin into your aortic valve.
Re: (Score:2)
It is not the task of a filesystem to recover data, but to keep the data as consistent as possible.
You are right, it is the task of the recovery tools to recover data*, which for ZFS are deficient or completely missing.
* Short of online repair, which today only exists in the limited form of raid recovery, and BTW, ZFS is far from the only fs that has that.
Re: (Score:2)
True I've wondered this myself lately with btrfs. Ext? has backup copies of the superblock. Which it uses during repair I presume.
There is no reason ZFS shouldn't have redundant copies of the critical structures. How foolproof is ZFS da
Re: (Score:1)
You are partially right. I miss the good old dump/restore tools for ZFS, but zfs send/receive do their job (in a limited fashion) well.
I see ZFS as the best option to run larger systems. I've had some problems with it when it was still experimental on FreeBSD, but at the moment it is running fine. I had to replace 2 faulty drives recently. It was painless and has not cost me any bit of lost data. I cannot complain, because there is one administrative problem less that I have to care about.
Re: (Score:2)
Re: (Score:2)
Like, for example, UFS actually has a repairing FSCK. ZFS fanatics will argue to the ends of the earth that ZFS doesn't need fsck repair because it has built-in raid. Riiiggght.
That's not the argument. fsck is not magic. It is designed around a number of possible kinds of error. It verifies on-disk structures and will attempt to reconstruct metadata if it finds that it is corrupted. Equivalent logic to fsck is built into ZFS. Every ZFS I/O operation runs a small part of this, validating metadata and attempting to repair it if it is damaged. You could pull this logic out into a separate tool, but why bother? zpool scrub will do the same thing, forcing the zpool to read (and
Re: (Score:3)
Re: (Score:2)
http://books.slashdot.org/comm... [slashdot.org]
Re: (Score:2)
That can be debated. A DYI NAS that does the job can be done pretty easily using RAID Z2 [1]. However, an unRAID appliance has some flexibility where one can add more hard disks as one sees fit dynamically without having to rebuild the entire array. Next to an EMC Isilon (which has 3+ nodes connected via Infiniband), this does the job quite well.
Maybe this is the next step up for evolution of filesystems, where an array can be upgraded (disks added/subtracted) without affecting the data on them. Of cour
Re: (Score:2)
Naming a book "Storage Essentials" and then not talking about ZFS was a mistake. If you're going to be building any type of NAS, you're going to want to use ZFS for it's scalability, reliability and stability. While you might get away with UFS for a couple of terabytes, you're going to have a bad time of it when you've got 40TB worth of storage space to manage.
Essentials means "the essentials," not "everything you should know about X."
After quickly looking through the table of contents, I don't think there's actually enough room in the book to even introduce ZFS. What should he have taken out? Smart? RAID? Encryption? I would argue that all that is way more "essentials" than ZFS. ZFS deserves its own book.
Re: (Score:2)
Re: (Score:2)
20 pages are barely enough to even introduce ZFS. Another 200 page book is more reasonable.
Re: (Score:3)
Sorry about that mistake. I'm not a FreeBSD expert, I'm someone who is setting up a FreeBSD file server, after 10 years of using Linux. So I'm in the market for a book like this, and of course it is largely useless to me, because of course I'm using ZFS. I was confused by the PC-BSD installer, which *does* default to ZFS.
Re: (Score:2)
Are you switching to BSD just for ZFS?
Learning BSD is probably a good investment, but ZFS on Linux [zfsonlinux.org] is production/stable and is excellent. I've been using on CENTOS 6 for over a year and it has been even more stable than EXT4 in a production environment.
I use both and ... (Score:2)
I had a failure on every disk of a sixteen disk pool when setting up on linux late last year for example, just after I'd copied a few TB to it - there's still some edge cases where it falls over and dies. Reinstalled with BSD it was much faster, nearly twice as fast, and hasn't
Re: (Score:1)
ZFS is a filesystem, not an operating system.
Re: (Score:1)
Now that ZFS is the default operating system for new installs of FreeBSD 10.x, it sounds like this book documents a lot of hard won technical insights that have been made obsolete by ZFS. Why would I configure RAID 10 for UFS when ZFS provides superior data protection? And so on. It's probably useful for people who have parachuted in and now must maintain a legacy FreeBSD system. It doesn't sound particularly useful for someone who is migrating from Linux to FreeBSD right now, since this is all about how people *used* to configure FreeBSD storage.
O_o I'm assuming you meant filesystem.
Embarassed (Score:2)
204 pages or 240? (Score:2)
Re:204 pages or 240? - both are correct (Score:4, Informative)
The book contains 204 numbered pages. Add in the index, Table of Contents, preface, copyright page, etc, and it hits 240 pages.
I did not do this in an effort to screw with people.
Had it occurred to me beforehand, however... yeah, I would have totally done that to screw with people.
==ml
Re: (Score:2)
Book Review: FreeBSD Mastery: Storage Essentials (Score:1)
Thank you Saint Aardvark for taking the time to write this review. You write very well.
--Z.
Cover artwork (Score:2)
The cover artwork is nice, but i like the cover style of his "Absolute ..." series more.
Not really for mastery ... (Score:2)
If it was, it wouldn't be about UFS, it'd be about ZFS.
UFS is still fine for small installations on embedded systems, but for any thing of any size, you should be using ZFS. Its superior in every way other than memory usage.
Re: (Score:2)
http://books.slashdot.org/comm... [slashdot.org]
Re: (Score:2)
ZFS lacks fsck, it's slow unless you through massive hardware at it, and "send" as a replication API is a drug addled piece of crap. Can't resume interrupted replication without starting from the beginning, what kind of amateur effort is that?
Re: (Score:2)
Righto. ZFS performs amazingly when not compared to anything. Look, even fanbois [phoronix.com] admit that ZFS is slow on "simple configurations", like for example... one disk. And it is a memory hog, do we agree? Here are some benchmarks [phoronix.com]. ZFS last by a mile. Look, we know the drill. ZFS fans talk a great filesystem. It only looks good when you don't compare it to anything. BTW, ZFS is a disgusting mess inside that nobody has the courage to touch in any substantive way now that Sun has paid the death penalty for being stu
Re: (Score:2)
ZFS is miserable on things that assume overwritten blocks will stay where they are on the disk. Some people even count on that to able scrub data. Is there a simple ioctl/fctl that allows that to be turned off in ZFS? no. There should also be an ioctl saying "this file needs to start on a physical block, not be encrypted, and it would be very cool if it was in the 1st gig of the disk, and can you tell me what real sector you can allocate for it?" because computer still need to boot.
Why wasn't there a zfs
Re: (Score:2)
I've got some 32 bit stuff with 4GB of memory running ZFS that still can saturate gigabit if you ask it for a file. Not the sort of thing you want a few people hitting at once but still not slow even on crap hardware. In general terms a ZFS filesystem that is nearly full gets very slow but that's something that afflicts others as well.
You have a point with send but it still shits all over rsync in terms of speed so if there's a rare chance of interruption
Re: (Score:2)
At work I have a little AMD (1.6GHz I think) freebsd system with 2Gb of RAM that saturates gigabit easily. I have actually been quite impressed by the performance of ZFS. Perhaps I am easily impressed though. The last system we had was an off-the-shelf seagate home level NAS that ran some form of embedded linux and failed horribly.
It keeps complaining it wants another 2gb of RAM to enable prefetch or something, but I can't be bothered because it is really better than it needs to be, and it does provide me
Re: (Score:2)
I've recently gone back to my roots and started dabbling with 3D animation and compositing again. My fileserver is a FreeBSD machine running on a decent 64-bit CPU with 16GiB RAM, with ZFS. And let me tell you, ZFS is dog slow for some uses, without it being anywhere near full. In my case, lossless-encoded video, and directories with thousands of 4MiB+ images, and working against that in realtime(or trying to), the filesystem stalled out at 80MiB/s, while my old fileserver running Linux and XFS easily satur
How did you get it that slow? (Score:2)
Then there's the possibility of running 4k per sectors disks as if they are not and losing a lot of performance.
So what did you do to get a speed slower than a single dis
Re: (Score:2)
6 WD Red 2TB disks split over 3 VDEVs, sector size is set correctly etc. No encryption, no compression. And it makes no difference whether I use NFS or Samba.
ZFS is something with which I have yet to familiarize myself with the internals so I can only guess, but my initial impression is that it's similar to older unix filesystems(and why Silicon Graphics developed XFS) in that it is not that good at handling many large files simultaneously. So I have the original video clip, then I have individual folders w
Re: (Score:2)
I'm using it for seismic data with a lot of multi-TB files being accessed simultaneously and it still saturates bonded gigabit links (better networking coming soon). Other stuff may be better but it's tasks like handling many large files simultan
Re: (Score:2)
Ran my home file server / desktop PC on a 32-bit Intel P4 with only 2 GB of RAM. Booted off a pair of 2 GB USB sticks (/ and /usr installed there, RAID1 via gmirror), and a 4 GB USB stick for L2ARC, while using 4x 160 GB SATA1 harddrives in a raidz1 vdev. Ran XBMC locally to catalogue all the shows into MySQL, and then to stream the videos to the other two XBMC systems in the house (10/100 Ethernet). No issues watching 480p and 720p shows while others w
Clustered Filesystems (Score:1)
great (Score:1)