• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

55 PetaByte ZFS installation

Finally some validation for ZFS on Linux! I am running that exact port on my ZFS server at home, nowhere near that capacity, but still it's nice to know that this is production quality code! Hah! to any of you who said I would have problems with ZFS on Linux!
 
This is fantastic news! I've been on the fence about moving away from openindiana for my nas but this gives me the confidence to switch to linux very soon!
 
extide said:
Hah! to any of you who said I would have problems with ZFS on Linux!
Click to expand...
We did not mock ZFS/Linux users. My concern was this: what happens if Linux users start to loose data because of an immature ZFS port? Then ZFS would get a bad reputation: "ZFS is not safe, there are many users that lost data!". The fact they ran an immature ZFS implementation in beta stage would have not mattered, ZFS would get a bad reputation. To build up a good reputation takes many years, to loose it, takes just a few days. I would not like you to loose data, and then you go around and bad mouthing ZFS. That was my concern. Apparently, FreeBSD users are happy with ZFS, and they dont go around bad mouthing ZFS, so that is ok.

But some Linux supporters take every chance to bad mouth everything from Solaris. For instance, the Linux kernel developers that said ZFS is crap, because it is a "rampant layering violation" - implying it is a bad idea that the filesystem also has a raid manager built in. The reason ZFS can do all its magic, is because it has raid built in. ZFS knows of everything, from data to raid, and can detect errors that no one else would detect. Linux has separate layers; fileystems / raid manager / etc - and can not pass errors from one domain to another - and can not detect all errors.

The fact that BTRFS is now also a rampant layering violation, is not a problem any longer. As long as Linux does something, it is not a problem. But if Solaris does something, it is a problem. If rampant layering violation is that bad, why would Linux people design BTRFS to also do that, just as ZFS? Maybe BTRFS is just a ZFS copy? The BTRFS creator Chris Mason has officially said that he looks at ZFS to get good ideas to implement. For instance, in an interview he said he was convinced he should add checksums to catch bit rot, after the ZFS people raving about it so much in ZFS.

There are Linux people today that says BTRFS is not a ZFS copy, but even Chris Mason says it is a copy. In some years, those Linux people will probably say that ZFS has copied everything from BTRFS and that BTRFS was first, even though ZFS was released several years before BTRFS.



Oracle owns Lustre. Lustre is used on 80% of all large supercomputer installations. Sun had in the plans to port ZFS to Lustre, because with such large datasets, data corruption is bound to occur. Now the port is happening. :)
 
Awesome!

I still did not look at ZFS yet. Definitely something I want to look into if I build a SAN/NAS
 
brutalizer said:
We did not mock ZFS/Linux users. My concern was this: what happens if Linux users start to loose data because of an immature ZFS port? Then ZFS would get a bad reputation: "ZFS is not safe, there are many users that lost data!". The fact they ran an immature ZFS implementation in beta stage would have not mattered, ZFS would get a bad reputation. To build up a good reputation takes many years, to loose it, takes just a few days. I would not like you to loose data, and then you go around and bad mouthing ZFS. That was my concern. Apparently, FreeBSD users are happy with ZFS, and they dont go around bad mouthing ZFS, so that is ok.

But some Linux supporters take every chance to bad mouth everything from Solaris. For instance, the Linux kernel developers that said ZFS is crap, because it is a "rampant layering violation" - implying it is a bad idea that the filesystem also has a raid manager built in. The reason ZFS can do all its magic, is because it has raid built in. ZFS knows of everything, from data to raid, and can detect errors that no one else would detect. Linux has separate layers; fileystems / raid manager / etc - and can not pass errors from one domain to another - and can not detect all errors.

The fact that BTRFS is now also a rampant layering violation, is not a problem any longer. As long as Linux does something, it is not a problem. But if Solaris does something, it is a problem. If rampant layering violation is that bad, why would Linux people design BTRFS to also do that, just as ZFS? Maybe BTRFS is just a ZFS copy? The BTRFS creator Chris Mason has officially said that he looks at ZFS to get good ideas to implement. For instance, in an interview he said he was convinced he should add checksums to catch bit rot, after the ZFS people raving about it so much in ZFS.

There are Linux people today that says BTRFS is not a ZFS copy, but even Chris Mason says it is a copy. In some years, those Linux people will probably say that ZFS has copied everything from BTRFS and that BTRFS was first, even though ZFS was released several years before BTRFS.



