Hi all, Now that the Fishworks 2010.Q1 release seems to get deduplication, does anyone know if bugid: 6924824 (destroying a dedup-enabled dataset bricks system) is still valid, it has not been fixed in in onnv and it is not mentioned in the release notes. This is one of the bugs i''ve been keeping my eyes on before using dedup for any serious work, so I was a but surprised to see that it was in the 2010Q1 release but not fixed in ON. It might not be an issue, just curious, both from a fishworks perspective and from a OpenSolaris perspective. Regards Henrik http://sparcv9.blogspot.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100304/ed22e5bb/attachment.html>
On Thu, Mar 4, 2010 at 8:08 AM, Henrik Johansson <henrikj at henkis.net> wrote:> Hi all, > Now that the Fishworks 2010.Q1 release seems to get deduplication, does > anyone know if bugid: 6924824 (destroying a dedup-enabled dataset bricks > system) is still valid, it has not been fixed in in onnv and it is not > mentioned in the release notes. > This is one of the bugs i''ve been keeping my eyes on before using dedup for > any serious work, so I was a but surprised to see that it was in the 2010Q1 > release but not fixed in ON. It might not be an issue, just curious, both > from a fishworks perspective and from a OpenSolaris perspective. > Regards > Henrik > http://sparcv9.blogspot.com > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > >My rep says "Use dedupe at your own risk at this time". Guess they''ve been seeing a lot of issues, and regardless if its ''supported'' or not, he said not to use it. -- Brent Jones brent at servuhome.net
On 3/4/10 9:17 AM, Brent Jones wrote:> On Thu, Mar 4, 2010 at 8:08 AM, Henrik Johansson<henrikj at henkis.net> wrote: >> Hi all, >> Now that the Fishworks 2010.Q1 release seems to get deduplication, does >> anyone know if bugid: 6924824 (destroying a dedup-enabled dataset bricks >> system) is still valid, it has not been fixed in in onnv and it is not >> mentioned in the release notes. >> This is one of the bugs i''ve been keeping my eyes on before using dedup for >> any serious work, so I was a but surprised to see that it was in the 2010Q1 >> release but not fixed in ON. It might not be an issue, just curious, both >> from a fishworks perspective and from a OpenSolaris perspective. >> Regards >> Henrik >> http://sparcv9.blogspot.com >> >> _______________________________________________ >> zfs-discuss mailing list >> zfs-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >> >> > > My rep says "Use dedupe at your own risk at this time". > > Guess they''ve been seeing a lot of issues, and regardless if its > ''supported'' or not, he said not to use it.So its not a feature, its a bug. They should release some official statement if they are going to have the sales reps saying that. Either it works or it doesn''t and if it doesn''t, then all parts of Oracle should be saying the same thing, not just after they have your money (oh btw, that dedup thing...). As discussed in a couple other threads, if Oracle wants to treat the fishworks boxes like closed appliances, then it should "just work" and if it doesn''t then it should be treated like a toaster that doesn''t work and they should take it back. They seem to want to sell them with the benefits of being closed for them - you shouldn''t use the command line, etc but then act like your unique workload/environment is somehow causing them to break when they break. If they seal the box and put 5 knobs on the outside, don''t blame the customer when they turn all the knobs to 10 and the box doesn''t work. Take the box back, remove the knobs or fix the guts so all the knobs work as advertised.
On Thu, Mar 4, 2010 at 4:40 PM, zfs ml <zfsml at itsbeen.sent.com> wrote:> On 3/4/10 9:17 AM, Brent Jones wrote: > >> My rep says "Use dedupe at your own risk at this time". >> >> Guess they''ve been seeing a lot of issues, and regardless if its >> ''supported'' or not, he said not to use it. >> > > So its not a feature, its a bug. They should release some official > statement if they are going to have the sales reps saying that. Either it > works or it doesn''t and if it doesn''t, then all parts of Oracle should be > saying the same thing, not just after they have your money (oh btw, that > dedup thing...). > > As discussed in a couple other threads, if Oracle wants to treat the > fishworks boxes like closed appliances, then it should "just work" and if it > doesn''t then it should be treated like a toaster that doesn''t work and they > should take it back. They seem to want to sell them with the benefits of > being closed for them - you shouldn''t use the command line, etc but then act > like your unique workload/environment is somehow causing them to break when > they break. If they seal the box and put 5 knobs on the outside, don''t blame > the customer when they turn all the knobs to 10 and the box doesn''t work. > Take the box back, remove the knobs or fix the guts so all the knobs work as > advertised.It seems they kind of rushed the appliance into the market. We''ve a few 7410s and replication (with zfs send/receive) doesn''t work after shares reach ~1TB (broken pipe error). It''s frustrating and we can''t do anything because every time we type "shell" in the CLI, it freaks us out with a message saying the warranty will be voided if we continue. I bet that we could work around that bug but we''re not allowed and the workarounds provided by Sun haven''t worked. Regarding dedup, Oracle is very courageous for including it in the 2010.Q1 release if this comes to be true. But I understand the pressure on then. Every other vendor out there is releasing products with deduplication. Personally, I would just wait 2-3 releases before using it in a black box like the 7000s. The hardware on the other hand is incredible in terms of resilience and performance, no doubt. Which makes me think the pretty interface becomes an annoyance sometimes. Let''s wait for 2010.Q1 :) -- Giovanni Tirloni sysdroid.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100304/c8f6773b/attachment.html>
> It seems they kind of rushed the appliance into the market. We''ve a few 7410s and replication (with zfs send/receive) doesn''t work after shares reach ~1TB (broken pipe error).While it''s the case that the 7000 series is a relatively new product, the characterization of "rushed to market" is inaccurate. While the product certainly has had bugs, we''ve been pretty quick to address them (for example, the issue you described).> It''s frustrating and we can''t do anything because every time we type "shell" in the CLI, it freaks us out with a message saying the warranty will be voided if we continue. I bet that we could work around that bug but we''re not allowed and the workarounds provided by Sun haven''t worked.I can understand why it might be frustrating to feel shut out of your customary Solaris interfaces, but it''s not Solaris: it''s an appliance. Arbitrary actions that might seem benign to someone familiar with Solaris can have disastrous consequences -- I''d be happy to give some examples of the amusing ways our customers have taken careful aim and shot themselves in the foot.> Regarding dedup, Oracle is very courageous for including it in the 2010.Q1 release if this comes to be true. But I understand the pressure on then. Every other vendor out there is releasing products with deduplication. Personally, I would just wait 2-3 releases before using it in a black box like the 7000s.We''re including dedup in the 2010.Q1 release, and as always we would not release a product we didn''t stand behind. ZFS dedup still has some performance pathologies and surprising results at times; we''re working our customers to ensure that their deployments are successful, and fixing problems as they come up.> The hardware on the other hand is incredible in terms of resilience and performance, no doubt. Which makes me think the pretty interface becomes an annoyance sometimes. Let''s wait for 2010.Q1 :)As always, we welcome feedback (although zfs-discuss is not the appropriate forum), and are eager to improve the product. Adam -- Adam Leventhal, Fishworks http://blogs.sun.com/ahl
Hi, I have tried what dedup does on a test dataset that I have filled with 372 GB of partly redundant data. I have used snv_133. All in all, it was successful. The net data volume was only 120 GB. Destruction of the dataset finally took a while, but without any compromise of anything else. After this successful test I am planning to use dedup productively soon. Regards, Tonmaus -- This message posted from opensolaris.org
On Fri, Mar 5, 2010 at 10:49 AM, Tonmaus <sequoiamobil at gmx.net> wrote:> Hi, > > I have tried what dedup does on a test dataset that I have filled with 372 GB of partly redundant data. I have used snv_133. All in all, it was successful. The net data volume was only 120 GB. Destruction of the dataset finally took a while, but without any compromise of anything else. > > After this successful test I am planning to use dedup productively soon. > > Regards, > > Tonmaus > -- > This message posted from opensolaris.org > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >120GB isn''t a large enough test. Do what you will, but there have now been at least a dozen reports of people locking up their 7000 series, and X4500/X4540''s by enabling de-dupe on large datasets. Myself included. Check CR 6924390 for updates (if any) -- Brent Jones brent at servuhome.net
Hi, so, what would be a critical test size in your opinion? Are there any other side conditions? I.e., I am not using any snapshots and have also turned off automatic snapshots because I was bitten by system hangs while destroying datasets with living snapshots. I am also aware that Fishworks isn''t probably on the same code level as the current dev build. Tonmaus -- This message posted from opensolaris.org
On Fri, Mar 5, 2010 at 4:48 PM, Tonmaus <sequoiamobil at gmx.net> wrote:> Hi, > > so, what would be a critical test size in your opinion? Are there any other > side conditions? > >when your dedup hash table ( a table that holds a checksum of every block seen on filesystems/zvols after dedup was enabled) exceeds memory, your performance degrades exponentially probably before that. James Dickens http://uadmin.blogspot.com> I.e., I am not using any snapshots and have also turned off automatic > snapshots because I was bitten by system hangs while destroying datasets > with living snapshots. > I am also aware that Fishworks isn''t probably on the same code level as the > current dev build. > > Tonmaus > -- > This message posted from opensolaris.org > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100305/9148d413/attachment.html>
On Mar 5, 2010, at 5:10 PM, James Dickens wrote:> On Fri, Mar 5, 2010 at 4:48 PM, Tonmaus <sequoiamobil at gmx.net> wrote: > Hi, > > so, what would be a critical test size in your opinion? Are there any other side conditions? > > > when your dedup hash table ( a table that holds a checksum of every block seen on filesystems/zvols after dedup was enabled) exceeds memory, your performance degrades exponentially probably before that.More important is the small, random I/O performance of your pool. For fast devices, like 15krpm disks, SSDs, or array controllers with nonvolatile caches, performance should be good. For big, slow JBOD drives, the small, random I/O performance is poor and you pay for that cost savings with time spent waiting. -- richard ZFS storage and performance consulting at http://www.RichardElling.com ZFS training on deduplication, NexentaStor, and NAS performance http://nexenta-atlanta.eventbrite.com (March 16-18, 2010)
>>>>> "al" == Adam Leventhal <ahl at eng.sun.com> writes:al> As always, we welcome feedback (although zfs-discuss is not al> the appropriate forum), ``Please, you criticize our work in private while we compliment it in public.'''' -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 304 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100308/adb4a319/attachment.bin>
On Mon, Mar 8, 2010 at 2:10 PM, Miles Nordin <carton at ivy.net> wrote:> >>>>> "al" == Adam Leventhal <ahl at eng.sun.com> writes: > > al> As always, we welcome feedback (although zfs-discuss is not > al> the appropriate forum), > > ``Please, you criticize our work in private while we compliment it in > public.'''' >I''m betting its more the fact that zfs-discuss is not fishworks-support. Nobody is stopping you from making a blog talking about how badly you think fishworks sucks, or how awesome you think it is. I don''t see Adam and co. posting to this list announcing new features or code releases for the fishworks project. If they have on a regular basis and I''ve just been missing it, feel free to link to the threads. I''m fairly certain his response is that if you want to discuss fishworks, you should go about the proper channels, not that he''s somehow trying to cover up a glaring issue with the product. --Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100308/31d82a9b/attachment.html>
>>>>> "tc" == Tim Cook <tim at cook.ms> writes:tc> I''m betting its more the fact that zfs-discuss is not Firstly, there''s no need for you to respond on anyone''s behalf, especially not by ``betting.'''' Secondly, fishworks does run ZFS, and I for one am interested in what works and what doesn''t. tc> I don''t see Adam and co. posting to this list announcing new tc> features or code releases I don''t recall whether he does or not, but I do recall reading about fishworks here and not regarding it OT. tc> Nobody is stopping you from making a blog talking about Yup, and if this forum''s not a neutral one, I''ll not be the only one who stops wasting his time on it and goes looking for another. But, so far, notwithstanding your efforts, it is neutral, and there''s no need for me to do that. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 304 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100308/6c79eae3/attachment.bin>
On Mon, Mar 8, 2010 at 5:47 PM, Miles Nordin <carton at ivy.net> wrote:> >>>>> "tc" == Tim Cook <tim at cook.ms> writes: > > tc> I''m betting its more the fact that zfs-discuss is not > > Firstly, there''s no need for you to respond on anyone''s behalf, > especially not by ``betting.'''' > >I''m not betting, I know. It''s called being polite and leaving the door open for him to speak his own mind if he so chooses.> Secondly, fishworks does run ZFS, and I for one am interested in what > works and what doesn''t. >So does nexenta. So does green-bytes. So does milax. So does belenix. So does freebsd. Fortunately this isn''t nexenta-enterprise-support, or green-bytes-enterprise-support, this is zfs-discuss. We''re here to talk about zfs as it''s implemented in opensolaris. NOT fishworks or any other one-off.> > tc> I don''t see Adam and co. posting to this list announcing new > tc> features or code releases > > I don''t recall whether he does or not, but I do recall reading about > fishworks here and not regarding it OT. > >Mentioning fishworks in passing is a far cry from turning this into a forum to discuss the implementations of solaris components in a closed appliance.> tc> Nobody is stopping you from making a blog talking about > > Yup, and if this forum''s not a neutral one, I''ll not be the only one > who stops wasting his time on it and goes looking for another. But, > so far, notwithstanding your efforts, it is neutral, and there''s no > need for me to do that. > >This forum being neutral has absolutely nothing to do with the specifics of Oracle''s closed appliances. People keeping the discussion on-topic by telling you/whoever this isn''t the proper place to discuss those closed appliances also has nothing to do with this forum being neutral. If you want to debate the pro''s and con''s of fishworks, you''re free to do so, but this isn''t the proper place to do it. Start your own forum. Start a blog. Call up your local sales rep and ask to speak to an engineer. You''ve got all sorts of avenues to have the discussion, but this isn''t one of them. --Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100308/bbf32b30/attachment.html>