Tag Archives: jfs

How to recover a deleted file in aix / jfs?

It is possible to recover the file using the “fsdb” command (filesystem debugger). when,

No new files have been created on the filesystem.

No files have been extended.

The filesystem is able to be unmounted.

Warning: I have test this in my test server. This is undocumented one. You may facing the critical problem when you follow the below steps on your systems. So try this at your own risk. Please avoid directly try this with your production servers. Here is the output for your reference.

You can get deleted files inode if you don’t have.

#fuser -dV

inode=68     size=34358697984  fd=6
inode=76     size=16106135552  fd=7
inode=65     size=34358697984  fd=16
inode=68     size=34358697984  fd=11
inode=68     size=34358697984  fd=7
inode=68     size=34358697984  fd=6

# lsvg -l testvg

testvg:

LV NAME             TYPE       LPs   PPs   PVs  LV STATE      MOUNT POINT

loglv00             jfs2log    1     1     1    closed/syncd  N/A

#

# crfs -a size=256M -v jfs2 -g testvg -m /new            à create a “/new” FS

File system created successfully.

261932 kilobytes total disk space.

New File System size is 524288

#

# lsvg -l testvg

testvg:

LV NAME             TYPE       LPs   PPs   PVs  LV STATE      MOUNT POINT

loglv00             jfs2log    1     1     1    closed/syncd  N/A

fslv00              jfs2       16    16    1    closed/syncd  /new

#

# mount /new         à mount the /new FS

#

# lsvg -l testvg

testvg:

LV NAME             TYPE       LPs   PPs   PVs  LV STATE      MOUNT POINT

loglv00             jfs2log    1     1     1    open/syncd    N/A

fslv00              jfs2       16    16    1    open/syncd    /new

#

# cd /new

#

# ls -l

total 0

drwxr-xr-x   2 root     system          256 Apr 03 16:47 lost+found

#

# cat >> film         à Create a file named “film”

Hi this is the test file. I want to use this file for recovery test

^C#

#

# cat film

Hi this is the test file. I want to use this file for recovery test

#

# ls –il        à check the inode number of the file “film”. That is 4

total 8

4 -rw-r–r–   1 root     system           68 Apr 03 16:49 film

3 drwxr-xr-x   2 root     system          256 Apr 03 16:47 lost+found

#

#

# rm film     à remove the file “film”

#

# ls -l

total 0

drwxr-xr-x   2 root     system          256 Apr 03 16:47 lost+found

#

# cd ~

#

# umount /new     à unmount the /new FS

#

# lsvg -l testvg

testvg:

LV NAME             TYPE       LPs   PPs   PVs  LV STATE      MOUNT POINT

loglv00             jfs2log    1     1     1    closed/syncd  N/A

fslv00              jfs2       16    16    1    closed/syncd  /new

#

# fsdb /dev/fslv00       à use the “fsdb <lv_name>” to recover the deleted  file.

File System:                    /dev/fslv00

File System Size:               523864  (512 byte blocks)

Aggregate Block Size:           4096

Allocation Group Size:          8192    (aggregate blocks)

> dir 2

idotdot = 2

3      lost+found

>

> i 4     à provide the inode number of our deleted file. That is 4

Inode 4 at block 33, offset 0x800:

[1] di_fileset:         16                 [18] di_inostamp:       0x4d98ead4

[2] di_number:          4               [19] di_gen:            3940655789

[3] di_size:    0x0000000000000044      [20] di_ixpxd.len:      4

[4] di_nblocks: 0x0000000000000001      [21] di_ixpxd.addr1:    0x00

[5] di_nlink:           0               [22] di_ixpxd.addr2:    0x00000021

[6] di_mode:            0x000081a4           di_ixpxd.address:  33

0100644 -rw-r–r–      [24] di_uid:            0

[25] di_gid:            0

[9] di_atime.tj_nsec:   0x1e8a1025      [26] di_atime.tj_sec:0x000000004d98eb7d

[10] di_ctime.tj_nsec:  0x0ca85614      [27] di_ctime.tj_sec:0x000000004d98ebac

[11] di_mtime.tj_nsec:  0x1af63892      [28] di_mtime.tj_sec:0x000000004d98eb77

[12] di_otime.tj_nsec:  0x03b74a9a      [29] di_otime.tj_sec:0x000000004d98eb24

[13] di_ea.flag:        0x00            [30] di_ea.len:         0

EAv1                               [31] di_ea.addr1:       0x00

[15] di_ea.nEntry:      0x00            [32] di_ea.addr2:       0x00000000

[16] di_ea.type:        0x0000               di_ea.address:     0

[34] di_ea.nblocks:     0

