You should contact the storage community and hopefully get a hold of the
responsible engineer. This is a firewire bug, not a ZFS bug.
- Eric
On Sat, May 31, 2008 at 03:56:52PM -0700, Matt Cowger wrote:
> Anyone willing to provide the modified kernel binaries for opensolaris2008.05?
>
>
> Thi
Anyone willing to provide the modified kernel binaries for opensolaris2008.05?
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
On Sat, 31 May 2008, Matt Cowger wrote:
> Sure. Here's the thread discussing the overall issue:
>
> http://www.opensolaris.org/jive/thread.jspa?threadID=36365&tstart=0
I found that via Google as well as this bug entry
http://bugs.opensolaris.org/view_bug.do?bug_id=6560174
This is really unfort
On Sat, 31 May 2008, Matt Cowger wrote:
> I can't believe its almost a year later, with a patch provided, and
> this bug is still not fixed.
>
> For those of us that cant recompile the sources, it makes solaris
> useless if we want to use a firewire drive.
Can you provide the history behind thi
I can't believe its almost a year later, with a patch provided, and this bug is
still not fixed.
For those of us that cant recompile the sources, it makes solaris useless if we
want to use a firewire drive.
--m
This message posted from opensolaris.org
___
Regarding the patches for this bug (6445725) I applied them to a nightly build
of snv 77, where they now appear to reside in usr/src/uts/intel/sbp2/debug64
rather than obj64 after successful build. I then copied them over the kernels
in the community release of b77.
usr/src/uts/intel/scsa1394/
This bug is still not integrated? To upgrade to a community release I still
have to patch and compile the kernel? How can this bug fix be integrated with
the code?
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@ope
Thank you very much for this input. I eventually upgraded to snv_69 and did the
ON build of 69 with your patch. I copied to patched kernels over and have now
re-imported the defunct pool. The pool is working after a quick 'resilvering'.
Thanks very much!
This message posted from opensolaris.
> By coincidence, I spent some time dtracing 6560174 yesterday afternoon on
> b62, and these bugs are indeed duplicates. I never noticed 6445725 because my
> system wasn't hanging but as the notes say, the fix for 6434435 changes the
> problem, and instead the error that gets propogated back fro
Jürgen Keil wrote:
>>> And 6560174 might be a duplicate of 6445725
>> I see what you mean. Unfortunately there does not
>> look to be a work-around.
>
> Nope, no work-around. This is a scsa1394 bug; it
> has some issues when it is used from interrupt context.
>
> I have some source code diffs,
> > 3) Can your code diffs be integrated into the OS on my end to use this
> > drive, and if so, how?
>
> I believe the bug is still being worked on, right Jürgen ?
The opensolaris sponsor process for fixing bug 6445725 seems
to got stuck. I ping'ed Alan P. on the state of that bug...
This
> > Nope, no work-around.
>
> OK. Then I have 3 questions:
>
> 1) How do I destroy the pool that was on the firewire
> drive? (So that zfs stops complaining about it)
Even if the drive is disconnected, it should be possible
to "zpool export" it, so that the OS forgets about it
and doesn't try
aric wrote:
>> Nope, no work-around.
>
> OK. Then I have 3 questions:
>
> 1) How do I destroy the pool that was on the firewire drive? (So that zfs
> stops complaining about it)
`zpool destroy ` this works even if the drive isn't connected.
> 2) How can I reformat the firewire drive? Does t
> Nope, no work-around.
OK. Then I have 3 questions:
1) How do I destroy the pool that was on the firewire drive? (So that zfs stops
complaining about it)
2) How can I reformat the firewire drive? Does this need to be done on a
non-Solaris OS?
3) Can your code diffs be integrated into the O
> > And 6560174 might be a duplicate of 6445725
>
> I see what you mean. Unfortunately there does not
> look to be a work-around.
Nope, no work-around. This is a scsa1394 bug; it
has some issues when it is used from interrupt context.
I have some source code diffs, that are supposed to
fix the
> And 6560174 might be a duplicate of 6445725
I see what you mean. Unfortunately there does not look to be a work-around.
It is beginning to sound like firewire drives are not a safe alternative for
backup? This is unfortunate when you have an Ultra20 with only 2 disks.
Is there a way to dest
> I think I have ran into this bug, 6560174, with a firewire drive.
And 6560174 might be a duplicate of 6445725
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/lis
I think I have ran into this bug, 6560174, with a firewire drive. Running build
64a, formatted entire external firewire drive as a zpool. Worked fine with
smaller zfs send operations. Tried zfs send on a 10GB filesystem and it seemed
to hang (though there is no notice of progress with zfs send).
18 matches
Mail list logo
