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
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 happens
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
> f
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 i
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 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 ditt
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 for all metadata, so that even if any block
> of ZFS metada
> 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 for all metadata, so that even if any block
of ZFS metadata is destroyed, we always have another copy.
Bill Moore describes ditto
> 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 block
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 to
See:
http://www.opensolaris.org/jive/thread.jspa?threadID=11305&tstart=0
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 accoun
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 sh
> 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
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, Jul
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 questio
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.
(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)
Product: event_registry
Category: events
Sub-Category: msg
Thanks, I filed 6450642.
- Eric
___
zfs-discuss mailing
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
___
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
19 matches
Mail list logo