Oracle owns Lustre. Lustre is used on 80% of all large supercomputer installations. Sun had in the plans to port ZFS to Lustre, because with such large datasets, data corruption is bound to occur. Now the port is happening. :)
Click to expand...

I see you certainly have a bit of an agenda here. If I had problems, I would figure out exactly what's wrong. I don't go randomly blaming people on the internet for problems I may have. My ZFS box is still in "test" mode. I have all my data on it, but I still have my data on my old storage system as well. I have had some MINOR bumps along the way (related to linux and/or the hardware, not ZFS) but have been able to always get everything working again, and haven't lost any data. So far I am pretty impressed with it but I wont be considering it in 'production' mode, even though it only my personal stuff at home, until I have spent more time with it.

I am not sure if you are the guy who said "Post when you have problem because you will" or something like that, but someone on here did, so if that wasn't you then my comment was not directed at you :)
 
bleomycin said:
This is fantastic news! I've been on the fence about moving away from openindiana for my nas but this gives me the confidence to switch to linux very soon!
Click to expand...

have fun with that. zfsol is NOT ready for production. if you read through that pdf and watched the video the dude says as much. once they fix the ZIL and direct drive control under linux then and only then should you consider moving over.

until then, OI and freeBSD are both MUCH better options.
 
While I agree that ZFSOL is not at the same place as it is on BSD or OI, LLNL seems to consider it production ready. They are deploying it and will continue to update the code as they go along. I'm not sure that I'd jump on it just yet, but it is tempting. I don't need the Quotas or Changelog stuff. The lack of ZIL might be an issue for some and Linux drive management issues is a bit nebulous. But I suspect for most people running a single server it's not that much of an issue.
 
define deploying it. rolling it out and running production style testing to find and then fix the remaining problems doesn't sound like production to me.

sounded to me like septemberish they expect it to be basically final RC beta or GA production ready. which is great btw, just sayin i wouldn't put anything intended for production up using ZFSOL until those releases.
 
fantastic! we have a name space cluster at nexenta that could probably get there...we just haven't had 55 pb of disk to test :)
 
I thought that licensing issues prevented a native ZFS port to Linux? Is this ZFS on fuse or what?

EDIT: dammit should have read the presentation.
 
extide said:
I am not sure if you are the guy who said "Post when you have problem because you will" or something like that, but someone on here did, so if that wasn't you then my comment was not directed at you :)
Click to expand...

I said "posted what you found" . reporting bugs to zfslinux bugs tracker or share your experience
this does not mean that you will face many problems :D, at least report to zfslinux bug tracker, this will speed up maturity of zfslinux.
as my understanding, many people are waiting stable (merging to linue kernel distribution, kernel.org) zfslinux:), we can have alternate to use zfslinux or mdadm.

I did not mock linux, actualy I make a living on linux and windows :), solaris as a hobby :D

in linux kernel works, the stable filesystem ( could be zfslinux in the future) will merge into kernel distribution :D.
that means... you can use on you real server ( not test server anymore).
 
cantalup said:
in linux kernel works, the stable filesystem ( could be zfslinux in the future) will merge into kernel distribution :D.
that means... you can use on you real server ( not test server anymore).
Click to expand...
I dont think ZFS will ever merge into a kernel distribution. This is because the CDDL and GPL licenses are not compatible.

One way to go around this problem is to separately download the ZFS source code and compile it into Linux. This is ok, I think. But no merge of ZFS into Linux by default.
 
brutalizer said:
I dont think ZFS will ever merge into a kernel distribution. This is because the CDDL and GPL licenses are not compatible.

One way to go around this problem is to separately download the ZFS source code and compile it into Linux. This is ok, I think. But no merge of ZFS into Linux by default.
Click to expand...

on my understanding, zfslinux would merge to kernel when zfslinux gpl is already get a green light to included in linux kernel distribution.

zfslinux try to make zfs to be gpl ,where linux licenses are GPL, and LGPL

you can check on zfslinux historical roadmap on it's website.

seperatting filesystem is possible, but ideally... porting to GPL is a breakthrough, this is where zfslinux tries to achieve :D.

as I posted on another thread, you can read on btrfs that is in limbo by oracle. btrfs is gpl. it looks like soon or later , btrfs forking could happens....
oracle is trying to play their role polticaly on open source movement, such as open solaris and their linux projects.