change_inode: [m]odify, [e]a, [t]ree, or e[x]it > m     à choose “m” to modify

Please enter: field-number value > 5  1   à  put the field number is 5, change the di_nlink value to 1

Inode 4 at block 33, offset 0x800:

[1] di_fileset:         16              [18] di_inostamp:       0x4d98ead4

[2] di_number:          4               [19] di_gen:            3940655789

[3] di_size:    0x0000000000000044      [20] di_ixpxd.len:      4

[4] di_nblocks: 0x0000000000000001      [21] di_ixpxd.addr1:    0x00

[5] di_nlink:           1               [22] di_ixpxd.addr2:    0x00000021

[6] di_mode:            0x000081a4           di_ixpxd.address:  33

0100644 -rw-r–r–      [24] di_uid:            0

[25] di_gid:            0

[9] di_atime.tj_nsec:   0x1e8a1025      [26] di_atime.tj_sec:0x000000004d98eb7d

[10] di_ctime.tj_nsec:  0x0ca85614      [27] di_ctime.tj_sec:0x000000004d98ebac

[11] di_mtime.tj_nsec:  0x1af63892      [28] di_mtime.tj_sec:0x000000004d98eb77

[12] di_otime.tj_nsec:  0x03b74a9a      [29] di_otime.tj_sec:0x000000004d98eb24

[13] di_ea.flag:        0x00            [30] di_ea.len:         0

EAv1                               [31] di_ea.addr1:       0x00

[15] di_ea.nEntry:      0x00            [32] di_ea.addr2:       0x00000000

[16] di_ea.type:        0x0000               di_ea.address:     0

[34] di_ea.nblocks:     0

change_inode: [m]odify, [e]a, [t]ree, or e[x]it > x    à exit

> quit

#

# fsck -yp /dev/fslv00     à run fsck to repaired the  inconsistencies.

The current volume is: /dev/fslv00

Primary superblock is valid.

J2_LOGREDO:log redo processing for /dev/fslv00

logredo start at: 1301867616 sec and end at 1301867616 sec

Primary superblock is valid.

*** Phase 1 – Initial inode scan

*** Phase 2 – Process remaining directories

*** Phase 3 – Process remaining files

*** Phase 4 – Check and repair inode allocation map

File system inode map is corrupt (FIXED)

Superblock marked dirty because repairs are about to be written.

*** Phase 5 – Check and repair block allocation map

Block allocation map is corrupt (FIXED)

Inodes not connected to the root directory

tree have been detected.  Will reconnect.

File system is clean.

Superblock is marked dirty (FIXED)

All observed inconsistencies have been repaired.

#

# mount /new   à mount the /new FS

# lsvg -l testvg

testvg:

LV NAME             TYPE       LPs   PPs   PVs  LV STATE      MOUNT POINT

loglv00             jfs2log    1     1     1    open/syncd    N/A

fslv00              jfs2       16    16    1    open/syncd    /new

#

# cd /new  à goto the /new FS

#

# ls -l

total 0

drwxr-xr-x   2 root     system          256 Apr 03 16:47 lost+found

#

# cd lost+found   à go to lost+found dir

#

# pwd

/new/lost+found

#

# ls -l

total 8

-rw-r–r–   1 root     system           68 Apr 03 16:49 4     à you can see the deleted file in the name of your inode number

#

# cat 4   à confirm the file content

Hi this is the test file. I want to use this file for recovery test

#

# mv 4 /new/.      à move the file to the exact place where it was before

#

# pwd

/new/lost+found

# cd ..

#

# pwd

/new

# ls -l

total 8

-rw-r–r–   1 root     system           68 Apr 03 16:49 4

drwxr-xr-x   2 root     system          256 Apr 03 16:55 lost+found

#

# cat 4

Hi this is the test file. I want to use this file for recovery test

#

# mv 4 film  à change the name of the recovered file to the old one.

#

# ls -l

total 8

-rw-r–r–   1 root     system           68 Apr 03 16:49 film   à the deleted file has been recovered.

drwxr-xr-x   2 root     system          256 Apr 03 16:55 lost+found

#

#

 

Raw vs JFS Logical Volumes I/O

Question

Does Virtual Memory Manager (VMM) work with raw logical updates, and if so, how?
If raw logical volumes do not use block I/O buffer cache, does sync update raw logical volumes or does VMM?

Answer

When an application directly accesses a raw logical volume, the VMM is not involved. The VMM is involved when accessing the Journaled File System (JFS).
sync only updates JFS, so neither sync nor VMM updates raw logical volumes. All writes to raw logical volumes are synchronous, which means that the writes do not return until the data has made it to disk and therefore does not require a sync.