134 msgstr "No automated response will be taken."
135 msgid "ZFS-8000-72.impact"
136 msgstr "The pool is no longer available"
137 msgid "ZFS-8000-72.action"
138 msgstr "\nEven though all the devices are available, the on-disk data\nhas been corrupted such that the pool cannot be opened. If a recovery\naction is presented, the pool can be returned to a usable state.\nOtherwise, all data within the pool is lost, and the pool must be\ndestroyed and restored from an appropriate backup source. ZFS\nincludes built-in metadata replication to prevent this from happening\neven for unreplicated pools, but running in a replicated configuration\nwill decrease the chances of this happening in the future.\n\nIf this error is encountered during 'zpool import', see the\nsection below. Otherwise, run 'zpool status -x' to determine which\npool is faulted and if a recovery option is available:\n\n\n# zpool status -x\n pool: test\n id: 13783646421373024673\n state: FAULTED\nstatus: The pool metadata is corrupted and cannot be opened.\naction: Recovery is possible, but will result in some data loss.\n Returning the pool to its state as of Mon Sep 28 10:24:39 2009\n should correct the problem. Approximately 59 seconds of data\n will have to be discarded, irreversibly. Recovery can be\n attempted by executing 'zpool clear -F test'. A scrub of the pool\n is strongly recommended following a successful recovery.\n see: http://illumos.org/msg/ZFS-8000-72\nconfig:\n\n NAME STATE READ WRITE CKSUM\n test FAULTED 0 0 2 corrupted data\n c0t0d0 ONLINE 0 0 2\n c0t0d1 ONLINE 0 0 2\n\n\nIf recovery is unavailable, the recommended action will be:\n\n\naction: Destroy the pool and restore from backup.\n\n\nIf this error is encountered during 'zpool import', and if no\nrecovery option is mentioned, the pool is unrecoverable and cannot be\nimported. The pool must be restored from an appropriate backup\nsource. If a recovery option is available, the output from 'zpool\nimport' will look something like the following:\n\n\n# zpool import share\ncannot import 'share': I/O error\n Recovery is possible, but will result in some data loss.\n Returning the pool to its state as of Sun Sep 27 12:31:07 2009\n should correct the problem. Approximately 53 seconds of data\n will have to be discarded, irreversibly. Recovery can be\n attempted by executing 'zpool import -F share'. A scrub of the pool\n is strongly recommended following a successful recovery.\n\n\nRecovery actions are requested with the -F option to either\n'zpool clear' or 'zpool import'. Recovery will result in some data\nloss, because it reverts the pool to an earlier state. A dry-run\nrecovery check can be performed by adding the -n option, affirming if\nrecovery is possible without actually reverting the pool to its\nearlier state.\n"
139 #
140 # code: ZFS-8000-8A
141 # keys: ereport.fs.zfs.object.corrupt_data
142 #
143 msgid "ZFS-8000-8A.type"
144 msgstr "Error"
145 msgid "ZFS-8000-8A.severity"
146 msgstr "Critical"
147 msgid "ZFS-8000-8A.description"
148 msgstr "A file or directory could not be read due to corrupt data. Refer to %s for more information."
149 msgid "ZFS-8000-8A.response"
150 msgstr "No automated response will be taken."
151 msgid "ZFS-8000-8A.impact"
152 msgstr "The file or directory is unavailable."
153 msgid "ZFS-8000-8A.action"
154 msgstr "\nRun 'zpool status -x' to determine which pool is damaged:\n\n\n# zpool status -x\n pool: test\n state: ONLINE\nstatus: One or more devices has experienced an error and no valid replicas\n are available. Some filesystem data is corrupt, and applications\n may have been affected.\naction: Destroy the pool and restore from backup.\n see: http://illumos.org/msg/ZFS-8000-8A\n scrub: none requested\nconfig:\n\n NAME STATE READ WRITE CKSUM\n test ONLINE 0 0 2\n c0t0d0 ONLINE 0 0 2\n c0t0d1 ONLINE 0 0 0\n\nerrors: 1 data errors, use '-v' for a list\n\n\nUnfortunately, the data cannot be repaired, and the only choice to\nrepair the data is to restore the pool from backup. Applications attempting to\naccess the corrupted data will get an error (EIO), and data may be permanently\nlost.\n\nOn recent versions of Solaris, the list of affected files can be\nretrieved by using the '-v' option to 'zpool status':\n\n\n# zpool status -xv\n pool: test\n state: ONLINE\nstatus: One or more devices has experienced an error and no valid replicas\n are available. Some filesystem data is corrupt, and applications\n may have been affected.\naction: Destroy the pool and restore from backup.\n see: http://illumos.org/msg/ZFS-8000-8A\n scrub: none requested\nconfig:\n\n NAME STATE READ WRITE CKSUM\n test ONLINE 0 0 2\n c0t0d0 ONLINE 0 0 2\n c0t0d1 ONLINE 0 0 0\n\nerrors: Permanent errors have been detected in the following files:\n\n /export/example/foo\n\n\nDamaged files may or may not be able to be removed depending on the\ntype of corruption. If the corruption is within the plain data, the file should\nbe removable. If the corruption is in the file metadata, then the file cannot\nbe removed, though it can be moved to an alternate location. In either case,\nthe data should be restored from a backup source. It is also possible for the\ncorruption to be within pool-wide metadata, resulting in entire datasets being\nunavailable. If this is the case, the only option is to destroy the pool and\nre-create the datasets from backup.\n "
155 #
156 # code: ZFS-8000-9P
157 # keys: ereport.fs.zfs.device.failing
158 #
159 msgid "ZFS-8000-9P.type"
160 msgstr "Error"
161 msgid "ZFS-8000-9P.severity"
162 msgstr "Minor"
163 msgid "ZFS-8000-9P.description"
164 msgstr "A device has experienced uncorrectable errors in a\n replicated configuration. Refer to %s for more information."
165 msgid "ZFS-8000-9P.response"
166 msgstr "ZFS has attempted to repair the affected data."
167 msgid "ZFS-8000-9P.impact"
168 msgstr "The system is unaffected, though errors may indicate future\n failure. Future errors may cause ZFS to automatically fault\n the device."
169 msgid "ZFS-8000-9P.action"
170 msgstr "\nRun 'zpool status -x' to determine which pool has experienced\nerrors:\n\n\n# zpool status\n pool: test\n state: ONLINE\nstatus: One or more devices has experienced an unrecoverable error. An\n attempt was made to correct the error. Applications are unaffected.\naction: Determine if the device needs to be replaced, and clear the errors\n using 'zpool online' or replace the device with 'zpool replace'.\n see: http://illumos.org/msg/ZFS-8000-9P\n scrub: none requested\nconfig:\n\n NAME STATE READ WRITE CKSUM\n test ONLINE 0 0 0\n mirror ONLINE 0 0 0\n c0t0d0 ONLINE 0 0 2\n c0t0d1 ONLINE 0 0 0\n\nerrors: No known data errors\n\n\nFind the device with a non-zero error count for READ, WRITE, or CKSUM.\nThis indicates that the device has experienced a read I/O error, write I/O\nerror, or checksum validation error. Because the device is part of a mirror or\nRAID-Z device, ZFS was able to recover from the error and subsequently repair\nthe damaged data.\n\nIf these errors persist over a period of time, ZFS may determine the\ndevice is faulty and mark it as such. However, these error counts may or may\nnot indicate that the device is unusable. It depends on how the errors were\ncaused, which the administrator can determine in advance of any ZFS diagnosis.\nFor example, the following cases will all produce errors that do not indicate\npotential device failure:\n\n\nA network attached device lost connectivity but has now\nrecovered\nA device suffered from a bit flip, an expected event over long\nperiods of time\nAn administrator accidentally wrote over a portion of the disk using\nanother program\n\n\nIn these cases, the presence of errors does not indicate that the\ndevice is likely to fail in the future, and therefore does not need to be\nreplaced. If this is the case, then the device errors should be cleared using\n'zpool clear':\n\n\n# zpool clear test c0t0d0\n\n\nOn the other hand, errors may very well indicate that the device has\nfailed or is about to fail. If there are continual I/O errors to a device that\nis otherwise attached and functioning on the system, it most likely needs to be\nreplaced. The administrator should check the system log for any driver\nmessages that may indicate hardware failure. If it is determined that the\ndevice needs to be replaced, then the 'zpool replace' command should be\nused:\n\n\n# zpool replace test c0t0d0 c0t0d2\n\n\nThis will attach the new device to the pool and begin resilvering data\nto it. Once the resilvering process is complete, the old device will\nautomatically be removed from the pool, at which point it can safely be removed\nfrom the system. If the device needs to be replaced in-place (because there are\nno available spare devices), the original device can be removed and replaced\nwith a new device, at which point a different form of 'zpool replace' can be\nused:\n\n\n# zpool replace test c0t0d0\n\n\nThis assumes that the original device at 'c0t0d0' has been replaced\nwith a new device under the same path, and will be replaced\nappropriately.\n\nYou can monitor the progress of the resilvering operation by using the\n'zpool status -x' command:\n\n\n# zpool status -x\n pool: test\n state: DEGRADED\nstatus: One or more devices is currently being replaced. The pool may not be\n providing the necessary level of replication.\naction: Wait for the resilvering operation to complete\n scrub: resilver in progress, 0.14% done, 0h0m to go\nconfig:\n\n NAME STATE READ WRITE CKSUM\n test ONLINE 0 0 0\n mirror ONLINE 0 0 0\n replacing ONLINE 0 0 0\n c0t0d0 ONLINE 0 0 3\n c0t0d2 ONLINE 0 0 0 58.5K resilvered\n c0t0d1 ONLINE 0 0 0\n\nerrors: No known data errors\n\n "
171 #
172 # code: ZFS-8000-A5
173 # keys: ereport.fs.zfs.device.version_mismatch
174 #
|
134 msgstr "No automated response will be taken."
135 msgid "ZFS-8000-72.impact"
136 msgstr "The pool is no longer available"
137 msgid "ZFS-8000-72.action"
138 msgstr "\nEven though all the devices are available, the on-disk data\nhas been corrupted such that the pool cannot be opened. If a recovery\naction is presented, the pool can be returned to a usable state.\nOtherwise, all data within the pool is lost, and the pool must be\ndestroyed and restored from an appropriate backup source. ZFS\nincludes built-in metadata replication to prevent this from happening\neven for unreplicated pools, but running in a replicated configuration\nwill decrease the chances of this happening in the future.\n\nIf this error is encountered during 'zpool import', see the\nsection below. Otherwise, run 'zpool status -x' to determine which\npool is faulted and if a recovery option is available:\n\n\n# zpool status -x\n pool: test\n id: 13783646421373024673\n state: FAULTED\nstatus: The pool metadata is corrupted and cannot be opened.\naction: Recovery is possible, but will result in some data loss.\n Returning the pool to its state as of Mon Sep 28 10:24:39 2009\n should correct the problem. Approximately 59 seconds of data\n will have to be discarded, irreversibly. Recovery can be\n attempted by executing 'zpool clear -F test'. A scrub of the pool\n is strongly recommended following a successful recovery.\n see: http://illumos.org/msg/ZFS-8000-72\nconfig:\n\n NAME STATE READ WRITE CKSUM\n test FAULTED 0 0 2 corrupted data\n c0t0d0 ONLINE 0 0 2\n c0t0d1 ONLINE 0 0 2\n\n\nIf recovery is unavailable, the recommended action will be:\n\n\naction: Destroy the pool and restore from backup.\n\n\nIf this error is encountered during 'zpool import', and if no\nrecovery option is mentioned, the pool is unrecoverable and cannot be\nimported. The pool must be restored from an appropriate backup\nsource. If a recovery option is available, the output from 'zpool\nimport' will look something like the following:\n\n\n# zpool import share\ncannot import 'share': I/O error\n Recovery is possible, but will result in some data loss.\n Returning the pool to its state as of Sun Sep 27 12:31:07 2009\n should correct the problem. Approximately 53 seconds of data\n will have to be discarded, irreversibly. Recovery can be\n attempted by executing 'zpool import -F share'. A scrub of the pool\n is strongly recommended following a successful recovery.\n\n\nRecovery actions are requested with the -F option to either\n'zpool clear' or 'zpool import'. Recovery will result in some data\nloss, because it reverts the pool to an earlier state. A dry-run\nrecovery check can be performed by adding the -n option, affirming if\nrecovery is possible without actually reverting the pool to its\nearlier state.\n"
139 #
140 # code: ZFS-8000-8A
141 # keys: ereport.fs.zfs.object.corrupt_data
142 #
143 msgid "ZFS-8000-8A.type"
144 msgstr "Error"
145 msgid "ZFS-8000-8A.severity"
146 msgstr "Critical"
147 msgid "ZFS-8000-8A.description"
148 msgstr "A file or directory could not be read due to corrupt data. Refer to %s for more information."
149 msgid "ZFS-8000-8A.response"
150 msgstr "No automated response will be taken."
151 msgid "ZFS-8000-8A.impact"
152 msgstr "The file or directory is unavailable."
153 msgid "ZFS-8000-8A.action"
154 msgstr "\nRun 'zpool status -x' to determine which pool is damaged:\n\n\n# zpool status -x\n pool: test\n state: ONLINE\nstatus: One or more devices has experienced an error and no valid replicas\n are available. Some filesystem data is corrupt, and applications\n may have been affected.\naction: Destroy the pool and restore from backup.\n see: http://illumos.org/msg/ZFS-8000-8A\n scrub: none requested\nconfig:\n\n NAME STATE READ WRITE CKSUM\n test ONLINE 0 0 2\n c0t0d0 ONLINE 0 0 2\n c0t0d1 ONLINE 0 0 0\n\nerrors: 1 data errors, use '-v' for a list\n\n\nUnfortunately, the data cannot be repaired, and the only choice to\nrepair the data is to restore the pool from backup. Applications attempting to\naccess the corrupted data will get an error (EIO), and data may be permanently\nlost.\n\nOn recent versions of illumos, the list of affected files can be\nretrieved by using the '-v' option to 'zpool status':\n\n\n# zpool status -xv\n pool: test\n state: ONLINE\nstatus: One or more devices has experienced an error and no valid replicas\n are available. Some filesystem data is corrupt, and applications\n may have been affected.\naction: Destroy the pool and restore from backup.\n see: http://illumos.org/msg/ZFS-8000-8A\n scrub: none requested\nconfig:\n\n NAME STATE READ WRITE CKSUM\n test ONLINE 0 0 2\n c0t0d0 ONLINE 0 0 2\n c0t0d1 ONLINE 0 0 0\n\nerrors: Permanent errors have been detected in the following files:\n\n /export/example/foo\n\n\nDamaged files may or may not be able to be removed depending on the\ntype of corruption. If the corruption is within the plain data, the file should\nbe removable. If the corruption is in the file metadata, then the file cannot\nbe removed, though it can be moved to an alternate location. In either case,\nthe data should be restored from a backup source. It is also possible for the\ncorruption to be within pool-wide metadata, resulting in entire datasets being\nunavailable. If this is the case, the only option is to destroy the pool and\nre-create the datasets from backup.\n "
155 #
156 # code: ZFS-8000-9P
157 # keys: ereport.fs.zfs.device.failing
158 #
159 msgid "ZFS-8000-9P.type"
160 msgstr "Error"
161 msgid "ZFS-8000-9P.severity"
162 msgstr "Minor"
163 msgid "ZFS-8000-9P.description"
164 msgstr "A device has experienced uncorrectable errors in a\n replicated configuration. Refer to %s for more information."
165 msgid "ZFS-8000-9P.response"
166 msgstr "ZFS has attempted to repair the affected data."
167 msgid "ZFS-8000-9P.impact"
168 msgstr "The system is unaffected, though errors may indicate future\n failure. Future errors may cause ZFS to automatically fault\n the device."
169 msgid "ZFS-8000-9P.action"
170 msgstr "\nRun 'zpool status -x' to determine which pool has experienced\nerrors:\n\n\n# zpool status\n pool: test\n state: ONLINE\nstatus: One or more devices has experienced an unrecoverable error. An\n attempt was made to correct the error. Applications are unaffected.\naction: Determine if the device needs to be replaced, and clear the errors\n using 'zpool online' or replace the device with 'zpool replace'.\n see: http://illumos.org/msg/ZFS-8000-9P\n scrub: none requested\nconfig:\n\n NAME STATE READ WRITE CKSUM\n test ONLINE 0 0 0\n mirror ONLINE 0 0 0\n c0t0d0 ONLINE 0 0 2\n c0t0d1 ONLINE 0 0 0\n\nerrors: No known data errors\n\n\nFind the device with a non-zero error count for READ, WRITE, or CKSUM.\nThis indicates that the device has experienced a read I/O error, write I/O\nerror, or checksum validation error. Because the device is part of a mirror or\nRAID-Z device, ZFS was able to recover from the error and subsequently repair\nthe damaged data.\n\nIf these errors persist over a period of time, ZFS may determine the\ndevice is faulty and mark it as such. However, these error counts may or may\nnot indicate that the device is unusable. It depends on how the errors were\ncaused, which the administrator can determine in advance of any ZFS diagnosis.\nFor example, the following cases will all produce errors that do not indicate\npotential device failure:\n\n\nA network attached device lost connectivity but has now\nrecovered\nA device suffered from a bit flip, an expected event over long\nperiods of time\nAn administrator accidentally wrote over a portion of the disk using\nanother program\n\n\nIn these cases, the presence of errors does not indicate that the\ndevice is likely to fail in the future, and therefore does not need to be\nreplaced. If this is the case, then the device errors should be cleared using\n'zpool clear':\n\n\n# zpool clear test c0t0d0\n\n\nOn the other hand, errors may very well indicate that the device has\nfailed or is about to fail. If there are continual I/O errors to a device that\nis otherwise attached and functioning on the system, it most likely needs to be\nreplaced. The administrator should check the system log for any driver\nmessages that may indicate hardware failure. If it is determined that the\ndevice needs to be replaced, then the 'zpool replace' command should be\nused:\n\n\n# zpool replace test c0t0d0 c0t0d2\n\n\nThis will attach the new device to the pool and begin resilvering data\nto it. Once the resilvering process is complete, the old device will\nautomatically be removed from the pool, at which point it can safely be removed\nfrom the system. If the device needs to be replaced in-place (because there are\nno available spare devices), the original device can be removed and replaced\nwith a new device, at which point a different form of 'zpool replace' can be\nused:\n\n\n# zpool replace test c0t0d0\n\n\nThis assumes that the original device at 'c0t0d0' has been replaced\nwith a new device under the same path, and will be replaced\nappropriately.\n\nYou can monitor the progress of the resilvering operation by using the\n'zpool status -x' command:\n\n\n# zpool status -x\n pool: test\n state: DEGRADED\nstatus: One or more devices is currently being replaced. The pool may not be\n providing the necessary level of replication.\naction: Wait for the resilvering operation to complete\n scrub: resilver in progress, 0.14% done, 0h0m to go\nconfig:\n\n NAME STATE READ WRITE CKSUM\n test ONLINE 0 0 0\n mirror ONLINE 0 0 0\n replacing ONLINE 0 0 0\n c0t0d0 ONLINE 0 0 3\n c0t0d2 ONLINE 0 0 0 58.5K resilvered\n c0t0d1 ONLINE 0 0 0\n\nerrors: No known data errors\n\n "
171 #
172 # code: ZFS-8000-A5
173 # keys: ereport.fs.zfs.device.version_mismatch
174 #
|