still remember mysql when in the oracle hand? :p.... forking anyone....
http://www.infoworld.com/d/open-source-software/non-oracle-mysql-fork-deemed-ready-prime-time-853
The lightweight, cloud-friendly Drizzle fork gives companies an escape from Oracle's clutches
 
Regarding your link on forking MySQL. Dont forget that the founder of MySQL who has founded MariaDB(?) says that Oracle has done a very good job on MySQL, it got nice performance boosts and functionality. He praises Oracle's work on MySQL. Something like "even if I dont like Oracle, they got good database engineers and have done a very good job on MySQL".
 
brutalizer said:
Regarding your link on forking MySQL. Dont forget that the founder of MySQL who has founded MariaDB(?) says that Oracle has done a very good job on MySQL, it got nice performance boosts and functionality. He praises Oracle's work on MySQL. Something like "even if I dont like Oracle, they got good database engineers and have done a very good job on MySQL".
Click to expand...

We can talk politically. Or practically.
Don't forget sun.
Oracle put some enhancement. On MySQL, but we should see MySQl 's life span.
I prefer talk practically
 
side-observer
Sorry, no link

1. It is suggested very clearly early in the day, Sun very carefully chose a license that does not intend for ZFS to be included in GPL fashion. (From start).
2. Sun however leaves an open route for FreeBSD type of scenario, for example.
3. While it is not wrong to very specifically try to workaround the limitation, in this case, try to build your own kernel module, instead of getting prebuilt Linux kernel module from official distribution (not allowed per license I believe)
4. in this case it is kind of obvious there is a seek. (seek! and the dependency is created)
5. As noted, Sun leaves an open route for FreeBSD/ZFS so you do have a choice there. Per the spirit, it seems sensible. Even OpenIndiana type of Sun derived distributions.
6. As per other option, BTRFS seems like a generally accepted upcoming Linux solution for many Linux developers and distributions.
7. Hence in all angles, it seems reasonable alternative options are widely available, if you really do not want to talk to Oracle/Solaris.

8. In knowing and avoiding all sensible options and instead insisting on such combination, it seems
(seek! and the dependency is created)

9. If you argue that other sensible options do not meet your particular needs, then you are suggesting a deficiency (seek, dependency, acknowledgement), Per reasonable generic circumstances, it seems discussion with Oracle to get special license arrangement maybe a choice as well?

10. Now do not get wrong impression. I am a Linux user for many years and accept that in many cases it performs great. As a matter of fact, Linux filesystems have very high performance frequently demonstrated in benchmarks. ( i put the statement here in case someone assumes bias. I am a regular Linux user)

just observation. I understand some will argue it is not in the spirit, but perfectly legal if you hand built everything on your own.
 
1) One of the problems with GPL is that it is too restrictive. If you build a product around GPL software, everything must be open sourced as GPL. This is a restriction. GPL is very infectious. It taints everything. Everything needs to be GPL and open sourced.

For instance, FreeBSD license is more free because it allows a company to close the source if they wish and still release their product. Thus, Sun could have used FreeBSD license instead of GPL, but chose not to. Instead Sun choose CDDL which is more free than GPL.
 
cantalup said:
I said "posted what you found" . reporting bugs to zfslinux bugs tracker or share your experience
this does not mean that you will face many problems :D, at least report to zfslinux bug tracker, this will speed up maturity of zfslinux.
as my understanding, many people are waiting stable (merging to linue kernel distribution, kernel.org) zfslinux:), we can have alternate to use zfslinux or mdadm.

I did not mock linux, actualy I make a living on linux and windows :), solaris as a hobby :D

in linux kernel works, the stable filesystem ( could be zfslinux in the future) will merge into kernel distribution :D.
that means... you can use on you real server ( not test server anymore).
Click to expand...

Well then I apologize, as I took the tone to be more aggressive and pessimistic. I will definitely write up bugs if/when I come across them. I have done QA work for many years and know plenty well how to write up good bugs :)
 
lightp2 said:
side-observer
Sorry, no link

