|
Description
|
bmap_set_bn() does not bother about second level indirection causing freeing free and UFS_HOLE panic left and right. If you happen to use fallocate feature in UFS which is present in snv_29+, you will notice some strange panics (UFS_HOLE or freeing free block panic) when file size is over 2060 blocks. It's because bmap_set_bn() does not work well with second level of indirection. For example :-
/dev/rdsk/c1t1d0s6 > :inode
i#: 4 md: ---trw------- uid: 0 gid: 0
ln: 1 bs: 8830 sz : c_flags : 0 1100000
db#0: 64d0 db#1: 64d8 db#2: 64e0 db#3: 64e8
db#4: 64f0 db#5: 64f8 db#6: 6500 db#7: 6508
db#8: 6510 db#9: 6518 db#a: 6520 db#b: 6528
ib#0: c388 ib#1: c008
accessed: Fri Nov 3 12:05:03 2006
modified: Fri Nov 3 12:05:03 2006
created : Fri Nov 3 12:05:03 2006
/dev/rdsk/c1t1d0s6 > 1:ib:block,800/X
3002000: 0000c048 00000000 00000000 00000000
*
3003ff0: 00000000 00000000 00000000 00000000
Nothing there when the file is really huge. The correct blocks are :-
/dev/rdsk/c1t1d0s6 > 0xc048:block,800/X
3012000: 00018008 00018010 00018018 00018020
3012010: 00018028 00018030 00018038 00018040
3012020: 00018088 00018050 00018058 00018060
3012030: 00018068 00018070 00018078 00018080
So if you happen to write to the file the blk number will not be set properly. We need an assignment 'nb = bap[i];' in the for loop which fetches through the indirect blocks.
|
