Originally posted by trilean
View Post
Announcement
Collapse
No announcement yet.
How Three BSD Operating Systems Compare To Ten Linux Distributions
Collapse
X
-
I am by now (member of phoronix couple of months) detecting a pattern.
Have some article comparing BSD with Linux appearing.. you got crowd of "penguin friends" descending (30+ posts) on it like vultures bashing Sun or random BSD for all it's worth.. starting usually with mr. SystemCrasher, his "cow filesystems"TM and "sun marketing bs"TM remarks...
It's bit like Russian web trolls under random political article in Northern/Eastern Europe.
Have some neutral BSD news or announcement, none of this crowd deigns to comment on it.
Is it caused by some sort of complicated form of inferiority complex? Need to prove how superior THEIR FAVORITE OS is? Honestly curious..
- Likes 1
Comment
-
"You got it backwards. ZFS is not fragile, it is the most robust filesystem there is out there. ZFS is built with a focus on data integrity, to be robust and protect your data."a
Originally posted by SystemCrasher View PostSounds like Sun's marketing bullshit.
For isntance, there are several research papers out there, by independent comp sci researchers, that all conclude that ZFS is safe. Those links can be found on the wikipedia article on ZFS in the section about data integrity - if you care to read about what researcher say. I agree with you that you should be sceptical to everything you hear, that is very sound and intelligent. But in this case, about ZFS claims about superior reliability - these claims are backed up by several independent researchers. OTOH, there is no research showing that BTRFS is safe, so I would be a bit hesitant of trusting BTRFS - for exactly the same reason you are sceptical of ZFS claims of data integrity:
- Sun claims ZFS is very safe - you are sceptical and dont trust ZFS because it might be marketing. But there are research papers out there confirming ZFS is superior.
- BTRFS claims to be safe (who says it btw?) - I am sceptical and dont trust BTRFS because it might be marketing. There are no research papers out there confirming BTRFS is safe. No researchers have examined BTRFS. If you know of such research papers, please post them. I would like to learn more.
So, if you look at what science says, it seems ZFS is safer than BTRFS.
Research papers shows that other filesystems such as XFS, NTFS, etc -are unsafe and might corrupt your data. Research papers can be found in the same wikipedia section on ZFS data integrity.
Yet, googling a bit can yeld some funny "success stories". When someone tells "Enterprise" you should expect catch, and marketing promises would wildly exceed practical performance.
Checksumming isn't worst part of ZFS, sure. They used quite good tradeoffs in terms of checksumming strength vs speed. On other hand, many other engineering solutions are much less sound. No defragger? While CoW inherently means fragments on write? And only lame mumblings about adding new drives? Skipping "good luck to remove them later" catch? Staying silent about bad sectors would bring thing down and no tools would be able to fix that? That's what called MARKETING BULLSHIT. Sure, sun was good at it. That's what I dislike about Sun and their products.
"For isntance, hard disks have lot of checksums on the surface to detect data corruption - and still you get data corruption on hard disks"
XFS can't do full journalling, to begin with. It would journal metadata only, so you can get half-old, half-new data in file if crash happens. There is no data to complete or rollback DATA part. Needless to say, file can get unusable. So speaking about reliability sounds funny for such designs. In classic designs, journalling takes one write to journal and one into storage. Hence writing data twice. It kills write speed by at least 2x. Nobody in sane mind uses e.g. EXT4 in this mode. So XFS, JFS and some few others do not even implement full journalling. OTOH CoW based things avoid it in some smartass way, where whole storage area is basically a "journal". That's why most futuristic designs are centered around CoW these days. Full journalling at no-journalling speed. But there're some other catches .
The problem with storage is that traditionally you have different layers: filesystem layer, raid layer, volume management layer, etc etc. And data might be checksummed on each layer to catch data corruption, but when data passes one layer to another there might be corruption because the checksum is not passed. This means data might be corrupted when you have many layers. ZFS is very different, it is monolithic. ZFS is in charge of everything: filesystem, raid, volume manager, etc etc. This means the checksums in ZFS is always known to every layer. This is the one of the many reasons ZFS is safe: it is monolithic so every layer have access to the same checksum. This means the data on ZFS in both ends of the chain is verified: data is verified on disk, all the way up to the other side (i.e. RAM if you wish). That is, end-to-end checksums. Have you played this game as a kid? All kids sits in a ring, and one whispers a word to the next, who whispers the same word to the next, etc. Then you compare the words from the beginning and at the end: they always differ. You need to be sure that the words at the beginning and at the end agrees: end-to-end.
Funnily, the Linux kernel developers have called ZFS and abomination because it is an "rampant layering violation":
I stumbled upon a great article (via Ars Technica) by Jeff Bonwick, responding to Andrew Morton's claim that ZFS is a "rampant layering violation" because it cuts across the traditionally separate worlds of the filesystem, volume manager, and RAID controller. I think ZFS is a brilliant invention and believe it'll go far. It removes complexity and cost, improves data reliability and generally makes people's (both sysadmins & desktop users) lives soooo much easier. Too many times I've had to be the bearer of bad news and let a customer know their data is corrupt and they'll have to restore from backup. Most of the time we can work out where the problem has occurred and take the necessary steps to prevent or reduce the chances of it from occurring again. However there are times, particularly when dealing with 3rd party storage and it's associated software, that an explanation can't be found and I have to refer the customer to the 3rd party vendor. These problems are invariably due to over complexity in the storage stack. Whilst ZFS does have it's limitations (can't shrink or boot from ZFS just yet), work is in place to remove these limitations. Remember, ZFS is in it's infancy - all it's competitors have been in the public sector for many many years. One of the comments on Jeff's post caught my eye (I've copied part of it verbatim)... first, it is my understanding that sun chose a particular open-license to prevent zfs to make it into the linux kernel. this is unfortunate. with zfs coming to mac osx soon, zfs is the chance for sun to basically implement and benevolently control the future direction of one file system to conquer them all. (hey, sun: how about releasing a slower version for linux that's got the extra useless layer as dummy calls, and that allows me to mount a zfs partition/disk on a sun or on a max osx or on a linux machine?) second, is it not possible for zfs to plug into the upper linux layer for its interface, use the intermediate parts that it has itself rather than calling on linux, and rely only on the lowest linux hardware layer? This is typical of a lot of people in the Linux community and is quite childish - "he's got a nice shiny new toy and he won't let me play with it". Sun is not preventing Linux from doing anything, it's own license is. In fact there is enough Linux compatible code out there for some enterprising Linux developer to work on their own ZFS port. Remember, the only reason ZFS has made it into FreeBSD and OS X is because their licenses aren't so aggressive towards other licenses. I'm a big fan of Linux, but not of this kind of mentality. The operating system space is big enough for all of us - it's not a Linux vs MS world. Get over it.
Linux kernel developers says ZFS is bad design because it is not layered, it is monolithic. Well, the reason ZFS is safe is BECAUSE it is monolithic. It seems that the Linux kernel devs did not really understood the design criteria behind ZFS and why it was built like that weird. The reason was because everything in ZFS revolves around data integrity. If ZFS did not care about data integrity, it would be layered just like all traditional filesystems on Linux. But ZFS is different because it's highest priority is data integrity, not performance. In Enterprise, you care about reliability, not performance. If a big business server goes down, you might loose $billions. Performance is secondary, reliability is the top priority. That is why Mainframes have sometimes triple cpus, same computation is calculated on two cpus and if they differ, a third cpu will disconnect the faulty cpu. etc etc. In enterprise arena, reliability and data integrity is top priority. Chris Mason, a desktop developer, has no clue of this.
The weird thing is that BTRFS is also a monolithic "rampant layering violation". It is funny how Linux kernel developers mocked ZFS, and then after a few years, did a similar clone even though they first agreed that ZFS is badly designed (Linux devs did not understand ZFS weird design because of it's purpose: data integrity).
I do not give a fuck about "since 1929" stuff, but I do care about technical excellence, solving difficult challenges, good performance, interesting designs, good algos, inner working of things, etc.
Come on, keep quoting Sun's marketing BS. Yet, if we google a bit, we'll see some ppl around who had ZFS fucked up and .. no good means to recover. It do not have to be fsck, etc, but if filesystem's metadata are damaged to degree driver can't mount it properly, it could be good idea to have some "plan B", either to parse all metadata, check them carefully and recover like fsck tools do, or at least being able to read data back with relaxed demands on metadata integrity.
And the need for "fsck" has not been that great, the ZFS forums are not crowded with threads about people loosing their data and requiring "fsck". I dont see a great demand for "fsck" for ZFS.
This makes vague assumption all involved data are valid and it works reasonably. But it may or may not be a case. CoW can have rather specific failure modes and snapshots are anything but backup replacement. E.g. if someone had 5 snapshots, they shared blocks and bad sectors appeared here, all 5 snapshots are going to be ruined at once. Going back in time may or may not succeed. Depends on how badly metadata are damaged, and actually, if one got severe corruption, trying tricks like this can easily make things worse, because CoW can get stuck half way while trying to rewind back, hanging in the middle of nowhere. Read-only recovery to another destination allows to avoid this problem - it does not touches original storage, so failure at least can't develop any further. And one can try to select various "entry points" to try to parse them.
Unless there is some pesky bad sector appears and it happens there was no redundancy. At this point ZFS easily fucked up and really hard to repair. Because Sun architects preferred to mumble "always valid" and had no plan B for scenarios this assumption has failed. And I've seen a few, where it has been the case. So ppl had a lot of very specific fun. I think it can be better than that and not really fond being fed by marketing BS instead of technical solutions.
At the end you are free to have your opinion, but several researchers say ZFS is safe, and they say other filesystems are not safe. And it is a fact that many (all?) OSes wants ZFS, for instance Linux. If ZFS was bad, interest would die in this geeky computer world. Marketing can only uphold an interest for so long time, eventually, the true qualities will prevail. And many nerds such as me (or you) and other savvy developers, can think for ourselves. And who promotes ZFS today in Linux? It is the nerds. They dont fall for the marketing that ZFS spewed out 10 years ago (ZFS is 15 years old today). FreeBSD wants ZFS, Linux wants it, Apple has it, etc. There might be some merit in ZFS? Have you even tried it? If we talk about Solaris DTrace, which was also marketed by Sun, we see today what OSes have it or recenlty ported/copied it. I doubt Sun marketing is so powerful to make every major OS have ported/copied DTrace or ZFS? These OSes have a copy of DTrace or ported it. And probably a few other OSes I dont know of have DTrace:
1) FreeBSD
2) Mac OS X
3) QNX
4) IBM AIX have a copy called ProbeVue
5) VMware have a copy called vProbes (they even credit DTrace explicitly)
6) Linux have a copy called Systemtap (the developers first talked about DTrace a lot, and then deleted all references to DTrace because they did not want to give credit: https://blogs.oracle.com/ahl/entry/dtrace_knockoffs ). Now Linux also have DTrace via Oracle Linux distro.
- Likes 1
Comment
-
Originally posted by kebabbert View PostWell, you can not disagree that ZFS is the first common filesystem that had checksums to detect data corruption.
Ive read an old interview with Chris Mason that after he read some articles of ZFS data integrity, only then he realized that checksums should be added to BTRFS.
I see no point trying to fool myself and I do care about convenient and pleasant ways to manage my systems without weird, impractical, unnatural or inconvenient assumptions. Somehow I got to think btrfs is quite close to being like this, but I can't tell the same about ZFS, which makes different assumptions.
It is an afterthought. Mason did not know the importance of detecting data corruption in very large datasets. Sun had vast experience of large data sets and the problems that might occur in large storage.
Mason, a desktop developer, had not that experience of large storage servers. Thus, ZFS was the first filesystem out there, and still today, many considers ZFS be the safest filesystem out there. So, it seems very probable that Sun's aim of designing a new filesystem with a focus on data integrity and reliability is true. No other filesystem is in the same league in terms of data integrity according to several independent comp sci research groups.
For isntance, there are several research papers out there, by independent comp sci researchers, that all conclude that ZFS is safe. Those links can be found on the wikipedia article on ZFS in the section about data integrity - if you care to read about what researcher say.
I agree with you that you should be sceptical to everything you hear, that is very sound and intelligent. But in this case, about ZFS claims about superior reliability - these claims are backed up by several independent researchers. OTOH, there is no research showing that BTRFS is safe,
so I would be a bit hesitant of trusting BTRFS - for exactly the same reason you are sceptical of ZFS claims of data integrity:
- Sun claims ZFS is very safe - you are sceptical and dont trust ZFS because it might be marketing[....]BTRFS claims to be safe (who says it btw?) - I am sceptical and dont trust BTRFS because it might be marketing.
So, if you look at what science says, it seems ZFS is safer than BTRFS.
Research papers shows that other filesystems such as XFS, NTFS, etc -are unsafe and might corrupt your data. Research papers can be found in the same wikipedia section on ZFS data integrity.
I agree that no filesystem is 100% safe, but yet, there are fewer "success stories" on ZFS than other filesystems / RAID. For instance, if you look at the ZFS forums, and someone have problems, almost in all cases the problems are solved.
Very often when you see that someone says ZFS reports data corruption or they can not import the data zpool, it turns out to be a hardware problem: flaky PSU, sata cable slightly slighty loose, faulty RAM stick, etc. And when they fix the hardware problem the problems are gone and they can import the zpool again.
OTOH, have you read the BTRFS forums? Full of reports of data corruption, etc. The wiki says "Q:Is BTRFS safe? A:It depends". I doubt you will find research papers out there soon, claiming that BTRFS is safe.
You are free to have an opinion about Sun, but in this case: science says ZFS is safe, whereas other solutions are not safe.
Regarding "staying silent about bad sectors" - ZFS reports all such problems and repair them immediately. Many (all?) other filesystems can not even detect all forms of data corruption, so how can they repair those data corruption cases?
ZFS detects all types of data corruption, according to researchers, and according to the same research paper, ZFS repairs all those corruption cases too. It is easy, because when ZFS detects corruption, it is just a matter of retrieving a correct data block and replace the faulty. Which is what ZFS does. Read the research paper (on wikipedia article on ZFS data integrity).
"For isntance, hard disks have lot of checksums on the surface to detect data corruption - and still you get data corruption on hard disks"
Data corruption protection is not provided by journaling. You need checksums to get full data integrity.
But, you need a special kind of checksums. Ordinary checksums will not do. This is evidenced by hard disks having lot of error correcting codes to combat data corruption - and still hard disks get data corruption. No, you must use end-to-end checksums to get full data integrity.
The problem with storage is that traditionally you have different layers: filesystem layer, raid layer, volume management layer, etc etc. And data might be checksummed on each layer to catch data corruption, but when data passes one layer to another there might be corruption because the checksum is not passed. This means data might be corrupted when you have many layers. ZFS is very different, it is monolithic. ZFS is in charge of everything: filesystem, raid, volume manager, etc etc.
You need to be sure that the words at the beginning and at the end agrees: end-to-end.
Linux kernel developers says ZFS is bad design because it is not layered, it is monolithic. Well, the reason ZFS is safe is BECAUSE it is monolithic.
It seems that the Linux kernel devs did not really understood the design criteria behind ZFS and why it was built like that weird. The reason was because everything in ZFS revolves around data integrity.
If ZFS did not care about data integrity, it would be layered just like all traditional filesystems on Linux.
The weird thing is that BTRFS is also a monolithic "rampant layering violation". It is funny how Linux kernel developers mocked ZFS, and then after a few years, did a similar clone even though they first agreed that ZFS is badly designed (Linux devs did not understand ZFS weird design because of it's purpose: data integrity).
A true nerd! Me like. I am also like you. I care about technical excellence, and I back it up with science and research papers and studies. There is a reason everybody wants ZFS and it is hyped: it is safe.
You know, ZFS "scrub" checks/repairs the metadata and the data. "fsck" is not really trustworthy.
For instance, sometimes when you fsck or "chkdsk" a 10TB raid array, it will complete in a few minutes. But to really read and traverse 10 TB data,
And the need for "fsck" has not been that great, the ZFS forums are not crowded with threads about people loosing their data and requiring "fsck". I dont see a great demand for "fsck" for ZFS.
[quote]The metadata on ZFS is always duplicated all over the raid or disk. If it is damaged, you can always get another correct copy.[quote]
This "always" assumption sounds too vague and implies it would show me what EPIC FAIL means if it happens other way. Btrfs also DUPs metadata on single drive by default, but it also provides set of tools I would prefer to have for each and every filesystem. Good tooling is advantage of filesystem.
There are not 5 snapshots on ZFS. Every time you write data to the disk/array, the data is written to a new place. The old data is never touched.
At the end you are free to have your opinion, but several researchers say ZFS is safe, and they say other filesystems are not safe.
And it is a fact that many (all?) OSes wants ZFS, for instance Linux.
Solaris DTrace, which was also marketed by Sun, we see today what OSes have it or recenlty ported/copied it.Last edited by SystemCrasher; 07 March 2016, 03:49 PM.
Comment
-
Originally posted by SystemCrasher View PostRight, but I had quite heated discussion with some Gentoo dev here on Phoronix. Even he has admitted ZFS does checksumming in quite a specific way it brings some major tradeoffs. Somehow I do not think these tradeoffs are best for me in most usecases I care of.
It is true zfs will get fragmented over time, and it does not have a defragger. To decrease fragmentation, zfs will write only every fifth second to disk. In worst case, if you really must defrag, you can send the data to another server and back again. I agree it is a pain, but it is doable.
It is also a problem to change the number of disks in a vdev, it can not be done. But you can add another vdev. A zpool consists of one or more vdevs. Each vdev is configured as raid5 or raid6 or mirror. So, you can always add a new vdev, but never change the nr of disks in a vdev.
If you have a single disk, you can use "copies=2" switch, which will duplicate all data twice effectively halve the disk capacity. The metadata is always riddled all over the disk in mutiple copies, so it does not need to be backupped. "Copies=3" also works. No other filesystem can do this.
Regarding zfs is only fine on highend hardware, that is not really strictly correct. First, If you have non ecc ram, and you get corrupt dimm, zfs will not corrupt your data. I can give you a technical link on this, if you wish. This is a misconception that is not true (zfs will eat your data if you have corrupt non ecc ram) as well as the misconception that zfs needs more than 2 gb ram in a server to function well. No, instead i would argue the opposite: if you have cheap hardware, then you should use zfs to give extra protection in form of software. For instance, zfs detects flaky psu. Wouldnt it be good to know as soon as you have the slightest problem in your hardware? Zfs detects all those problems. Immediately. With high end stuff, it is reliable in itself so the need for extra protection as zfs decreases. It is when you have cheap stuff, you need extra protection. Zfs makes cheap stuff very very reliable. And on server graded hardware such as xeon, ecc ram, zfs will boost data integrity into enterprise quality arena. So i would say, the worse hardware you have, the greater the need to get safe software that will immediately detect loose sata cables, faulty ram dimms, etc. In high end stuff, you dont need the extra protection as much.
Have you ever tried zfs? Just curious...
Comment
-
Originally posted by aht0 View PostI am by now (member of phoronix couple of months) detecting a pattern.
Have some article comparing BSD with Linux appearing.. you got crowd of "penguin friends" descending (30+ posts) on it like vultures bashing Sun or random BSD for all it's worth.. starting usually with mr. SystemCrasher, his "cow filesystems"TM and "sun marketing bs"TM remarks...
It's bit like Russian web trolls under random political article in Northern/Eastern Europe.
Have some neutral BSD news or announcement, none of this crowd deigns to comment on it.
Is it caused by some sort of complicated form of inferiority complex? Need to prove how superior THEIR FAVORITE OS is? Honestly curious..
Windows Server is relatively secure against criticism by these Linux Trolls. Well, it is proprietary and expensive, there is an evil corporation... but technically it is not worse than Linux, it's well known, fast powerful, it frees us from systemd and other linuxisms.
Comment
-
Originally posted by Michael View Post
Sans file-system differences, past tests I've done haven't shown much difference between PC-BSD and FreeBSD when using the same kernel and compiler.
PC-BSD loads lots of stuff during start, it's no longer fully compatible with a vanilla FreeBSD (try using PC-BSD with a UFS2 doing "expert" fs selection in terminal, afterwards you will running into incompatibilities very fast once you try updating the system etc. Except for first brief glance, it's derivative of FreeBSD, not pure FreeBSD.
Thanks for a tip regarding Windows Server :PLast edited by aht0; 10 March 2016, 03:14 PM.
Comment
Comment