1. It is suggested very clearly early in the day, Sun very carefully chose a license that does not intend for ZFS to be included in GPL fashion. (From start).
2. Sun however leaves an open route for FreeBSD type of scenario, for example.
3. While it is not wrong to very specifically try to workaround the limitation, in this case, try to build your own kernel module, instead of getting prebuilt Linux kernel module from official distribution (not allowed per license I believe)
4. in this case it is kind of obvious there is a seek. (seek! and the dependency is created)
5. As noted, Sun leaves an open route for FreeBSD/ZFS so you do have a choice there. Per the spirit, it seems sensible. Even OpenIndiana type of Sun derived distributions.
6. As per other option, BTRFS seems like a generally accepted upcoming Linux solution for many Linux developers and distributions.
7. Hence in all angles, it seems reasonable alternative options are widely available, if you really do not want to talk to Oracle/Solaris.

8. In knowing and avoiding all sensible options and instead insisting on such combination, it seems
(seek! and the dependency is created)

9. If you argue that other sensible options do not meet your particular needs, then you are suggesting a deficiency (seek, dependency, acknowledgement), Per reasonable generic circumstances, it seems discussion with Oracle to get special license arrangement maybe a choice as well?

10. Now do not get wrong impression. I am a Linux user for many years and accept that in many cases it performs great. As a matter of fact, Linux filesystems have very high performance frequently demonstrated in benchmarks. ( i put the statement here in case someone assumes bias. I am a regular Linux user)

just observation. I understand some will argue it is not in the spirit, but perfectly legal if you hand built everything on your own.
Click to expand...

we are not in"perfect world"

Sun is a long gone. Oracle is in charge .

btrfs is still in a limbo shape. you can read mailing lists. Oracle is the driver for btrfs ( and not much development on btfs, open community has lend their hands, bug reports, offering patching... but oracle is shown no interests :p)
as I said, if some group are fed up with btrfs development, they could fork btrfs as forking is a common in open source community.


as I remember with my wording... the guy who drove ext4 said " ext4 put some enhancement to legacy ext3, not a breakthrough filesystem in linux).
people can use XFS or other filesystem
Actually, we need a breakthrough for at least a filesystem on linux.
the list is zfs(native) and btrfs.
 
brutalizer said:
1) One of the problems with GPL is that it is too restrictive. If you build a product around GPL software, everything must be open sourced as GPL. This is a restriction. GPL is very infectious. It taints everything. Everything needs to be GPL and open sourced.

For instance, FreeBSD license is more free because it allows a company to close the source if they wish and still release their product. Thus, Sun could have used FreeBSD license instead of GPL, but chose not to. Instead Sun choose CDDL which is more free than GPL.
Click to expand...

nothing perfect hahaha

you can argue CDDL versus GPL without conclusion :p

linux is using GPL, there are limitation and not perfect. CDDL has the same situation too :)

FreeBSD, aha... I just flashback to minix when learn my OS/data structured class with textbooks authored by tanenbaum http://www.cs.vu.nl/~ast/ hehehe.
and
I remember to read a book discussed on minix and linux ( version 0.X) :p. interesting book that discussed GPL/BSD/others license.

I would say, pick the right one for you best interests. those could be zfs, mdadm, hardware raid or others.
 
cantalup said:
Actually, we need a breakthrough for at least a filesystem on linux.
the list is zfs(native) and btrfs.
Click to expand...

Btrfs may be a future option for Linux only.
I hope for a common filesystem for all but Windows and this is ZFS,
already available on FreeBSD, Linux (native), OSX and any Solaris based OS's:
(I would be happy to see a Windows port too)
 
_Gea said:
Btrfs may be a future option for Linux only.
I hope for a common filesystem for all but Windows and this is ZFS,
already available on FreeBSD, Linux (native), OSX and any Solaris based OS's:
(I would be happy to see a Windows port too)
Click to expand...

I mentioned for linux :D

native zfs on linux still need a long journey. I would say better future than btrfs :p.

nothing for a common filesystem. we should see a modern filesystem approach after zfs.

porting zfs to windows? well this is a tough luck, since windows OS implementation is controlled by microsoft and totally different.
you can ask people whom porting unix world ( flavor) to windows, many workarounds.

I had projects in the past for porting linux apps to windows (XP and newer at that time). this was totally insane.. at the end....running linux on virtual machine with setting socket connections with front-end (windows) worked well :)
 
cantalup said:
nothing for a common filesystem. we should see a modern filesystem approach after zfs.
Click to expand...

There is always evolution. But ZFS was revolution 10 years ago when development begins, now 10 years later it is ready to use.
Even btrfs and Winfs, the most modern alternatives are not yet comparable.
 
_Gea said:
There is always evolution. But ZFS was revolution 10 years ago when development begins, now 10 years later it is ready to use.
Even btrfs and Winfs, the most modern alternatives are not yet comparable.
Click to expand...

