Re: [zfs-discuss] RFE: Un-dedup for unique blocks
From: Richard Elling [mailto:richard.ell...@gmail.com] I disagree the ZFS is developmentally challenged. As an IT consultant, 8 years ago before I heard of ZFS, it was always easy to sell Ontap, as long as it fit into the budget. 5 years ago, whenever I told customers about ZFS, it was always a quick easy sell. Nowadays, anybody who's heard of it says they don't want it, because they believe it's a dying product, and they're putting their bets on linux instead. I try to convince them otherwise, but I'm trying to buck the word on the street. They don't listen, however much sense I make. I can only sell ZFS to customers nowadays, who have still never heard of it. Developmentally challenged doesn't mean there is no development taking place. It means the largest development effort is working closed-source, and not available for free (except some purposes), so some consumers are going to follow their path, while others are going to follow the open source branch illumos path, which means both disunity amongst developers and disunity amongst consumers, and incompatibility amongst products. So far, in the illumos branch, I've only seen bugfixes introduced since zpool 28, no significant introduction of new features. (Unlike the oracle branch, which is just as easy to sell as ontap). Which presents a challenge. Hence the term, challenged. Right now, ZFS is the leading product as far as I'm concerned. Better than MS VSS, better than Ontap, better than BTRFS. It is my personal opinion that one day BTRFS will eclipse ZFS due to oracle's unsupportive strategy causing disparity and lowering consumer demand for zfs, but of course, that's just a personal opinion prediction for the future, which has yet to be seen. So far, every time I evaluate BTRFS, it fails spectacularly, but the last time I did, was about a year ago. I'm due for a BTRFS re-evaluation now. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] RFE: Un-dedup for unique blocks
Zfs on linux (ZOL) has made some pretty impressive strides over the last year or so... ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Resilver w/o errors vs. scrub with errors
On 2013-01-21 07:06, Stephan Budach wrote: Are there switch stats on whether it has seen media errors? Has anybody gotton QLogic's SanSurfer to work with anything newer than Java 1.4.2? ;) I checked the logs on my switches and they don't seem to indicate such issues, but I am lacking the real-time monitoring that the old SanSurfer provides. I don't know what that is except by your message's context, but can't you install JDK 1.4.2 on your system or in a VM, and set up a script or batch file to launch the SanSurfer with the specific JAVA_HOME and PATH values? ;) Or the problem is in finding the old Java version? //Jim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] OT FS : STEC ZeusRAM devices
Sorry to spam the list, but wondering if anyone has any interest : Due to political motivations, my current employer has decided to stop utilizing ZFS based storage systems. This has left us with some Stec ZeusRAM devices that we now have no use for. Purchased brand new from Avnet in August of 2011, put into service in September, used for approx. 1 year. We have 6x disks available - part number Z4RZF3D-8UC. If anyone is interested, please email me off-list. -Matt Breitbach ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] RFE: Un-dedup for unique blocks
On 01/21/2013 02:28 PM, Edward Ned Harvey (opensolarisisdeadlongliveopensolaris) wrote: From: Richard Elling [mailto:richard.ell...@gmail.com] I disagree the ZFS is developmentally challenged. As an IT consultant, 8 years ago before I heard of ZFS, it was always easy to sell Ontap, as long as it fit into the budget. 5 years ago, whenever I told customers about ZFS, it was always a quick easy sell. Nowadays, anybody who's heard of it says they don't want it, because they believe it's a dying product, and they're putting their bets on linux instead. I try to convince them otherwise, but I'm trying to buck the word on the street. They don't listen, however much sense I make. I can only sell ZFS to customers nowadays, who have still never heard of it. Yes, Oracle did some serious damage to ZFS' and its own reputation. My former employer used to be an almost exclusive Sun-shop. The moment Oracle took over and decided to tank the products aimed at our segment, we waved our beloved Sun hardware goodbye. Larry has clearly delineated his marketing strategy: either you're a Fortune500, or you can fuck right off. Developmentally challenged doesn't mean there is no development taking place. It means the largest development effort is working closed-source, and not available for free (except some purposes), so some consumers are going to follow their path, I would contest that point. Besides encryption (which I think was already well underway by the time Oracle took over), AFAIK nothing much improved in Oracle ZFS. Oracle only considers Sun a vehicle to sell its software products on (DB, ERP, CRM, etc.). Anything that doesn't fit into that strategy (e.g. Thumper) got butchered and thrown to the side. while others are going to follow the open source branch illumos path, which means both disunity amongst developers and disunity amongst consumers, and incompatibility amongst products. I can't talk about disunity among devs (how would that manifest itself?), but as far as incompatibility among products, I've yet to come across it. In fact, thanks to ZFS feature flags, different feature sets can coexist peacefully and give admins unprecedented control over their storage pools. Version control in ZFS used to be a take it or leave it approach, now you can selectively enable and use only features you want to. So far, in the illumos branch, I've only seen bugfixes introduced since zpool 28, no significant introduction of new features. I've had #3035 LZ4 compression for ZFS and GRUB integrated just a few days back and I've got #3137 L2ARC compression up for review as we speak. Waiting for #3137 to integrate, I'm looking to focus on multi-MB record sizes next, and then perhaps taking a long hard look at reducing the in-memory DDT footprint. (Unlike the oracle branch, which is just as easy to sell as ontap). Again, what significant features did they add besides encryption? I'm not saying they didn't, I'm just not aware of that many. Which presents a challenge. Hence the term, challenged. Agreed, it is a challenge and needs to be taken seriously. We are up against a lot of money and man-hours invested by big-name companies, so I fully agree there. We need to rally ourselves as a community hold together tightly. Right now, ZFS is the leading product as far as I'm concerned. Better than MS VSS, better than Ontap, better than BTRFS. It is my personal opinion that one day BTRFS will eclipse ZFS due to oracle's unsupportive strategy causing disparity and lowering consumer demand for zfs, but of course, that's just a personal opinion prediction for the future, which has yet to be seen. So far, every time I evaluate BTRFS, it fails spectacularly, but the last time I did, was about a year ago. I'm due for a BTRFS re-evaluation now. Let us know at z...@lists.illumos.org how that goes, perhaps write a blog post about your observations. I'm sure the BTRFS folks came up with some neat ideas which we might learn from. Cheers, -- Saso ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Odd snapshots exposed in Solaris 11.1
Since upgrading to Solaris 11.1, I've started seeing snapshots like tank/vbox/shares%VMs appearing with zfs list -t snapshot. I thought snapshots with a % in their name where private objects created during a send/receive operation. These snapshots don't have many properties: zfs get all tank/vbox/shares%VMs NAME PROPERTYVALUE SOURCE tank/vbox/shares%VMs creationTue Jan 15 9:15 2013 - tank/vbox/shares%VMs mountpoint /vbox/shares - tank/vbox/shares%VMs share.* ...local tank/vbox/shares%VMs zoned offdefault Which is casing one of my scripts grief. Does anyone know why these are showing up? -- Ian. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] RFE: Un-dedup for unique blocks
From: Sašo Kiselkov [mailto:skiselkov...@gmail.com] as far as incompatibility among products, I've yet to come across it I was talking about ... install solaris 11, and it's using a new version of zfs that's incompatible with anything else out there. And vice-versa. (Not sure if feature flags is the default, or zpool 28 is the default, in various illumos-based distributions. But my understanding is that once you upgrade to feature flags, you can't go back to 28. Which means, mutually, anything 28 is incompatible with each other.) You have to typically make a conscious decision and plan ahead, and intentionally go to zpool 28 and no higher, if you want compatibility between systems. Let us know at z...@lists.illumos.org how that goes, perhaps write a blog post about your observations. I'm sure the BTRFS folks came up with some neat ideas which we might learn from. Actually - I've written about it before (but it'll be difficult to find, and nothing earth shattering, so not worth the search.) I don't think there's anything that zfs developers don't already know. Basic stuff like fsck, and ability to shrink and remove devices, those are the things btrfs has and zfs doesn't. (But there's lots more stuff that zfs has and btrfs doesn't. Just making sure my previous comment isn't seen as a criticism of zfs, or a judgement in favor of btrfs.) And even with a new evaluation, the conclusion can't be completely clear, nor immediate. Last evaluation started about 10 months ago, and we kept it in production for several weeks or a couple of months, because it appeared to be doing everything well. (Except for features that were known to be not-yet implemented, such as read-only snapshots (aka quotas) and btrfs-equivalent of zfs send.) Problem was, the system was unstable, crashing about once a week. No clues why. We tried all sorts of things in kernel, hardware, drivers, with and without support, to diagnose and capture the cause of the crashes. Then one day, I took a blind stab in the dark (for the ninetieth time) and I reformatted the storage volume ext4 instead of btrfs. After that, no more crashes. That was approx 8 months ago. I think the only thing I could learn upon a new evaluation is: #1 I hear btrfs send is implemented now. I'd like to see it with my own eyes before I believe it. #2 I hear quotas (read-only snapshots) are implemented now. Again, I'd like to see it before I believe it. #3 Proven stability. Never seen it yet with btrfs. Want to see it with my eyes and stand the test of time before it earns my trust. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] RFE: Un-dedup for unique blocks
On 01/22/2013 03:56 AM, Edward Ned Harvey (opensolarisisdeadlongliveopensolaris) wrote: From: Sašo Kiselkov [mailto:skiselkov...@gmail.com] as far as incompatibility among products, I've yet to come across it I was talking about ... install solaris 11, and it's using a new version of zfs that's incompatible with anything else out there. And vice-versa. Wait, you're complaining about a closed-source vendor who did a conscious effort to fuck the rest of the community over? I think you're crying on the wrong shoulder - it wasn't the open ZFS community that pulled this dick move. Yes, you can argue that the customer isn't interested in politics, but unfortunately, there are some things that we simply can't do anything about - the ball is in Oracle's court on this one. (Not sure if feature flags is the default, or zpool 28 is the default, in various illumos-based distributions. But my understanding is that once you upgrade to feature flags, you can't go back to 28. Which means, mutually, anything 28 is incompatible with each other.) You have to typically make a conscious decision and plan ahead, and intentionally go to zpool 28 and no higher, if you want compatibility between systems. Yes, feature flags is the default, simply because it is a way for open ZFS vendors to interoperate. Oracle is an important player in ZFS for sure, but we can't let their unwillingness to cooperate with others hold the whole community in stasis - that is actually what they would have wanted. Let us know at z...@lists.illumos.org how that goes, perhaps write a blog post about your observations. I'm sure the BTRFS folks came up with some neat ideas which we might learn from. Actually - I've written about it before (but it'll be difficult to find, and nothing earth shattering, so not worth the search.) I don't think there's anything that zfs developers don't already know. Basic stuff like fsck, and ability to shrink and remove devices, those are the things btrfs has and zfs doesn't. (But there's lots more stuff that zfs has and btrfs doesn't. Just making sure my previous comment isn't seen as a criticism of zfs, or a judgement in favor of btrfs.) Well, I learned of the LZ4 compression algorithm in a benchmark comparison of ZFS, BTRFS and other filesystem compression. Seeing that there were better things out there I decided to try and push the state of ZFS compression ahead a little. And even with a new evaluation, the conclusion can't be completely clear, nor immediate. Last evaluation started about 10 months ago, and we kept it in production for several weeks or a couple of months, because it appeared to be doing everything well. (Except for features that were known to be not-yet implemented, such as read-only snapshots (aka quotas) and btrfs-equivalent of zfs send.) Problem was, the system was unstable, crashing about once a week. No clues why. We tried all sorts of things in kernel, hardware, drivers, with and without support, to diagnose and capture the cause of the crashes. Then one day, I took a blind stab in the dark (for the ninetieth time) and I reformatted the storage volume ext4 instead of btrfs. After that, no more crashes. That was approx 8 months ago. Even negative results are results. I'm sure the BTRFS devs would be interested in your crash dumps. Not saying that you are in any way obligated to provide them - just pointing out that perhaps you were hitting some snag that could have been resolved (or not). I think the only thing I could learn upon a new evaluation is: #1 I hear btrfs send is implemented now. I'd like to see it with my own eyes before I believe it. #2 I hear quotas (read-only snapshots) are implemented now. Again, I'd like to see it before I believe it. #3 Proven stability. Never seen it yet with btrfs. Want to see it with my eyes and stand the test of time before it earns my trust. Do not underestimate these guys. They could have come up with a cool new feature that we haven't heard about anything at all. One of the things knocking around in my head ever since it was mentioned a while back on these mailing lists was a metadata-caching device, i.e. a small yet super-fast small device that would allow you to just store the pool topology for very fast scrub/resilver. These are the sort of things that I meant - they could have thought about filesystems in ways that haven't been done widely before. While BTRFS may be developmentally behind ZFS, one still has to have great respect for the intellect of its developers - these guys are not dumb. Cheers, -- Saso ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
