On 4/6/2014 7:50 AM, Harry Putnam wrote:
"[email protected]" <[email protected]> writes:
On 4/5/2014 9:25 AM, Harry Putnam wrote:
"[email protected]" <[email protected]> writes:
[...]
Can anyone else report having seen something like this?
Can the fact of my setting all four of my current pools to be
mountpointed under /p have any bearing here?
You can try doing this to see if it is able to correct the
problem:
http://docs.oracle.com/cd/E19253-01/819-5461/gbbwl/index.html
Looking at the examples shown there as types of errors one might get
using `zpool status', I notice NONE of the examples show the
corruption being listed as a directory. All examples show actual end
of the line filenames, accept those where the error says the pool is
FAULTED.
Have you ever seen a 'zpool status' output that showed only directory
names as the corrupted 'files'?
Is that unusual?
I have no experience on which to draw.
My opinion is this problem most likely occur because it was
lacking redundancy.
and scrub was not often run.
Can you specify what you actually mean by 'lacking redundancy'.
And for the record, one of the pools showing the posted output was
only 2 days old, so no... there had not been major scrubbing.....
Even the oldest one showing problems was less than a week old.
A fast summary, ZFS redundacy; basically is when bad data is
found by zfs it fetches a clean copy of the data from another
disk(mirrored) and repairs it with the correct data,etc.
If you have not already read this, I suggest reading "Oracle
Solaris Administration ZFS File system"
http://docs.oracle.com/cd/E23824_01/html/821-1448/gbscy.html#scrolltoc
I'm reading it myself and there are some things that are still
not clear:-)
In answer to your previous post; yes all seems ok now. I'm not sure
if you noticed that my setup is a vbox vm running on windows7 host.
I'm sorry, I did not noticed. You were fortunate it was
repaired; i have read cases
where some people were not as fortunate and had to destroy and
create again.
Looking back; I actually think that problem was caused by me
(ill-advisedly ) meddling with disks thru vbox.
I wanted to spred my discs onto an external usb3 multi tb disk.
My space on the windows main machine was getting tight.
I may have made some blunder figuring out to do it.
It can be done like this: Create disks in vbox on your oi vm. Thru
vbox, release then remove the disks (do not delete). Now move those
disks to the external drive.
Back in vbox; use the disc creation dialog but instead of creating new
discs choose to use existing discs. Track down your discs on ext drive
and select them.
When you next fire up your oi vm, those discs will appear with
'format' and can be used as usual.
One unexpected result is that vbox seems to create the same named
discs under the normal directory for your vm discs....but they never
grow beyond 4mb. All the while the same named discs out on the ext
drive may grow to whatever size was set when created.
So, end result is, you have disc-10 under your vm disc directory and
disc-10 out on the external.... the only one growing is on the
external. This all seems to work seamlessly with the oi OS.
Must be something like a place marker that vbox finds necessary to
create.
Gack... enough about vbox....I got carried away... sorry
------- --------- ---=--- --------- --------
No problem. I too use vbox for testing things out.
and i like reading on vbox.
Thanks for the input.
I've been going to that source documentation you cited sort of as
needed. Usually reading a bit more each time.... so slowly boning up a bit
Welcome...
_______________________________________________
OpenIndiana-discuss mailing list
[email protected]
http://openindiana.org/mailman/listinfo/openindiana-discuss
_______________________________________________
OpenIndiana-discuss mailing list
[email protected]
http://openindiana.org/mailman/listinfo/openindiana-discuss