I'm not worry about filesystem and raid(software or hardware).

you can search on btrfs or other filesystems in development aka not mature or stable.

in 10 years in the future, we should see something "new" filesystem :D.

native zfs(gpl version) linux is not mature too :p. this takes time and constant development including bug reports and fixing/enhancement.

we should not worry as long as the technology/software that you picked fits the bill and the goal accomplishments.
 
cantalup said:
in 10 years in the future, we should see something "new" filesystem :D.
Click to expand...
I dont think so. Before ZFS, all filesystems looked exactly the same since the dawn of the first floppy disks / first hard disks for 30-40 years. The first hard disks were small, and all filesystems have been designed to handle small disks. ext, JFS, NTFS, etc - all are just improved and improved old filesystem at the bottom.

Now, when we have 20TB raids, or even 100TB or Petabyte raid - new problems arise that the old filesystems never were designed for:
-No checksums to protect and detect against data corruption. The more data, the higher risk for data corruption
-Separate Raid manager, 3rd party software needed
-No snapshots (no CoW)
-Need to take filesystem off line to look for errors, fsck, chkdsk. How long does it take to fsck/chkdsk 55 PetaByte? Months? You can not have a filesystem off line for a month. You must do it online on a live filesystem. fsck unusable for large installations.
-No automatic self healing
-Scales bad. Problematic at PetaByte installations as performance decreases, or million files in one directory becomes very slow to list. Just look at the presentation in the first post here.
-etc

But ZFS was a game changer:
1) Checksums to protect and detect against data corruption
2) Everything is built in; raid manager, filesystems, etc. This means that ZFS can repair errors everywhere. Errors in raid, or on disk, or filesystem, etc - much more powerful than having separate layers.
3) Snapshots in place. CoW. How does Apple Time Machine do snapshots? Copy everything to another disk, and backup everything there! This is not CoW, but legacy and bad antique solution. ZFS does not need additional extra disks to do snapshots, it can do snapshots in place thanks to CoW
4) No need to take filesystem offline to look for errors. You can "scrub" on a live, using filesystem. There is no fsck command. This works fine for PetaByte installations, no need to pause work for a month.
5) Automatic self healing
6) Scales extremely well, up to 55 PetaByte and beyond. ZFS is 128 bits.
-etc

and now several filesystems mimic ZFS, for instance Oracle Btrfs, Windows ReFS. They all have 1) checksums, 2) raid manager built in, 3) CoW, etc. But they dont have 4) I think because BTRFS does need a "fsck" command, this proves the BTRFS team has not figured out how to do a GOOD automatic self healing. ZFS does not need fsck and has no fsck command, because ZFS is self healing. I dont know how good BTRFS and ReFS will scale, as they are only 64 bits.

Linux kernel developer Andrew Morton said that to combine several layers including raid is just bad. They did not understand that the power of ZFS, comes from the fact that all layers are built in. If there is an error in raid, or on disk, or anywhere, then ZFS can repair that error, because ZFS controls everything. If you have separate layers, then you can only repair errors in one layer, you can not repair errors that go through two layers. Now BTRFS also combines several layers into one. Which Linux kernel developers said was very bad to do.

Probably there will be more ZFS like filesystems too in the future from Apple, etc.


My point is that ZFS is so new and radical that it will serve us fine for the foreseeable future. For instance, if you want to fully populate one zpool, and completely fill it with data - then you need to move such many electrons to the disks that all oceans on the earth would vaporize. You would need so much energy that there would be no more water on earth, everything would be steam. How many 10TB disks are needed to fill up one zpool? It is something like, the weight of the entire earth - that many harddisks are needed. Mankind will never manufacture this many hard disks. Mankind will never control or create so much energy that we can boil away all oceans on earth.

Thus, you will not ever need another filesystem. The limits are so big they will never be encountered. ZFS is limit less. No limits. 128 bit filesystem is all mankind will ever need. No need for more bits. In other words; ZFS scales extremely well. Down from 1GB RAM pcs up to the future biggest installations where 55 PetaBytes would be considered tiny.

So my prediction is that all future filesystems will be very similar to ZFS, but have only minor improvements. They will all try to catch data corruption, have CoW, raid manager built in, self healing, etc. Maybe a few other functions, but they will all be a ZFS derivative.

