Nicolas Williams schrieb:
On Fri, Jun 19, 2009 at 04:09:29PM -0400, Miles Nordin wrote:
Also, as I said elsewhere, there's a barrier controlled by Sun to
getting bugs accepted. This is a useful barrier: the bug database is
a more useful drive toward improvement if it's not cluttered. It
Haudy Kazemi wrote:
I think a better question would be: what kind of tests would be most
promising for turning some subclass of these lost pools reported on
the mailing list into an actionable bug?
my first bet would be writing tools that test for ignored sync cache
commands leading to lost
Hi, Miles!
Hope, weather is fine at your place. :-)
On Sat, Jun 20, 2009 at 5:09 AM, Miles Nordin wrote:
I understood Bogdan's post was a trap: ``provide bug numbers. Oh,
they're fixed? nothing to see here then. no bugs? nothing to see
here then.''
Would be great if you do not put a words
ic == Ian Collins masuma@quicksilver.net.nz writes:
Access to the bug database is controlled.
ic No, the bug databse is open.
no, it isn't. Not all the bugs are visible, and after submitting a
bug it has to be approved. Neither is true of the mailing list.
pgpZrCTBzKBaa.pgp
bmm == Bogdan M Maryniuk bogdan.maryn...@gmail.com writes:
bmm OK, so what is the status of your bugreport about this?
That's a good question if it's meant genuinely, and not to be
obstructionist. It's hard to report one bug with clear information
because the problem isn't well-isolated
Miles Nordin wrote:
bmm == Bogdan M Maryniuk bogdan.maryn...@gmail.com writes:
bmm OK, so what is the status of your bugreport about this?
That's a good question if it's meant genuinely, and not to be
obstructionist. It's hard to report one bug with clear information
because the problem
th == Tim Haley tim.ha...@sun.com writes:
th The second is marked as a duplicate of 6784395, fixed in
th snv_107, 20 weeks ago.
Yeah nice sleuthing. :/
I understood Bogdan's post was a trap: ``provide bug numbers. Oh,
they're fixed? nothing to see here then. no bugs? nothing to see
On Fri, Jun 19, 2009 at 04:09:29PM -0400, Miles Nordin wrote:
Also, as I said elsewhere, there's a barrier controlled by Sun to
getting bugs accepted. This is a useful barrier: the bug database is
a more useful drive toward improvement if it's not cluttered. It also
means, like I said,
I think a better question would be: what kind of tests would be most
promising for turning some subclass of these lost pools reported on
the mailing list into an actionable bug?
my first bet would be writing tools that test for ignored sync cache
commands leading to lost writes, and apply them
2009/6/18 Timh Bergström timh.bergst...@diino.net:
USB-sticks has proven a bad idea with zfs mirrors
I think, USB sticks is bad idea for mirrors in general... :-)
ZFS on iSCSI *is* flaky
OK, so what is the status of your bugreport about this? Was ignored or
just rejected?..
Flaming people on
Den 18 juni 2009 09.42 skrev Bogdan M. Maryniukbogdan.maryn...@gmail.com:
ZFS on iSCSI *is* flaky
OK, so what is the status of your bugreport about this? Was ignored or
just rejected?..
No bug report because I don't think it's the file systems fault, and
why bother when disappearing vdevs
bmm == Bogdan M Maryniuk bogdan.maryn...@gmail.com writes:
tt == Toby Thain t...@telegraphics.com.au writes:
bmm That's why I think that speaking My $foo crashes therefore it
bmm is all crap is bad idea: either help to fix it or just don't
bmm use it,
First, people are allowed to
On 18-Jun-09, at 12:14 PM, Miles Nordin wrote:
bmm == Bogdan M Maryniuk bogdan.maryn...@gmail.com writes:
tt == Toby Thain t...@telegraphics.com.au writes:
...
tt /. is no person...
... you and I both know it's plausible
speculation that Apple delayed unleashing ZFS on their consumers
Toby,
On 17-Jun-09, at 7:37 AM, Orvar Korvar wrote:
Ok, so you mean the comments are mostly FUD and bull shit? Because
there are no bug reports from the whiners? Could this be the case? It
is mostly FUD? Hmmm...?
Having read the thread, I would say without a doubt.
Slashdot was never
Ok, so you mean the comments are mostly FUD and bull shit? Because there are no
bug reports from the whiners? Could this be the case? It is mostly FUD? Hmmm...?
--
This message posted from opensolaris.org
___
zfs-discuss mailing list
On Wed, Jun 17, 2009 at 8:37 PM, Orvar Korvarno-re...@opensolaris.org wrote:
Ok, so you mean the comments are mostly FUD and bull shit?
Unless there is real step-by-step reproducible proof, then yes, it is
completely useless waste of time and BS that I would not care at all,
if I were you.
--
On 17-Jun-09, at 7:37 AM, Orvar Korvar wrote:
Ok, so you mean the comments are mostly FUD and bull shit? Because
there are no bug reports from the whiners? Could this be the case?
It is mostly FUD? Hmmm...?
Having read the thread, I would say without a doubt.
Slashdot was never the
bmm == Bogdan M Maryniuk bogdan.maryn...@gmail.com writes:
tt == Toby Thain t...@telegraphics.com.au writes:
ok == Orvar Korvar no-re...@opensolaris.org writes:
bmm Personally I am running various open solaris versions on a
bmm VirtualBox as a crash dummy, as well as running osol on a
On 17-Jun-09, at 5:42 PM, Miles Nordin wrote:
bmm == Bogdan M Maryniuk bogdan.maryn...@gmail.com writes:
tt == Toby Thain t...@telegraphics.com.au writes:
ok == Orvar Korvar no-re...@opensolaris.org writes:
tt Slashdot was never the place to go for accurate information
tt about ZFS.
On Thu, Jun 18, 2009 at 6:42 AM, Miles Nordincar...@ivy.net wrote:
Surely you can understand there is such thing as a ``hard to reproduce
problem?'' Is the phrase so new to you? If you'd experience with
other filesystems in their corruption-prone infancy, it wouldn't be.
I understand your
On Thu 18/06/09 09:42 , Miles Nordin car...@ivy.net sent:
Access to the bug database is controlled.
No, the bug databse is open.
Ian.
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
The way I see it is that eventhough ZFS may be a wonderful filesystem,
it is not the best solution for every possible (odd) setup. I.e
USB-sticks has proven a bad idea with zfs mirrors, ergo - dont do
it(tm).
ZFS on iSCSI *is* flaky and a host-reboot without telling the target
will most likely
Den 18 juni 2009 06.47 skrev Timh Bergströmtimh.bergst...@diino.net:
The way I see it is that eventhough ZFS may be a wonderful filesystem,
it is not the best solution for every possible (odd) setup. I.e
USB-sticks has proven a bad idea with zfs mirrors, ergo - dont do
it(tm).
ZFS on iSCSI
I totally agree with you. I am just concerned about ZFS' reputation.
If there are complaints, what should SUN do? Should the complaints be taken
seriously or not? Me love ZFS, and I dont want it to loose it's credibility.
BTW, ZFS rocks. Hard.
--
This message posted from opensolaris.org
Hi,
If there are complaints, what should SUN do? Should the complaints be taken
seriously or not?
Customer complaints are ALWAYS taken serious by SUN, and more than that,
with those kind of statements Bugs could be traced, problems resolved
and so far filesystem -ZFS- could be improved.
bmm == Bogdan M Maryniuk bogdan.maryn...@gmail.com writes:
bmm but all the time when yet another slashdotter (read: teenager)
bmm screams
the comments about data loss were mostly quoting this list. And some
of the posters have said ``I'm losing a lot more ZFS pools than UFS
and VxFS
On Wed, Jun 17, 2009 at 6:58 AM, Miles Nordincar...@ivy.net wrote:
What have you done to try to reproduce the problem?
Well, if you had posted here steps that fails for you and I missed
this, then I am sorry, I would like to get this somewhere from archive
and try.
However, please don't get me
On Wed, Jun 17, 2009 at 6:58 AM, Miles Nordin car...@ivy.net wrote:
What have you done to try to reproduce the problem?
P.S. I've read that Slashdot article and all the comments and even
replied some. Plus, I've actually tried to reproduce few things that
they vaguely are able to describe. No
According to this webpage, there are some errors that makes ZFS unusable under
certain conditions. That is not really optimal for an Enterprise file system.
In my opinion the ZFS team should focus on bug correction instead of adding new
functionality. The functionality that exists far surpass
Orvar Korvar no-re...@opensolaris.org wrote:
According to this webpage, there are some errors that makes ZFS unusable
under certain conditions. That is not really optimal for an Enterprise file
system. In my opinion the ZFS team should focus on bug correction instead of
adding new
In the comments there are several people complaining of loosing data. That
doesnt sound to good. It takes a long time to build a good reputation, and 5
minutes to ruin it. We dont want ZFS to loose it's reputation of an uber file
system.
--
This message posted from opensolaris.org
On Mon, 15 Jun 2009, Orvar Korvar wrote:
In the comments there are several people complaining of loosing
data. That doesnt sound to good. It takes a long time to build a
good reputation, and 5 minutes to ruin it. We dont want ZFS to loose
it's reputation of an uber file system.
I recognize
On Mon, Jun 15, 2009 at 12:57 PM, Joerg Schilling
joerg.schill...@fokus.fraunhofer.de wrote:
Orvar Korvar no-re...@opensolaris.org wrote:
According to this webpage, there are some errors that makes ZFS unusable
under certain conditions. That is not really optimal for an Enterprise file
Orvar Korvar wrote:
In the comments there are several people complaining of loosing data. That
doesnt sound to good. It takes a long time to build a good reputation, and 5
minutes to ruin it. We dont want ZFS to loose it's reputation of an uber file
system.
With due respect, I recommend
On Tue, Jun 16, 2009 at 2:45 AM, Orvar Korvarno-re...@opensolaris.org wrote:
According to this webpage, there are some errors that makes ZFS unusable
under certain conditions.
That is not really optimal for an Enterprise file system. In my opinion the
ZFS team should focus
on bug correction
35 matches
Mail list logo
