Hello Richard,
Tuesday, December 5, 2006, 7:01:17 AM, you wrote:
RE Dale Ghent wrote:
Similar to UFS's onerror mount option, I take it?
RE Actually, it would be interesting to see how many customers change the
RE onerror setting. We have some data, just need more days in the hour.
Sometimes
Robert Milkowski wrote:
Hello Richard,
Tuesday, December 5, 2006, 7:01:17 AM, you wrote:
RE Dale Ghent wrote:
Similar to UFS's onerror mount option, I take it?
RE Actually, it would be interesting to see how many customers change the
RE onerror setting. We have some data, just need more
Last Friday, one of our V880s kernel panicked with the following
message.This is a SAN connected ZFS pool attached to one LUN. From
this, it appears that the SAN 'disappeared' and then there was a panic
shortly after.
Am I reading this correctly?
Is this normal behavior for ZFS?
This is a
Douglas Denny wrote:
Last Friday, one of our V880s kernel panicked with the following
message.This is a SAN connected ZFS pool attached to one LUN. From
this, it appears that the SAN 'disappeared' and then there was a panic
shortly after.
Am I reading this correctly?
Yes.
Is this
On 12/4/06, James C. McPherson [EMAIL PROTECTED] wrote:
Is this normal behavior for ZFS?
Yes. You have no redundancy (from ZFS' point of view at least),
so ZFS has no option except panicing in order to maintain the
integrity of your data.
This is interesting from a implementation point of
Douglas Denny wrote:
On 12/4/06, James C. McPherson [EMAIL PROTECTED] wrote:
Is this normal behavior for ZFS?
Yes. You have no redundancy (from ZFS' point of view at least),
so ZFS has no option except panicing in order to maintain the
integrity of your data.
This is interesting from a
Hi all,
Having experienced this, it would be nice if there was an option to
offline the filesystem instead of kernel panicking on a per-zpool
basis. If its a system-critical partition like a database I'd prefer
it to kernel-panick and thereby trigger a fail-over of the
application. However, if
Jason J. W. Williams wrote:
Hi all,
Having experienced this, it would be nice if there was an option to
offline the filesystem instead of kernel panicking on a per-zpool
basis. If its a system-critical partition like a database I'd prefer
it to kernel-panick and thereby trigger a fail-over of
Any chance we might get a short refresher warning when creating a
striped zpool? O:-)
Best Regards,
Jason
On 12/4/06, Matthew Ahrens [EMAIL PROTECTED] wrote:
Jason J. W. Williams wrote:
Hi all,
Having experienced this, it would be nice if there was an option to
offline the filesystem
Matthew Ahrens wrote:
Jason J. W. Williams wrote:
Hi all,
Having experienced this, it would be nice if there was an option to
offline the filesystem instead of kernel panicking on a per-zpool
basis. If its a system-critical partition like a database I'd prefer
it to kernel-panick and thereby
Dale Ghent wrote:
Matthew Ahrens wrote:
Jason J. W. Williams wrote:
Hi all,
Having experienced this, it would be nice if there was an option to
offline the filesystem instead of kernel panicking on a per-zpool
basis. If its a system-critical partition like a database I'd prefer
it to
Richard Elling wrote:
Actually, it would be interesting to see how many customers change the
onerror setting. We have some data, just need more days in the hour.
I'm pretty sure you'd find that info in over 6 years of submitted
Explorer output :)
I imagine that stuff is sandboxed away in
12 matches
Mail list logo