64 bit filesystem will have a zpool that in 15 years from now, will be filled up completely. And you need to create a new pool. 2^64 bits are something like 1000 PetaBytes or so. Even today we have 55 PB. To reach 1000 PB, is only a factor 20x. We will reach that in 15 years or so. Then BTRFS needs to be redesigned to handle 72 bits, or 80 bits or so. I dont understand why BTRFS did not go for 128 bits at once?
 
not likely. i did the math for what it would take to hit the single file size limit of 16 EB not to long ago. just to hit 16EB takes iirc 54.4 thousand 3TB hard drives which at about 4.5 watts per disk, presuming 5300rpm drives, consumes 244,800 watts just to power the drives.

that is just the single file size limitation. i think it is fairly safe to say that ZFS will be the last magnetic type file system you will ever 'need'. even with seagates supposed 60TB drives 10 years from now it just isn't realistic that you'll ever get close to hitting even this single file size limitation in 99.99% of production environments. the HPC guys, yeah they may get close to 16EB of raw or even usable space but that is still just the single file size limitation which is nowhere close to 256 quadrillion zetabytes.

if quantum computing with 3 dimensional optical storage and some of the theorized densities of that ever become a reality then things change. we could then theoretically hit the limitations but again we're talking about more electrical power than man has ever generated and that is counting every single watt hour ever produced in the history of electricity. we would need tony fucking stark to come out of the comic books and create thousands of his arc reactors to get close.
 
LoL, I remember my 10 MB MFM hard drive being so big, it would never be possible to fill it up.
 
Yes, a single file can be maximum 16 Exabyte in ZFS. That is 54.400 Hard disks 3TB each. Just as madrebel explained.

The entire zpool can store 2^128 bit data. And if that is not enough, then create another zpool. You can have two or more zpools. Theoretically, all data that mankind have ever created, or will ever produce in the future, can be stored in one single zpool. If you use 3TB disks, then you need as many disks as 100 moon weighs. How many kg does the moon weigh? Well, you need the weight of 100 moons to fill up one zpool:
https://blogs.oracle.com/dcb/entry/zfs_boils_the_ocean_consumes

Suffice to say, 2^128 bits is all the storage mankind will ever need. All atoms in the universe are 10^78. Something like 2^128
 
brutalizer said:
I dont think so. Before ZFS, all filesystems looked exactly the same since the dawn of the first floppy disks / first hard disks for 30-40 years. The first hard disks were small, and all filesystems have been designed to handle small disks. ext, JFS, NTFS, etc - all are just improved and improved old filesystem at the bottom.

N.....
Click to expand...

only time will tell :D, I would say "we should some new filesystems or improved file systems"
see you in 10 years :D

layer on software linux raid is designed when we need software raid, this is bad? yeah, this is stable? yeah, this is perfect? No. and along with question

as I said, you can not compare linux sofware raid and zfs at start. you can check my posting :p.

oh my.. btrfs still in development:p. on my side, I can not compare zfs with btrfs hehehhe.
I would travel via time machine to see btrfs 10 years in the future :D.
 
brutalizer said:
All atoms in the universe are 10^78. Something like 2^128
Click to expand...

Your math is WAY off. I think that may be the largest mathematical mistake I have ever seen or heard of. Have you considered working for an investment bank?

You are off by a factor of more than 10^39.

2^128 = 3.4 * 10^38
 
Thankfully, "real world scenarios" where fsck is needed for ZFS seems extremely rare. At least, I haven't heard of anything that bad. On the other hand, I've heard plenty of problems with NTFS filesystems needing to be recreated from scratch.

JoeComp, i'm feeling really lazy, so maybe you can find some examples where many people lost everything on a ZFS pool that wasn't user error and wasn't due to too many drives failing in a RAIDZ? I would love to know, but I have other things to worry about at the moment.
 
And yes, fsck-like tool for ZFS would be great - would take care of those (super rare?) cases where it would be needed.

In the meantime, I suppose we could all switch to btrfs - I don't know the status of it - is it feature complete now?
 
Rectal Prolapse said:
JoeComp, i'm feeling really lazy, so maybe you can find some examples where many people lost everything on a ZFS pool that wasn't user error and wasn't due to too many drives failing in a RAIDZ? I would love to know, but I have other things to worry about at the moment.
Click to expand...

You certainly are lazy. You couldn't even be bothered to read the link I ALREADY provided?
 
You must log in or register to reply here.
Back
Top