On 2012-Nov-19 14:38:30 -0700, Mark Shellenbaum
wrote:
>On 11/19/12 1:14 PM, Jim Klimov wrote:
>> On 2012-11-19 20:58, Mark Shellenbaum wrote:
>>> There is probably nothing wrong with the snapshots. This is a bug in
>>> ZFS diff. The ZPL parent pointer is only guaranteed to be correct for
>>> d
On 2012-Nov-19 21:10:56 +0100, Jim Klimov wrote:
>On 2012-11-19 20:28, Peter Jeremy wrote:
>> Yep - that's the fallback solution. With 1874 snapshots spread over 54
>> filesystems (including a couple of clones), that's a major undertaking.
>> (And it loses timestamp information).
>
>Well, as long
On 2012-11-19 22:38, Mark Shellenbaum wrote:
The parent pointer is a single 64 bit quantity that can't track all the
possible parents a hard linked file could have.
I believe it is inode number of the parent, or similar to that - and
an available inode number can get recycled and used by newer
On 11/19/12 1:14 PM, Jim Klimov wrote:
On 2012-11-19 20:58, Mark Shellenbaum wrote:
There is probably nothing wrong with the snapshots. This is a bug in
ZFS diff. The ZPL parent pointer is only guaranteed to be correct for
directory objects. What you probably have is a file that was hard
link
On 19 November, 2012 - Jim Klimov sent me these 1,1K bytes:
> Oh, and one more thing: rsync is only good if your filesystems don't
> really rely on ZFS/NFSv4-style ACLs. If you need those, you are stuck
> with Solaris tar or Solaris cpio to carry the files over, or you have
> to script up replicat
Oh, and one more thing: rsync is only good if your filesystems don't
really rely on ZFS/NFSv4-style ACLs. If you need those, you are stuck
with Solaris tar or Solaris cpio to carry the files over, or you have
to script up replication of ACLs after rsync somehow.
You should also replicate the "loc
On 2012-11-19 20:58, Mark Shellenbaum wrote:
There is probably nothing wrong with the snapshots. This is a bug in
ZFS diff. The ZPL parent pointer is only guaranteed to be correct for
directory objects. What you probably have is a file that was hard
linked multiple times and the parent pointer
On 2012-11-19 20:28, Peter Jeremy wrote:
Yep - that's the fallback solution. With 1874 snapshots spread over 54
filesystems (including a couple of clones), that's a major undertaking.
(And it loses timestamp information).
Well, as long as you have and know the base snapshots for the clones,
yo
On 11/16/12 17:15, Peter Jeremy wrote:
I have been tracking down a problem with "zfs diff" that reveals
itself variously as a hang (unkillable process), panic or error,
depending on the ZFS kernel version but seems to be caused by
corruption within the pool. I am using FreeBSD but the issue look
On 2012-Nov-19 13:47:01 -0500, Ray Arachelian wrote:
>On 11/19/2012 12:03 PM, Peter Jeremy wrote:
>> The damage exists in the oldest snapshot for that filesystem.
>Are you able to delete that snapshot?
Yes but it has no effect - the corrupt object exists in the current
pool so deleting an old sna
On 2012-Nov-19 09:10:36 -0800, Freddie Cash wrote:
>Create new pool.
>Create new filesystem.
>rsync data from /path/to/filesystem/.zfs/snapshot/snapname/ to new filesystem
>Snapshot new filesystem.
>rsync data from /path/to/filesystem/.zfs/snapshot/snapname+1/ to new filesystem
>Snapshot new files
On 11/19/2012 12:03 PM, Peter Jeremy wrote:
> On 2012-Nov-19 11:02:06 -0500, Ray Arachelian wrote:
>
>
> The damage exists in the oldest snapshot for that filesystem.
>
Are you able to delete that snapshot?
___
zfs-discuss mailing list
zfs-discuss@open
On Mon, Nov 19, 2012 at 9:03 AM, Peter Jeremy wrote:
> On 2012-Nov-19 11:02:06 -0500, Ray Arachelian wrote:
>>Is the pool importing properly at least? Maybe you can create another
>>volume and transfer the data over for that volume, then destroy it?
>
> The pool is imported and passes all tests
On 2012-Nov-19 11:02:06 -0500, Ray Arachelian wrote:
>Is the pool importing properly at least? Maybe you can create another
>volume and transfer the data over for that volume, then destroy it?
The pool is imported and passes all tests except "zfs diff". Creating
another pool _is_ an option but
On 11/16/2012 07:15 PM, Peter Jeremy wrote:
> I have been tracking down a problem with "zfs diff" that reveals
> itself variously as a hang (unkillable process), panic or error,
> depending on the ZFS kernel version but seems to be caused by
> corruption within the pool. I am using FreeBSD but the
I have been tracking down a problem with "zfs diff" that reveals
itself variously as a hang (unkillable process), panic or error,
depending on the ZFS kernel version but seems to be caused by
corruption within the pool. I am using FreeBSD but the issue looks to
be generic ZFS, rather than FreeBSD-
16 matches
Mail list logo
