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
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 this?
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=36365tstart=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
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
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?
This
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.
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
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
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 from
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, that are
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 to mount
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 poolname` this works even if the drive isn't connected.
2) How can I reformat the firewire drive? Does
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
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
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
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
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
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
18 matches
Mail list logo
