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 pe
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
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.
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.
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.
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.
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.
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).
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
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.
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 pe
Re: (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
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: UFS vs ZFS (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: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.