Project

General

Profile

Actions

Bug #1642

closed

hammer v2 mirror-copy + pfs-upgrade + pfs-downgrade makes data unavail

Added by thomas.nikolajsen over 14 years ago. Updated over 14 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

Description

I have problem where data in a PFS can't be accessed; I did:
(tried to get PFS on laptop, for 26c3)
src$ hammer mirror-copy PFS dst:PFS
src$ hammer pfs-downgrade PFS
dst$ hammer pfs-upgrade PFS

After this PFS was empty on dst; then did:
dst$ hammer pfs-downgrade PFS
src$ hammer pfs-upgrade PFS

Now PFS on src can't be accessed, see below.

This is HAMMER version 2 file systems on both src and dst;
on src it was originally version 1; have been upgraded some time ago.

I also mirror-copy'ed another PFS (no pfs-downgrade/pfs-upgrade),
it is empty on dst, and accessible as usual on src.

Both mirror-copy operations seemed to run with success.

commit ec61b2892719413e2fd52a677fc9a1d05d09d59a
(DragonFly_RELEASE_2_4 HAMMER - Fix root inode creation for slave)
isn't included on dst (build the day before it was committed);
I'm not sure if it is included on src (info is in git repo I can't access).

Any chance to get my data back?

I haven't updated src HAMMER file system since problem.
These data aren't critical (some local changes); do have checkout.

thomas

src$ ls l /hammer/.pfs/home.dragonfly.git
lrwxr-xr-x 1 root wheel 10 May 30 2009 /hammer/.pfs/home.dragonfly.git ->
@@-1:00011
src$ ls -l /hammer/.pfs/home.dragonfly.git/
ls: /hammer/.pfs/home.dragonfly.git/: No such file or directory

src$ hammer version /hammer/.pfs
min=1 wip=3 max=2 current=2 description="2.3 - New directory entry layout"
available versions:
1 NORM 2.0 - First HAMMER release
2 NORM 2.3 - New directory entry layout
src$ hammer pfs-status /hammer/.pfs/home.dragonfly.git
/hammer/.pfs/home.dragonfly.git PFS #11 {
sync-beg-tid=0x0000000000000001
sync-end-tid=0x000000122a2998b0
shared-uuid=1d9b804a-4ca9-11de-85a0-01500442c42b
unique-uuid=1d9b8090-4ca9-11de-85a0-01500442c42b
label=""
prune-min=00:00:00
operating as a MASTER
snapshots dir for master defaults to <fs>/snapshots
}
src$ uname -a
DragonFly ask 2.4.1-RELEASE DragonFly v2.4.1.17.g372c9-RELEASE #4: Mon Oct 12
00:35:07 CEST 2009 root@boy:/usr/obj/usr/src/sys/STANDARD i386

-
dst$ DragonFly bog 2.4.1-RELEASE DragonFly 2.4.1-RELEASE #3: Thu Oct 1
00:44:55 CEST 2009 root@boy:/usr/obj/usr/src/sys/STANDARD i386

Actions #1

Updated by dillon over 14 years ago

:commit ec61b2892719413e2fd52a677fc9a1d05d09d59a
:(DragonFly_RELEASE_2_4 HAMMER - Fix root inode creation for slave)
:isn't included on dst (build the day before it was committed);
:I'm not sure if it is included on src (info is in git repo I can't access).
:
:Any chance to get my data back?
:
:I haven't updated src HAMMER file system since problem.
:These data aren't critical (some local changes); do have checkout.
:
: -thomas

Woa.  That's a serious bug.  I think the data is probably gone.
I reproduced it immediately on my test box.
The bug is in how sync_end_tid (in the PFS staus) is being handled.
The field is not touched for a PFS master and can become stale.
When you downgraded to a slave the stale value was left intact
which made the slave inaccessible. Then when you upgraded to a
master again the PFS upgrade code rolled back the B-Tree to the
state as-of sync_end_tid, which was still a stale value.
When you upgraded the destination after the mirroring operation the
sync_end_tid was already set properly due to the mirroring operation,
so that upgrade should have worked.
I will fix the bug right now.  Basically I have to properly update
sync_end_tid in the PFS status when downgrading a PFS or bad things
happen.
-Matt
Actions #2

Updated by thomas.nikolajsen over 14 years ago

Fixed in commit 1ee600fb7b4fd882b22f201fcbc67a0f632b21ac
thank you.

-thomas
Actions

Also available in: Atom PDF