Talk:Main Page
UFS and the Unsuitability of ZFS for many applications
Greetings everyone. I am something of an antique, having begun my career programming 8 bit devices with neon 0-9 + A-F readout which delivered my answers one byte at a time. Not particularly efficient, yet here we are, and that is indeed where it all began.
The FreeBSD project appears to have recently been purchased by Intel::Microsoft, and if that is the case, I suppose one could do worse than partnering with the #1 desktop os and the #1 chip maker, yet it seems to me that Microsoft and Intel both have plans for cloud based systems that might prove problematic for some uses. While ZFS may be a reasonable choice for read-only data that extends beyond about 4TB, I do not care for stripped drives, and I have read and reread all the propaganda about the "protection" offered by ZFS.
Since 1980 or so I have managed various systems on behalf of agencies and individuals whose security requirements are as stringent as may be found anywhere, and I must tell you proponents of ZFS that with a total of about 150,000 system images under management, I have yet to experience one single "problem" of any kind while using UFS (without journaling) in a RAID level 1 "Mirrored Pair" setup. UFS, the descendant of FFS did not exist in 1980, but it was the Year of the Tandem Minicomputer, and the world was formally introduced to the "Mirrored pair" method of data security. What can I say, RAID-1 just "works." 0 faults so far!
That was a sweeping statement. I just reported that here, at least, *Decades* of uneventful operation are "in the books," yet we have frantic naysayers wringing their hands, desperately seeking my approval of the latest and greatest file system du jour. My application contractually requires Raid Level 1 with discrete, human-readable volume enumeration. In other words, I have clients who would begin perspiring if told 'the system doesn't use drive letters, it's "striped." I would likely hear "Not Acceptable," and be instructed to discontinue using any experimental file system. ZFS *is* experimental. This truly is *not* acceptable for my purposes
Properly implemented, A "mirrored-pair" is the truly "bullet proof" option to select. In fact, a RAID-1 mirrored pair consists of 3 identical drives. A primary or $System volume and a backup mirror image which is verified for bit accuracy, removed from the system and placed in a Fire Safe at the close of business every day. Master, Spare + Zombie-Apocalypse Extra copy in the fire-safe. Please explain to me how ZFS plans to equal that level of secure data storage. Theoretical reconstruction from parity != a mirrored pair, and my clients aren't buying that snake oil. In addition, modern IntelBSD has other issues beyond ZFS.
Now, Microsoft Corporation and apparently the modern new IntelBSD versions now coming off the press have the annoying, needless requirement that any substantive reconfiguration must now be performed during "offline servicing," and Microsoft further complicates things by making the tools for doing so available only in Professional or Enterprise versions or their server products. If I were running the IT department for one of the Executive Branch departments of the federal government I might be more receptive to the idea of a "read-only" image that requires offline servicing for any real changes. What limited usefulness Windows may have had, was completely eliminated with Windows-7 and beyond, at least in my opinion. At the end of the day, it's not access to Twitter and it's not access to streaming media, it's actually all about the safe, secure storage and retrieval of often extremely valuable data sets.
Stripped drives don't speak to me in a language I understand. If I have a commercial corporation executive inquire where, precisely, his data are stored, I am typically unable to satisfy either my client, or, frankly, myself that (a) I actually know where his stuff is stored, and (b) [more importantly] that it will still be here tomorrow morning when the day begins if the drive has a head crash. Part and parcel of that assurance is being able to tell a client with a straight face that I can (reasonably) do a forensic bitwise extraction and reconstruction. If the storage volumes are stripped and if they further complicate the issue by using GUID instead of something a human can easily work with, the fact of the matter is that *only* ZFS can reconstruct a file system that crashed while running on ZFS, and there are, believe it or not, situations that could require separation of the storage volume(s) from the host machine that created them, while for various reasons requiring that "lost" data be recovered anyway, and "could you hurry every chance you get?" I think you probably understand why a careful, conservative mirrored pair + a third copy in the fire safe at the close of every business day, makes my picky clients feel all warm and fuzzy, whereas RAID Level-5 with (needless, time wasting) encryption, and if that's not slow enough for you, how about (needless, time-wasting) file compression? Hello? 2-TB drives are down to $50. QUESTION: Why do I or anybody else need file compression? File compression made sense when the IBM PC came with a 10 Megabyte <-- hard drive. I'm sitting here in front of a work station with about 12 TB of mostly NAS storage. What on earth would I do with the extra space saved by compression? 12 TB, for God's Sake, is more storage than Google had their first two years in business. I need --> Mandatory File Compression <-- like I need a hole in the head, yet look at PC-Sysinstall and you'll see LZ4 compression has been pre-selected and there's no way to get out of that choice short of rewriting the install scripts and creating my very own BSD distribution like you folks did. Sounds like Linux DeJa Vu?
Let me repeat: ZFS is **NOT** a "one size fits all" drop-in replacement for whatever else you may have been using successfully for the past 30 years or so. If well-meaning men can disagree amicably on the question of what file system suits personal needs and satisfies personal preferences better, then why can't reasonable, well-meaning men agree to provide one another with FREEDOM TO CHOOSE WHAT WORKS BEST FOR THEM ??? Why is it so bleeping important to force-feed ZFS? The question is "What's in it for ME?" Apparently BSD is meeting some goal, or time table to force a switch to cloud-friendly striped volumes with indeterminate drive lettering and equally indeterminate directory and storage structures. What if the whole world suddenly comes to its senses and determines that while the whole cloud computing idea might be good for Microsoft or Oracle or Google, it's not worth a bleep for meeting *my* needs or for satisfying my exceptionally picky clients that I have their data safely in hand and can deliver it to them in whole, or in part on a moment's notice either on-line or by handing them an bit-perfect copy of the system image fresh from the fire safe. Beat that, if you can, ZFS, but frankly I doubt it.
The fundamental, underlying principle of Unix has always been "Tools, Not Policy!:" In fact, it was Dennis Ritchie, himself who coined that phrase "tools, not policy." "Tools, Not Policy" was indeed the guiding spirit at Bell Labs. Without the "Tools, Not Policy" mind-set, it's doubtful that William Shockley would have invented the semi-conductor diode (a.k.a. "transistor.) It is equally unlikely that Dennis Ritchie and Brian Kernighan would have created the C Programming Language at Bell labs or that Ritchie wold have gone on to create Unix out of the C Programming Lanhguage.
Tools, Not Policy! This motto has served Unix very well since the first day of its existence, so why bail out on the idea of providing people with a comprehensive suite of tools, and then standing aside while each sys-admin selects the tools that *he* prefers to help him get his work done in a manner that is efficient, comprehensible, and that offers bullet proof security.
Bottom Line? A RAID Level-1 "Mirrored Pair" with a spare copy placed in the fire safe every night is infinitely more secure than any ZFS RAID-5 striped volume could ever hope to be, so how much longer do I have to wait before somebody puts UFS back in the mix? Or will I have to create the FUBSD distribution? the FU part (naturally) refers to the fact that BSD is "Fashionably Unix-like."
{:~0
Translation into German (de)
Main Page |
Hauptseite |
{| class="wikitable"
|-
|+ Welcome to the [[GhostBSD Wiki:About|GhostBSD Wiki]] - your source for GhostBSD documentation on the web!
|-
| style="width:50%" |
{| style="width:100%"
|-
|+
=== Using [[GhostBSD]] ===
|-
|
* [[FAQ]]
* [[GhostBSD User Handbook|Handbook]] (The [[GhostBSD User Handbook|Handbook]] is in development.)
* [https://www.freebsd.org/doc/handbook/ FreeBSD Handbook]
* [[Installation Guide]]
* [[How To Books]]
* [[Hardware Supported List]]
|-
|}
| style="width:50%" |
{| style="width:100%"
|-
|+
|
{| class="wikitable"
|-
|+ Willkommen zum [[GhostBSD Wiki:About|Wiki von GhostBSD]] - deiner Quelle für Dokumentation von GhostBSD im Web!
|-
| style="width:50%" |
{| style="width:100%"
|-
|+
=== [[GhostBSD]] verwenden ===
|-
|
* [[FAQ]]
* [[GhostBSD User Handbook|Handbuch]] (Das [[GhostBSD User Handbook|Handbuch]] ist in Entwicklung.)
* [https://www.freebsd.org/doc/de/books/handbook/ Handbuch von FreeBSD]
* [[Installation Guide]]
* [[How To Books]]
* [[Hardware Supported List]]
|-
|}
| style="width:50%" |
{| style="width:100%"
|-
|+
|
=== Developing [[GhostBSD]] ===
|-
|
* [[GhostBSD Roadmap]]
* [[Beta Testing]]
*
*
|-
|}
|-
| colspan="2" |
{|
|-
|+
==== Projects ====
|-
|
; [[GBI]]: GBI is a [[GTK]] front-end installer; it is developed to use [[pc-sysinstall]].
|
; [[Networkmgr]]: Networkmgr is a graphical tool for network management.
|
; [[pc-sysinstall]]: pc-sysinstall is a back-end installer which is in [[FreeBSD]] and is used by [[PC-BSD]] and [[GhostBSD]].
|}
|}
|
=== [[GhostBSD]] entwickeln ===
|-
|
* [[GhostBSD Roadmap]]
* [[Beta Testing]]
*
*
|-
|}
|-
| colspan="2" |
{|
|-
|+
==== Projekte ====
|-
|
; [[GBI]]: GBI ist ein Programm zum Intsallieren als Front-End ([[GTK]]); Es zum Verwenden von [[pc-sysinstall]] entwickelt.
|
; [[Networkmgr]]: Networkmgr ist ein grafisches Werkzeug zur Netzwerkverwaltung.
|
; [[pc-sysinstall]]: pc-sysinstall ist ein Programm zum Intsallieren als Back-End, welches es in [[FreeBSD]] gibt und von [[PC-BSD]] und [[GhostBSD]] verwendet wird.
|}
|}
|
--Vater (talk) 22:52, 13 November 2017 (AST)
adding OctoPkg next to GBI, Networkmgr and pc-sysinstall?
OctoPkg seems to become an essentially part of (the default of) GhostBSD or am i wrong?
