* Power Outage Corruption - Recovery?
@ 2014-08-09 22:15 Matt Parnell
2014-08-10 7:17 ` Jaegeuk Kim
0 siblings, 1 reply; 4+ messages in thread
From: Matt Parnell @ 2014-08-09 22:15 UTC (permalink / raw)
To: linux-f2fs-devel
[-- Attachment #1.1: Type: text/plain, Size: 3166 bytes --]
I had a similar issue as a gentlemen whose message I recently read on this
list, where power loss caused his f2fs partition to cause a kernel oops
every time it was attempted to mount. I have the same issue. Is any form of
recovery possible?
Photorec was able to get most of it but there are two hard drive keys and a
keepass database that I wish to try and recover.
Setting fsck.f2fs debug level to 9, I can get output like the below and
even view the inode information with dump.f2fs.
Is there a way I can, through a program or through hex editing, get these
files back, or even repair the whole partition?
Thanks!
fsck output:
[fsck_chk_dentry_blk: 567] [ 2] - no[0x8d] name[keys] len[0x4] ino[0x3a1]
type[0x2]
[fsck_chk_xattr_blk: 709] ino[0x3a1] x_nid[0x3a8]
[fsck_chk_dentry_blk: 567] [ 3] - no[0x2] name[storage.key] len[0xb]
ino[0x3a2] type[0x1]
[fsck_chk_xattr_blk: 709] ino[0x3a2] x_nid[0x3a3]
[fsck_chk_dentry_blk: 567] [ 3] - no[0x4] name[tmp.key] len[0x7]
ino[0x3a4] type[0x1]
[fsck_chk_xattr_blk: 709] ino[0x3a4] x_nid[0x3a5]
[fsck_chk_dentry_blk: 567] [ 3] - no[0x5] name[home.key] len[0x8]
ino[0x3a6] type[0x1]
[fsck_chk_xattr_blk: 709] ino[0x3a6] x_nid[0x3a7]
[fsck_chk_dentry_blk: 588] [ 3] Dentry Block [0xac3912] Done : dentries:3
in 214 slots (len:255)
[fsck_chk_inode_blk: 379] Directory Inode: ino: 3a1 name: keys depth: 1
child files: 3
inode dump:
Info: sector size = 512
Info: total sectors = 92270592 (in 512bytes)
[print_node_info: 77] Node ID [0x3a2:930] is inode
i_mode [0x 81a4 : 33188]
i_uid [0x 0 : 0]
i_gid [0x 0 : 0]
i_links [0x 1 : 1]
i_size [0x 1000 : 4096]
i_blocks [0x 3 : 3]
i_atime [0x53b92ed2 : 1404645074]
i_atime_nsec [0x234fa2de : 592421598]
i_ctime [0x53ba3331 : 1404711729]
i_ctime_nsec [0x3a88bfa8 : 982040488]
i_mtime [0x53b90ec9 : 1404636873]
i_mtime_nsec [0x374e1dc2 : 927866306]
i_generation [0xf382a0df : 4085424351]
i_current_depth [0x 1 : 1]
i_xattr_nid [0x 3a3 : 931]
i_flags [0x 0 : 0]
i_pino [0x 3a1 : 929]
i_namelen [0x b : 11]
i_name [storage.key]
i_ext: fofs:0 blkaddr:693511 len:1
i_addr[0] [0x 693511 : 6894865]
i_addr[1] [0x 0 : 0]
i_addr[2] [0x 0 : 0]
i_addr[3] [0x 0 : 0]
i_nid[0] [0x 0 : 0]
i_nid[1] [0x 0 : 0]
i_nid[2] [0x 0 : 0]
i_nid[3] [0x 0 : 0]
i_nid[4] [0x 0 : 0]
Done.
[-- Attachment #1.2: Type: text/html, Size: 4307 bytes --]
[-- Attachment #2: Type: text/plain, Size: 79 bytes --]
------------------------------------------------------------------------------
[-- Attachment #3: Type: text/plain, Size: 179 bytes --]
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Power Outage Corruption - Recovery?
2014-08-09 22:15 Power Outage Corruption - Recovery? Matt Parnell
@ 2014-08-10 7:17 ` Jaegeuk Kim
2014-08-10 8:36 ` Matt Parnell
0 siblings, 1 reply; 4+ messages in thread
From: Jaegeuk Kim @ 2014-08-10 7:17 UTC (permalink / raw)
To: Matt Parnell; +Cc: linux-f2fs-devel
Hi Matt,
On Sat, Aug 09, 2014 at 10:15:15PM +0000, Matt Parnell wrote:
> I had a similar issue as a gentlemen whose message I recently read on this
> list, where power loss caused his f2fs partition to cause a kernel oops
> every time it was attempted to mount. I have the same issue. Is any form of
> recovery possible?
Ok, it seems that there is a roll-forward bug.
Could you mount it with -o disable_roll_forward?
>
> Photorec was able to get most of it but there are two hard drive keys and a
> keepass database that I wish to try and recover.
>
> Setting fsck.f2fs debug level to 9, I can get output like the below and
> even view the inode information with dump.f2fs.
I think I can add some codes in dump.f2fs to recover specific files with
inode numbers.
I'll look into this.
Thanks,
>
> Is there a way I can, through a program or through hex editing, get these
> files back, or even repair the whole partition?
>
> Thanks!
>
> fsck output:
>
> [fsck_chk_dentry_blk: 567] [ 2] - no[0x8d] name[keys] len[0x4] ino[0x3a1]
> type[0x2]
> [fsck_chk_xattr_blk: 709] ino[0x3a1] x_nid[0x3a8]
> [fsck_chk_dentry_blk: 567] [ 3] - no[0x2] name[storage.key] len[0xb]
> ino[0x3a2] type[0x1]
> [fsck_chk_xattr_blk: 709] ino[0x3a2] x_nid[0x3a3]
> [fsck_chk_dentry_blk: 567] [ 3] - no[0x4] name[tmp.key] len[0x7]
> ino[0x3a4] type[0x1]
> [fsck_chk_xattr_blk: 709] ino[0x3a4] x_nid[0x3a5]
> [fsck_chk_dentry_blk: 567] [ 3] - no[0x5] name[home.key] len[0x8]
> ino[0x3a6] type[0x1]
> [fsck_chk_xattr_blk: 709] ino[0x3a6] x_nid[0x3a7]
> [fsck_chk_dentry_blk: 588] [ 3] Dentry Block [0xac3912] Done : dentries:3
> in 214 slots (len:255)
>
> [fsck_chk_inode_blk: 379] Directory Inode: ino: 3a1 name: keys depth: 1
> child files: 3
>
> inode dump:
>
> Info: sector size = 512
> Info: total sectors = 92270592 (in 512bytes)
> [print_node_info: 77] Node ID [0x3a2:930] is inode
> i_mode [0x 81a4 : 33188]
> i_uid [0x 0 : 0]
> i_gid [0x 0 : 0]
> i_links [0x 1 : 1]
> i_size [0x 1000 : 4096]
> i_blocks [0x 3 : 3]
> i_atime [0x53b92ed2 : 1404645074]
> i_atime_nsec [0x234fa2de : 592421598]
> i_ctime [0x53ba3331 : 1404711729]
> i_ctime_nsec [0x3a88bfa8 : 982040488]
> i_mtime [0x53b90ec9 : 1404636873]
> i_mtime_nsec [0x374e1dc2 : 927866306]
> i_generation [0xf382a0df : 4085424351]
> i_current_depth [0x 1 : 1]
> i_xattr_nid [0x 3a3 : 931]
> i_flags [0x 0 : 0]
> i_pino [0x 3a1 : 929]
> i_namelen [0x b : 11]
> i_name [storage.key]
> i_ext: fofs:0 blkaddr:693511 len:1
> i_addr[0] [0x 693511 : 6894865]
> i_addr[1] [0x 0 : 0]
> i_addr[2] [0x 0 : 0]
> i_addr[3] [0x 0 : 0]
> i_nid[0] [0x 0 : 0]
> i_nid[1] [0x 0 : 0]
> i_nid[2] [0x 0 : 0]
> i_nid[3] [0x 0 : 0]
> i_nid[4] [0x 0 : 0]
>
>
> Done.
> ------------------------------------------------------------------------------
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
------------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Power Outage Corruption - Recovery?
2014-08-10 7:17 ` Jaegeuk Kim
@ 2014-08-10 8:36 ` Matt Parnell
2014-08-10 8:37 ` Matt Parnell
0 siblings, 1 reply; 4+ messages in thread
From: Matt Parnell @ 2014-08-10 8:36 UTC (permalink / raw)
To: Jaegeuk Kim; +Cc: linux-f2fs-devel
[-- Attachment #1.1: Type: text/plain, Size: 4564 bytes --]
Disabling roll forward allowed for the mount, excellent! I really should
have tried that option before bothering you, though it may have prevented
disclosure of the bug.
I still believe that adding the recovery option for dump could be a good
thing to do. Seeing as how this is working out, I'll copy the files,
reformat, and carry on with f2fs. It runs quite well on both my phone and
my intel ssd on top of Lukas with discards enabled.
On Aug 10, 2014 2:17 AM, "Jaegeuk Kim" <jaegeuk@kernel.org> wrote:
> Hi Matt,
>
> On Sat, Aug 09, 2014 at 10:15:15PM +0000, Matt Parnell wrote:
> > I had a similar issue as a gentlemen whose message I recently read on
> this
> > list, where power loss caused his f2fs partition to cause a kernel oops
> > every time it was attempted to mount. I have the same issue. Is any form
> of
> > recovery possible?
>
> Ok, it seems that there is a roll-forward bug.
> Could you mount it with -o disable_roll_forward?
>
> >
> > Photorec was able to get most of it but there are two hard drive keys
> and a
> > keepass database that I wish to try and recover.
> >
> > Setting fsck.f2fs debug level to 9, I can get output like the below and
> > even view the inode information with dump.f2fs.
>
> I think I can add some codes in dump.f2fs to recover specific files with
> inode numbers.
> I'll look into this.
>
> Thanks,
>
> >
> > Is there a way I can, through a program or through hex editing, get these
> > files back, or even repair the whole partition?
> >
> > Thanks!
> >
> > fsck output:
> >
> > [fsck_chk_dentry_blk: 567] [ 2] - no[0x8d] name[keys] len[0x4]
> ino[0x3a1]
> > type[0x2]
> > [fsck_chk_xattr_blk: 709] ino[0x3a1] x_nid[0x3a8]
> > [fsck_chk_dentry_blk: 567] [ 3] - no[0x2] name[storage.key] len[0xb]
> > ino[0x3a2] type[0x1]
> > [fsck_chk_xattr_blk: 709] ino[0x3a2] x_nid[0x3a3]
> > [fsck_chk_dentry_blk: 567] [ 3] - no[0x4] name[tmp.key] len[0x7]
> > ino[0x3a4] type[0x1]
> > [fsck_chk_xattr_blk: 709] ino[0x3a4] x_nid[0x3a5]
> > [fsck_chk_dentry_blk: 567] [ 3] - no[0x5] name[home.key] len[0x8]
> > ino[0x3a6] type[0x1]
> > [fsck_chk_xattr_blk: 709] ino[0x3a6] x_nid[0x3a7]
> > [fsck_chk_dentry_blk: 588] [ 3] Dentry Block [0xac3912] Done :
> dentries:3
> > in 214 slots (len:255)
> >
> > [fsck_chk_inode_blk: 379] Directory Inode: ino: 3a1 name: keys depth: 1
> > child files: 3
> >
> > inode dump:
> >
> > Info: sector size = 512
> > Info: total sectors = 92270592 (in 512bytes)
> > [print_node_info: 77] Node ID [0x3a2:930] is inode
> > i_mode [0x 81a4 : 33188]
> > i_uid [0x 0 : 0]
> > i_gid [0x 0 : 0]
> > i_links [0x 1 : 1]
> > i_size [0x 1000 : 4096]
> > i_blocks [0x 3 : 3]
> > i_atime [0x53b92ed2 : 1404645074]
> > i_atime_nsec [0x234fa2de : 592421598]
> > i_ctime [0x53ba3331 : 1404711729]
> > i_ctime_nsec [0x3a88bfa8 : 982040488]
> > i_mtime [0x53b90ec9 : 1404636873]
> > i_mtime_nsec [0x374e1dc2 : 927866306]
> > i_generation [0xf382a0df : 4085424351]
> > i_current_depth [0x 1 : 1]
> > i_xattr_nid [0x 3a3 : 931]
> > i_flags [0x 0 : 0]
> > i_pino [0x 3a1 : 929]
> > i_namelen [0x b : 11]
> > i_name [storage.key]
> > i_ext: fofs:0 blkaddr:693511 len:1
> > i_addr[0] [0x 693511 : 6894865]
> > i_addr[1] [0x 0 : 0]
> > i_addr[2] [0x 0 : 0]
> > i_addr[3] [0x 0 : 0]
> > i_nid[0] [0x 0 : 0]
> > i_nid[1] [0x 0 : 0]
> > i_nid[2] [0x 0 : 0]
> > i_nid[3] [0x 0 : 0]
> > i_nid[4] [0x 0 : 0]
> >
> >
> > Done.
>
> >
> ------------------------------------------------------------------------------
>
> > _______________________________________________
> > Linux-f2fs-devel mailing list
> > Linux-f2fs-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
>
>
[-- Attachment #1.2: Type: text/html, Size: 5969 bytes --]
[-- Attachment #2: Type: text/plain, Size: 79 bytes --]
------------------------------------------------------------------------------
[-- Attachment #3: Type: text/plain, Size: 179 bytes --]
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Power Outage Corruption - Recovery?
2014-08-10 8:36 ` Matt Parnell
@ 2014-08-10 8:37 ` Matt Parnell
0 siblings, 0 replies; 4+ messages in thread
From: Matt Parnell @ 2014-08-10 8:37 UTC (permalink / raw)
To: Jaegeuk Kim; +Cc: linux-f2fs-devel
[-- Attachment #1.1: Type: text/plain, Size: 4789 bytes --]
Luks that is. Autocorrect error.
On Aug 10, 2014 3:36 AM, "Matt Parnell" <mparnell@gmail.com> wrote:
> Disabling roll forward allowed for the mount, excellent! I really should
> have tried that option before bothering you, though it may have prevented
> disclosure of the bug.
>
> I still believe that adding the recovery option for dump could be a good
> thing to do. Seeing as how this is working out, I'll copy the files,
> reformat, and carry on with f2fs. It runs quite well on both my phone and
> my intel ssd on top of Lukas with discards enabled.
> On Aug 10, 2014 2:17 AM, "Jaegeuk Kim" <jaegeuk@kernel.org> wrote:
>
>> Hi Matt,
>>
>> On Sat, Aug 09, 2014 at 10:15:15PM +0000, Matt Parnell wrote:
>> > I had a similar issue as a gentlemen whose message I recently read on
>> this
>> > list, where power loss caused his f2fs partition to cause a kernel oops
>> > every time it was attempted to mount. I have the same issue. Is any
>> form of
>> > recovery possible?
>>
>> Ok, it seems that there is a roll-forward bug.
>> Could you mount it with -o disable_roll_forward?
>>
>> >
>> > Photorec was able to get most of it but there are two hard drive keys
>> and a
>> > keepass database that I wish to try and recover.
>> >
>> > Setting fsck.f2fs debug level to 9, I can get output like the below and
>> > even view the inode information with dump.f2fs.
>>
>> I think I can add some codes in dump.f2fs to recover specific files with
>> inode numbers.
>> I'll look into this.
>>
>> Thanks,
>>
>> >
>> > Is there a way I can, through a program or through hex editing, get
>> these
>> > files back, or even repair the whole partition?
>> >
>> > Thanks!
>> >
>> > fsck output:
>> >
>> > [fsck_chk_dentry_blk: 567] [ 2] - no[0x8d] name[keys] len[0x4]
>> ino[0x3a1]
>> > type[0x2]
>> > [fsck_chk_xattr_blk: 709] ino[0x3a1] x_nid[0x3a8]
>> > [fsck_chk_dentry_blk: 567] [ 3] - no[0x2] name[storage.key] len[0xb]
>> > ino[0x3a2] type[0x1]
>> > [fsck_chk_xattr_blk: 709] ino[0x3a2] x_nid[0x3a3]
>> > [fsck_chk_dentry_blk: 567] [ 3] - no[0x4] name[tmp.key] len[0x7]
>> > ino[0x3a4] type[0x1]
>> > [fsck_chk_xattr_blk: 709] ino[0x3a4] x_nid[0x3a5]
>> > [fsck_chk_dentry_blk: 567] [ 3] - no[0x5] name[home.key] len[0x8]
>> > ino[0x3a6] type[0x1]
>> > [fsck_chk_xattr_blk: 709] ino[0x3a6] x_nid[0x3a7]
>> > [fsck_chk_dentry_blk: 588] [ 3] Dentry Block [0xac3912] Done :
>> dentries:3
>> > in 214 slots (len:255)
>> >
>> > [fsck_chk_inode_blk: 379] Directory Inode: ino: 3a1 name: keys depth: 1
>> > child files: 3
>> >
>> > inode dump:
>> >
>> > Info: sector size = 512
>> > Info: total sectors = 92270592 (in 512bytes)
>> > [print_node_info: 77] Node ID [0x3a2:930] is inode
>> > i_mode [0x 81a4 : 33188]
>> > i_uid [0x 0 : 0]
>> > i_gid [0x 0 : 0]
>> > i_links [0x 1 : 1]
>> > i_size [0x 1000 : 4096]
>> > i_blocks [0x 3 : 3]
>> > i_atime [0x53b92ed2 : 1404645074]
>> > i_atime_nsec [0x234fa2de : 592421598]
>> > i_ctime [0x53ba3331 : 1404711729]
>> > i_ctime_nsec [0x3a88bfa8 : 982040488]
>> > i_mtime [0x53b90ec9 : 1404636873]
>> > i_mtime_nsec [0x374e1dc2 : 927866306]
>> > i_generation [0xf382a0df : 4085424351]
>> > i_current_depth [0x 1 : 1]
>> > i_xattr_nid [0x 3a3 : 931]
>> > i_flags [0x 0 : 0]
>> > i_pino [0x 3a1 : 929]
>> > i_namelen [0x b : 11]
>> > i_name [storage.key]
>> > i_ext: fofs:0 blkaddr:693511 len:1
>> > i_addr[0] [0x 693511 : 6894865]
>> > i_addr[1] [0x 0 : 0]
>> > i_addr[2] [0x 0 : 0]
>> > i_addr[3] [0x 0 : 0]
>> > i_nid[0] [0x 0 : 0]
>> > i_nid[1] [0x 0 : 0]
>> > i_nid[2] [0x 0 : 0]
>> > i_nid[3] [0x 0 : 0]
>> > i_nid[4] [0x 0 : 0]
>> >
>> >
>> > Done.
>>
>> >
>> ------------------------------------------------------------------------------
>>
>> > _______________________________________________
>> > Linux-f2fs-devel mailing list
>> > Linux-f2fs-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
>>
>>
[-- Attachment #1.2: Type: text/html, Size: 6418 bytes --]
[-- Attachment #2: Type: text/plain, Size: 79 bytes --]
------------------------------------------------------------------------------
[-- Attachment #3: Type: text/plain, Size: 179 bytes --]
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-08-10 8:37 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-08-09 22:15 Power Outage Corruption - Recovery? Matt Parnell
2014-08-10 7:17 ` Jaegeuk Kim
2014-08-10 8:36 ` Matt Parnell
2014-08-10 8:37 ` Matt Parnell
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.