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 als
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 wor
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
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
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, so
> "th" == Tim Haley 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
here the
Miles Nordin wrote:
"bmm" == Bogdan M Maryniuk 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 yet.
> "bmm" == Bogdan M Maryniuk 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 yet.
In my notes: 6
> "ic" == Ian Collins 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
Description: PGP sign
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
On 18-Jun-09, at 12:14 PM, Miles Nordin wrote:
"bmm" == Bogdan M Maryniuk writes:
"tt" == Toby Thain writes:
...
tt> /. is no person...
... you and I both know it's plausible
speculation that Apple delayed unleashing ZFS on their consumers
because of the lost pool problems. ZFS doesn
> "bmm" == Bogdan M Maryniuk writes:
> "tt" == Toby Thain 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 speak and share information, and ye
Den 18 juni 2009 09.42 skrev Bogdan M. Maryniuk:
>> 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 (even though the pool is f
2009/6/18 Timh Bergström :
> 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 ./
Nobody flaming peop
Den 18 juni 2009 06.47 skrev Timh Bergström:
> 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 hos
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 get
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
On Thu, Jun 18, 2009 at 6:42 AM, Miles Nordin 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 point, but I d
On 17-Jun-09, at 5:42 PM, Miles Nordin wrote:
"bmm" == Bogdan M Maryniuk writes:
"tt" == Toby Thain writes:
"ok" == Orvar Korvar writes:
tt> Slashdot was never the place to go for accurate information
tt> about ZFS.
again, the posts in the slashdot thread complaining about corrupt
> "bmm" == Bogdan M Maryniuk writes:
> "tt" == Toby Thain writes:
> "ok" == Orvar Korvar 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 real
bmm> systems. All ZFS.
It sounds like what y
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 pl
On Wed, Jun 17, 2009 at 8:37 PM, Orvar Korvar 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.
--
Kind regards, BM
Things
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
zfs-discuss@opensol
On Wed, Jun 17, 2009 at 6:58 AM, Miles Nordin 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 failures so far.
On Wed, Jun 17, 2009 at 6:58 AM, Miles Nordin 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 wrong: no ad h
> "bmm" == Bogdan M Maryniuk 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 filesystems on my FC
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.
Takin
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
__
On Tue, Jun 16, 2009 at 2:45 AM, Orvar Korvar 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 n
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 t
On Mon, Jun 15, 2009 at 12:57 PM, Joerg Schilling <
joerg.schill...@fokus.fraunhofer.de> wrote:
> Orvar Korvar 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 opinio
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 t
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
_
Orvar Korvar 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 functionality. The functional
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 an
35 matches
Mail list logo
