Slashdot Mirror

← Back to Stories (view on slashdot.org)

Book Review: FreeBSD Mastery: Storage Essentials

Posted by samzenpus on from the read-all-about-it dept.

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. 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. 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.

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.

75 comments

  1. NTFS by Anonymous Coward · · Score: 1

    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.

    1. Re:NTFS by Tough+Love · · Score: 1

      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 to Microsoft for industry beating storage software. Never have, never will.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    2. Re:NTFS by LordLimecat · · Score: 2

      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.

    3. Re:NTFS by HotNeedleOfInquiry · · Score: 1

      I'm thinking, if there's one piece of software I'd kinda like "frozen in time", it would be a dependable journaling filesystem.

      --
      "Eve of Destruction", it's not just for old hippies anymore...
    4. Re:NTFS by Tough+Love · · Score: 1

      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.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    5. Re: NTFS by Anonymous Coward · · Score: 0

      Ntfs is a dinosaur compared to ZFS, do yourself a flavour and check it out

    6. Re:NTFS by TheRaven64 · · Score: 1

      No, NTFS has continued to evolve. The original design team were given changing requirements right up until Windows NT shipped. The on-disk format is basically an efficient way of storing large blobs of data and an efficient way of storing small blobs of data (much like BFS, though with a different approach). Everything else is policy that is layered on top.

      --
      I am TheRaven on Soylent News
    7. Re:NTFS by Anonymous Coward · · Score: 0

      As I understand it, devs are mortally afraid to touch it out of fear of breaking it.

      (Long-time MS dev here hopefully posting anonymously.) There is no fear of breaking the code. The code is rock solid. I have rarely seen code anywhere that is so well documented, reviewed, debugged, and tested.

      There is a conditioned aversion to any "new file system" because of major failures in attempting to make a radical new file system at MS, going back to around 1991. The OS code-named Cairo, under development at that time, eventually became NT 3.1 and was the basis for the UI of Windows 95. Cairo was supposed to have had a much-hyped new "object oriented" file system, but that never shipped. Then for a few years there were some incremental improvements to NTFS, followed by WinFS, another overly-ambitious project that had to be cancelled. WinFS was supposed to be a hybrid of a traditional file system and a relational database, and was one of the major features supposed to have shipped with Vista. There have also been several scrapped internal projects that never got any outside attention, but were known major failures internally.

      ReFS is different in that it is just the incremental evolution of NTFS, addressing real needs and weaknesses of NTFS, rather than the latest grandiose vision of the next-gen FS.

  2. What a crock by Anonymous Coward · · Score: 0

    why disk encryption might *not* be the right choice:
    recovering data can be difficult or impossible,

    Backups! Backups! Backups!

    it might get you unwanted attention from adversaries,

    This is a variant of the venerable security through obscurity.

    and it will *not* protect you against, say, an adversary who can put a keylogger on your laptop.

    Perfect is the enemy of good enough. Disk encryption solves one particular set of problems; IDS/antivirus solve another set. Need I draw you a Venn diagram?

    1. Re:What a crock by mlts · · Score: 4, 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.

    2. Re:What a crock by buchner.johannes · · Score: 2

      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 or TwoFish (512 bit key).

      The other thing I was worried about was read/write throughput. There is a benchmark utility that will tell you how how different cyphers perform. However I have never noticed any difference when working with encryption, probably because data comes in blocks and is cached efficiently by the kernel. Today, I do not see any obstacles for encrypting some partitions.

      --
      NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
    3. Re:What a crock by LordLimecat · · Score: 1

      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 process of analyzing the most common risks, and determining the best way to deal with them. Sometimes this means determining that a particular security action will lower your security by attracting the attention of entities with far more sophistication than you are prepared to deal with; if you are worried about criminals stealing your laptop, and your mitigation ends up attracting the attention of the NSA, you have lost the security battle.

      IDS / antivirus have no ability whatsoever to detect a hardware keylogger, by the way. If you attract the attention of someone who can gain physical access to your hardware, you lose-- period.

    4. Re:What a crock by Anonymous Coward · · Score: 0

      Common sense says turn disk encryption on with a laptop, plain and simple.

      There is absolutely nothing on my laptop that I fear anyone else reading. Nothing. There are no passwords, no legally protected or privileged information, nada. It's an old, slow Dell that works fine for web browsing and simple games, too old to run anything processor- or memory-intensive like MSwindows.

      But, like a politician or an Internet pundit, you've taken your own point of view and projected it onto the world at large, utterly blind to the reality that other humans are more multifarious and divergent than either of us can probably ever know.

      If you really want to epitomize the 20th century Internet blowhard, and learn nothing from our crude little conversation here, you should scoff at me and mock other people's differences now.

    5. Re:What a crock by goarilla · · Score: 1

      There is absolutely nothing on my laptop that I fear anyone else reading. Nothing. There are no passwords, no legally protected or privileged information, nada. It's an old, slow Dell that works fine for web browsing and simple games, too old to run anything processor- or memory-intensive like MSwindows.

      What about saved/cached web service passwords/session cookies etc ...

    6. Re:What a crock by Anonymous Coward · · Score: 0

      I'll be happy to reply to a 21'st century Internet blowhard who touts their edge case and assumes that nobody needs security along the lines of "why should you care about privacy invasions... are you doing something ILLEGAL?" Even with an old, slow Dell, there is bad stuff that can happen if a user leaves their fly open.

      1: Even with UNIX filesystems, that Dell is using a HDD, so deleted stuff still remains. Which means session cookies can be obtained (and there are a lot of websites where having that session cookie gives you access -forever-, even if you change passwords.)

      2: Facts are facts. The loss of a laptop or even a USB flash drive can cause people to wind up in jail or sprout lawsuits. One can think it may not happen, but it does.

      3: There is lots on that laptop that can be used against a person. Caches can find out a lot of info, remnants in a swapfile can show what someone was working on, empty disk sectors can get pictures, documents and potentially E-mail messages. Even metadata as when stuff was accessed and when could be used. All it takes is one shady picture, and there is a CP possession charge right there.

      4: You never know who is accessing what. When I was in college a few years back, there was a ring of script kiddies that would work with some laptop thieves, go through the contents of a laptop, find the owner, then demand money in return for the data, otherwise, they would send in the stored term papers to turnitin under their own name (which essentially means the original author now is blocked from using their own work.) Saved password sites (Chrome doesn't have encryption with a passphrase) end up giving free access and allowing the people who stole the laptops to drop students from classes without them knowing about it.

      5: Right now, the economy isn't bad enough that people are desperate... but if we get another 2008 or 1972, someone finding where a laptop owner resides and their daily schedule opens them up to a nice home invasion or "just" a burglary if lucky. Maybe even a kidnapping.

      One random AC might not have much on their laptop, but lets be real... there is a lot of stuff 99% of the other laptop users have on their own devices which they don't want people to see, edit, or claim as their own. There are a lot of consequences to data loss that people don't think about. Just being a person that might not have data is doing an injustice to those who really NEED to protect their stuff.

  3. Storage Mastery 2 will cover ZFS by phoenix_rizzen · · Score: 4, Informative

    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.

    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 about this.

  4. Not for new users of FreeBSD by dmoen · · Score: 2

    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.

    --
    I have written a truly remarkable program which this sig is too small to contain.
    1. Re:Not for new users of FreeBSD by agshekeloh · · Score: 3, 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

    2. Re:Not for new users of FreeBSD by unixisc · · Score: 1

      That's interesting, given that it is the default in PC-BSD. Also, I'd think it'd be the default in any 64-bit FreeBSD installation

    3. Re:Not for new users of FreeBSD by Noxal · · Score: 1

      ZFS is a filesystem, not an operating system.

    4. Re:Not for new users of FreeBSD by Mysticalfruit · · 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.

      --
      Yes Francis, the world has gone crazy.
    5. Re:Not for new users of FreeBSD by phoenix_rizzen · · Score: 1

      http://books.slashdot.org/comm...

    6. Re:Not for new users of FreeBSD by dmoen · · Score: 2

      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.

      --
      I have written a truly remarkable program which this sig is too small to contain.
    7. Re:Not for new users of FreeBSD by mlts · · Score: 1

      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 course, parity and redundant copies will be affected, but the data would still be usable. This would be nice on servers that are not SAN connected, so adding more drives to a live filesystem is something that would be done.

      [1]: RAID Z only can detect bit rot... RAID 1 and Z2 can find it and fix it. UnRAID doesn't seem to have any measures to protect against this. The EMC Isilons do, periodically running their equivalent of a zpool scrub.

    8. Re:Not for new users of FreeBSD by mcrbids · · Score: 1

      Are you switching to BSD just for ZFS?

      Learning BSD is probably a good investment, but ZFS on Linux 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 have no problem with your religion until you decide it's reason to deprive others of the truth.
    9. Re:Not for new users of FreeBSD by EmeraldBot · · 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.

      --
      "Set a man a fire, he'll be warm for the rest of the night. Set a man afire, he'll be warm for the rest of his life."
    10. Re:Not for new users of FreeBSD by kthreadd · · Score: 1

      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.

    11. Re:Not for new users of FreeBSD by Anonymous Coward · · Score: 0

      What do you mean there's no room? Surely 240 pages isn't a hard limit, there are much longer books out there.

    12. Re:Not for new users of FreeBSD by Mysticalfruit · · Score: 1

      He could have simply made the book 260 pages instead of 240 and put in a 20 page chapter on ZFS right after RAID. The first couple of pages would be about the design philosophy of ZFS. Next introduce the concepts of vdevs, pools and pool types (in relation to what the reader just learned about RAID), sub file systems, snapshots and file system attributes. Next layout some scenarios using 8 disks in a JBOD. Create a raidZ, raidZ2 and a raid10. Next talk about tacking on another 8 disks and what the options would be for expanding a raidZ, raidZ2, raid10 set. Next talk about the pros and cons of read caches and ZIL's and ways to tune ZFS to be more performant. Lastly, talk about scrubbing and replacing failed devices.

      I'll stand by my original argument... ZFS is essential to building scaleable networked storage devices with FreeBSD/Solaris and likely soon Linux. Yes, you could write the end all book on ZFS. Yes, someone like me would likely buy such a book. However, for your average sysadmin who knows nothing about ZFS this chapter plus google would give them a good starting foundation for building a storage device.

      --
      Yes Francis, the world has gone crazy.
    13. Re:Not for new users of FreeBSD by kthreadd · · Score: 1

      20 pages are barely enough to even introduce ZFS. Another 200 page book is more reasonable.

  5. UFS vs ZFS by agshekeloh · · Score: 4, 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.

    1. Re:UFS vs ZFS by unixisc · · Score: 1

      Licensing? BSDL ain't religious about it the way GNU people are, so that's not so much of an issue: the CDDL is not so incompatible w/ BSDL, so FreeBSD happily accepts it when needed. It would be more of a problem in Linux, since GPL and CDDL are completely incompatible.

    2. Re:UFS vs ZFS by Tough+Love · · Score: 1

      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.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    3. Re:UFS vs ZFS by saleenS281 · · Score: 1

      In what scenario would fsck help you with a ZFS filesystem? What is this "break" you speak of that fsck would fix?

    4. Re:UFS vs ZFS by Tough+Love · · Score: 1

      Here you go. 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.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    5. Re: UFS vs ZFS by saleenS281 · · Score: 1

      So you don't have an actual example then? Vague references aren't really helpful to having a meaningful discussion. In most circles what you're doing at this point would be considered FUD at best.

    6. Re: UFS vs ZFS by Tough+Love · · Score: 1

      Don't be an ass. Anybody can search "ZFS unrecoverable" or the like. Up the creek without a fsck.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    7. Re: UFS vs ZFS by koinu · · Score: 1

      ZFS has got "self-healing" and does not need fsck. It will probably destroy more data while a user cannot give hints with "y" or "n" during self-healing, but the filesystem will become stable and available. ZFS can of course become unrecoverable, like UFS can be un-fsck-able, because essential meta data might have become destroyed. You'll always need backups for important filesystems, no matter if it is UFS or ZFS, everything can get FUBAR.

    8. Re: UFS vs ZFS by Tough+Love · · Score: 1

      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.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    9. Re: UFS vs ZFS by ImdatS · · Score: 1

      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, puts higher priority on maintaining the overall filesystem's consistency over the recoverability of a single file. UFS w/fsck doesn't self-heal, but provides you with a tool to help recover a single file if the overall filesystem is corrupted or a single file is corrupted.

      I guess the question is what is more valuable: being able to recover a single file or having a self-healing filesystem that makes sure the the FS itself isn't corrupted.

      BTW: I assume that the use of angry sentences like "don't be an ass" or "... when your blood runs thick with ZFS koolaid..." won't help your arguments to be taken as seriously as you hoped for... then again, who knows ...

    10. Re:UFS vs ZFS by TheRaven64 · · Score: 1

      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).

      --
      I am TheRaven on Soylent News
    11. Re:UFS vs ZFS by TheRaven64 · · Score: 1

      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 therefore repair) everything using the fsck-like logic in the kernel.

      Bottom line is, ZFS is groovy and all (though no speed daemon) until it breaks

      The same is true of any filesystem. If a filesystem is corrupted to the extent that the self-healing logic in ZFS can't recover, it's also corrupted to the extent that a fsck tool would not be able to recover it.

      --
      I am TheRaven on Soylent News
    12. Re: UFS vs ZFS by koinu · · 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 "n"... the filesystem is still broken. And second thing is that when data is gone, it is gone on UFS and if you cannot describe (reliably!) in 5 lines on a display what is gone/affected, the user should always assume that a restore from backup is needed. And how exactly will UFS know if/what data is gone when it even cannot check its consistency? When you are lucky, you'll notice that libc is gone right after a reboot. When have bad luck, your system will notice a lot later that you valuable data is gone and your backups have been already overwritten because the backup tapes/disks are reused after a month or so.

    13. Re:UFS vs ZFS by goarilla · · Score: 1

      His pool has problems but I'm willing to bet it was still mountable (ONLINE) at that time.

    14. Re: UFS vs ZFS by goarilla · · Score: 1

      I don't think so. ZFS protects all data blocks and data pointers with checksums. Not only the special filesystem structures (superblock, inodes, metadata tables, ...).

    15. Re: UFS vs ZFS by Tough+Love · · Score: 1

      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, it's not coming back, but at least e2fsck gives you the best shot at it of any filesystem.

      It's actually unconsciounable that the false impression of "self-healing" promulgated by ZFS fans and repeated by you has been allowed to propagate without responsible correction by ZFS designers, who certainly understand the nature of the hyperbole. Smells like intellectual fraud. I'm not saying it is intellectuatl fraud per se, just that it smells like it.

      Re "don't be an ass"... overeaction indeed. But perhaps understandable given the persistent false claims we hear about ZFS. Come on, ZFS is a decent filesystem without ascribing mythical powers to it that it does not possess. But nonsensical hype and shameless exaggeration do not serve that community well. Eventually somebody who bothered to examine the code and know the facts is going to come along and make some wide eyed claims look a little dumb.

      The stupidest part of this whole issue: nothing stops ZFS from having a proper repairing fsck except hubris and misplaced faith in the capabilities of raid-only corruption repair.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    16. Re: UFS vs ZFS by Tough+Love · · Score: 1

      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.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    17. Re: UFS vs ZFS by Tough+Love · · Score: 1

      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.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    18. Re: UFS vs ZFS by goarilla · · Score: 1

      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.

      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 data protection for normal data and structural data ? Can anyone shed light on this ?

      Now fsck utilities aren't perfect and can worsen your situation. I myself have been bitten by xfs_repair and e2fsck (ext3 fs) in the past for example.

    19. Re: UFS vs ZFS by koinu · · 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.

  6. 204 pages or 240? by grahamsaa · · Score: 1

    It's a minor quibble, but the review states it's 204 pages and the table says 240. Obviously at least one of these numbers is incorrect.

    --
    Facts have a liberal bias.
  7. Re:204 pages or 240? - both are correct by agshekeloh · · Score: 3, 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

  8. Book Review: FreeBSD Mastery: Storage Essentials by ziani · · Score: 1

    Thank you Saint Aardvark for taking the time to write this review. You write very well.
    --Z.

  9. Cover artwork by psergiu · · Score: 1

    The cover artwork is nice, but i like the cover style of his "Absolute ..." series more.

    --
    1% APY, No fees, Online Bank https://captl1.co/2uIErYq Don't let your $$$ sit in a no-interest acct.
  10. Re:204 pages or 240? - both are correct by grahamsaa · · Score: 1

    lol, I like your style!

    --
    Facts have a liberal bias.
  11. Not really for mastery ... by BitZtream · · Score: 1

    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.

    --
    Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
    1. Re:Not really for mastery ... by phoenix_rizzen · · Score: 1

      http://books.slashdot.org/comm...

    2. Re:Not really for mastery ... by Tough+Love · · Score: 1

      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?

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    3. Re: Not really for mastery ... by Anonymous Coward · · Score: 0

      There are patches coming by delphix that allow it. In any case zfs send / recv is more resilient than ufs dump / restore. Zfs is not slow by any stretch of the imagination, especially not on mirrors. Random IO is fantastic, even with a cold cache.

    4. Re:Not really for mastery ... by dbIII · · Score: 1

      it's slow unless you through massive hardware at it

      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 it's tolerated.

    5. Re:Not really for mastery ... by inasity_rules · · Score: 1

      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 some minor redundancy.

      --
      I have determined that my sig is indeterminate.
    6. Re: Not really for mastery ... by Tough+Love · · Score: 1

      Righto. ZFS performs amazingly when not compared to anything. Look, even fanbois 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. 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 stupid. No wonder it has proved impossible to implement a repairing fsck.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    7. Re: Not really for mastery ... by thogard · · Score: 1

      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 zfsdump / zfsrestore that wrapped up the send / receive from day one? Even if /usr/lib/fs/zfs/fsck was a shell script wrapper around something else, it would have indicated a clue about where this stuff should fit in the grad scheme of things.

      Not everyone uses ufsdump to make backups, I use it to verify the contents of some files on the disk.

    8. Re:Not really for mastery ... by Shinobi · · Score: 1

      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 saturated the gigabit link

    9. Re:Not really for mastery ... by phoenix_rizzen · · Score: 1

      it's slow unless you through massive hardware at it,

      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 were downloading.

      Later, migrated to 4x 500 GB SATA2 hardrives in two mirror vdevs, running same XBMC setup. No issues there, and was even able to remove the L2ARC device as the pool was now faster than the cache.

      This past summer, I migrated the system to an AMD Phenom-II X4 system with 8 GB of RAM, and a zfs-on-root setup using 1 TB SATA3 drives (no USB sticks anywhere). Switched to a 64-bit install at this point (no changes to the pool). Switches to Plex everywhere instead of XBMC, and added a bunch of extra services like CUPS. Also does real-time transcoding for the little one's tablet (she uses Plex on the tablet).

      No issues to report. No performance issues, even when multiple torrents are downloading while we're watching shows on the tablet and the TV. The pool migrated along between each upgrade (with the exception of the first raidz->mirror conversion that used zfs send/recv). And it's all backed up to an external 3 TB drive via zfs send/recv.

      ZFS is only as complicated or as "slow" as you make it.

  12. Embarassed by unixisc · · Score: 1

    Is it anything like Embarrassingly Parallel Workloads?

  13. Re:Book Review: FreeBSD Mastery: Storage Essential by Anonymous Coward · · Score: 0

    I read through Saint's documentation every day. It's one of the reasons I keep coming into work.

  14. I use both and ... by dbIII · · Score: 1

    While ZFS on linux is pretty good and I'm using it on a few things it's still a bit behind the other versions in speed and reliability. At the moment BSD is still a long way ahead if you have a lot of disks and want raidz or raidz2.
    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 had any problems. Of course twice as fast doesn't always matter since it doesn't take much to saturate gigabit.

    However you can set stuff on on BSD now for reliability and later you can just import those ZFS pools from BSD into linux with a one line command. I've done that with a web server I first setup in BSD, with mirrored disks in the pool, and then when I reinstalled as linux I just had to import the pool and I got all the contents back, all neatly mounted where they should be.

    It probably won't take very long for ZFS on linux to catch up but for the moment BSD has some advantages. I love how ZFS will work even if you shove the disks into a different machine with different controllers and even a different operating system. No more worrying about whether you can get a replacement RAID card of the same model when things die.

  15. Clustered Filesystems by allfieldsrequired · · Score: 1

    The thing that is stopping me right now from my server fleet wholesale to a BSD is the lack of good choices when it comes to clustered filesystems, like OCFS2. I know there is GlusterFS, which is not the right solution for me and HAMMER / HAMMER2 which don't have the maturity and feature set we need yet. A shared drive, with a simple and fast DLM. Maybe I have overlooked something, but that is what is lacking right now in File Systems for BSD...

  16. How did you get it that slow? by dbIII · · Score: 1

    So what is the dog slow setup? A dozen disks in a single raidz2 vdev will be slow, splitting it into multiple vdevs will not, and mirrored disks (one vdev per two disks) should be very fast. It's not the same as RAID where the speed is proportional to the number of disks, the speed is proportional to the number of vdevs (virtual devices).
    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 disk? Did any of my guesses match up or is something else wrong?
    I've got faster than that with a Pentium 4, eight year old IDE disks and 2GB memory.

    1. Re:How did you get it that slow? by Shinobi · · Score: 1

      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 with the RBG channel images, the alpha channel images, the shadow maps, etc etc etc, meaning that for each second of 3D animation there's hundreds of images.

    2. Re:How did you get it that slow? by dbIII · · Score: 1
      OK then, it's not a setup failure, but something is definitely wrong. It's probably to do with ZFS using 512 byte sector sizes which many disks lie about when they really have a 4k sector size.

      in that it is not that good at handling many large files simultaneously

      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 simultaneously that filesytems are designed to do well these days.
      I'm not saying it's the best, but it's supposed to be at least fit for purpose so something is definitely wrong when performance is so bad. However the important thing is not using system X but getting the thing to go fast so maybe go with the XFS if it works better for you.

  17. great by bbloggertutorials · · Score: 1

    the cover is so great... Visit Blogger Tutorials!