On Sun, Jul 12, 2015 at 06:18:17PM -0700, Richard Elling wrote:
Some additional block pointer verification code was added in changeset
f63ab3d5a84a12b474655fc7e700db3efba6c4c9 and likely is the cause
of this assertion. In general, assertion failures are almost always software
problems -- the
First action:
If you can mount the pool read-only, update your backup
Then
I would expect that a single bad disk is the reason of the problem on a
write command. I would first check the system and fault log or
smartvalues for hints about a bad disk. If there is a suspicious disk,
remove that
On Jul 12, 2015, at 5:26 PM, Derek Yarnell de...@umiacs.umd.edu wrote:
On 7/12/15 3:21 PM, Günther Alka wrote:
First action:
If you can mount the pool read-only, update your backup
We are securing all the non-scratch data currently before messing with
the pool any more. We had backups
On 7/12/15 3:21 PM, Günther Alka wrote:
First action:
If you can mount the pool read-only, update your backup
We are securing all the non-scratch data currently before messing with
the pool any more. We had backups as recent as the night before but it
is still going to be faster to pull the
Mucho snippage deleted!
I also saw you mention this indirectly on twitter.
Generally, the OmniOS release should mention which release. 170cea2 is
r151014. It's good to mention that alongside the uname as that's how most of
us lock in on a release.
Is there anything we can fix to help these
On Jul 12, 2015, at 9:18 PM, Richard Elling
richard.ell...@richardelling.com wrote:
Dan, if you're listening, Matt would be the best person to weigh-in on this.
Yes he would be, Richard..
The panic in the arc_get_data_buf() paths is similar to older problems we'd
seen in r151006.
Derek,
System ld.cache was modified to add the GCC lib directory in search
path with crle(1)
This resolved the previous breakage with the gettext installed from
the OmniOS IPS repo and allowed us to progress. Unfortunately, it
looks like there was a permission issue with /var/tmp on the zone I
was using
On Sat, 11 Jul 2015, Derek Yarnell wrote:
Hi,
We just have had a catastrophic event on one of our OmniOS r14 file
servers. In what seems to have been triggered by the weekly scrub of
its one large zfs pool (~100T) it panics. This made it basically reboot
continually and we have installed a
The on-going scrub automatically restarts, apparently even in read-only
mode. You should 'zpool scrub -s poolname' ASAP after boot (if you can)
to stop the ongoing scrub.
We have tried to stop the scrub but it seems you can not cancel a scrub
when the pool is mounted readonly.
--
Derek T.