Eric Schrock wrote:
Well the fact that it's a level 2 indirect block indicates why it can't
simply be removed. We don't know what data it refers to, so we can't
free the associated blocks. The panic on move is quite interesting -
after BFU give it another shot and file a bug if it still
Eric Lowe wrote:
Eric Schrock wrote:
Well the fact that it's a level 2 indirect block indicates why it can't
simply be removed. We don't know what data it refers to, so we can't
free the associated blocks. The panic on move is quite interesting -
after BFU give it another shot and file a bug
Hello Bill,
Friday, July 21, 2006, 7:31:25 AM, you wrote:
BM On Thu, Jul 20, 2006 at 03:45:54PM -0700, Jeff Bonwick wrote:
However, we do have the advantage of always knowing when something
is corrupted, and knowing what that particular block should have been.
We also have ditto blocks
After reading the ditto blocks blog (good article, btw), an idea occurred to me:Since we use ditto blocks to preserve critical filesystem data, would it be practical to add a filesystem property that would cause all files in a filesystem to be stored as mirrored blocks?That would allow a dual-copy
Hello Gregory,
Friday, July 21, 2006, 3:22:17 PM, you wrote:
After reading the ditto blocks blog (good article, btw), an idea occurred to me:
Since we use ditto blocks to preserve critical filesystem data, would it be practical to add a filesystem property that would cause all files
On Fri, Jul 21, 2006 at 07:22:17AM -0600, Gregory Shaw wrote:
After reading the ditto blocks blog (good article, btw), an idea
occurred to me:
Since we use ditto blocks to preserve critical filesystem data, would
it be practical to add a filesystem property that would cause all
files
What does 'zpool status -v' show? This sounds like you have corruption
in the dnode (a.k.a. metadata). This corruption is unrepairable at the
moment, since we have no way of knowing the extent of the blocks that
this dnode may be referencing. You should be able to move this file
aside, however.
Eric Schrock wrote:
What does 'zpool status -v' show? This sounds like you have corruption
# zpool status -v
pool: junk
state: ONLINE
status: One or more devices has experienced an error resulting in data
corruption. Applications may be affected.
action: Restore the file in
Well the fact that it's a level 2 indirect block indicates why it can't
simply be removed. We don't know what data it refers to, so we can't
free the associated blocks. The panic on move is quite interesting -
after BFU give it another shot and file a bug if it still happens.
- Eric
On Thu,
Well the fact that it's a level 2 indirect block indicates why it can't
simply be removed. We don't know what data it refers to, so we can't
free the associated blocks. The panic on move is quite interesting -
after BFU give it another shot and file a bug if it still happens.
What's the
On Thu, 20 Jul 2006, Darren Dunham wrote:
Well the fact that it's a level 2 indirect block indicates why it can't
simply be removed. We don't know what data it refers to, so we can't
free the associated blocks. The panic on move is quite interesting -
after BFU give it another shot and
Note that there are two common reasons to have a fsck-like utility -
1. Detect corruption
2. Repair corruption
For the first, we have scrubbing (and eventually background scrubbing)
so it's pointless in the ZFS world. For the latter, the type of things
it repairs are known pathologies endemic
Basically, the first step is to identify the file in question so the
user knows what's been lost. The second step is a way to move these
blocks into pergatory, where they won't take up filesystem namespace,
but still account for used space. The final step is to actually delete
the blocks
I had a checksum error occur in a file. Since only one file is corrupt
(and it's a link library at that) I don't want to blow away the whole pool
to remove the corrupt file. However, I can't figure out any way to unlink
the file. Using rm to try to unlink the file I get EIO:
% rm llib-lip.ln
On Wed, 19 Jul 2006, Eric Lowe wrote:
(Also BTW that page has a typo, you might want to get the typo fixed, I
didn't know where the doc bugs should go for those messages)
- Eric
Product: event_registry
Category: events
Sub-Category: msg
-tim
15 matches
Mail list logo
