Skip to content

L
linux-davinci
Switch branch/tag
  1. 18 Dec, 2009 2 commits
    • Tao Ma's avatar
      ocfs2: Set i_nlink properly during reflink. · 10cf1a02
      Tao Ma authored 
      We create a file in orphan dir for reflink so that if there
is any error, we don't create any wrong dentry in the dir.
But actually the file in orphan dir should be i_nlink = 0
so that it can be replayed and freed successfully.

This patch first set i_nlink to 0 when creating the file in
orphan dir and then set it to 1(reflink now only works for
regular file) when we move it to the dest dir.
Signed-off-by: default avatarTao Ma <tao.ma@oracle.com>
Signed-off-by: default avatarJoel Becker <joel.becker@oracle.com>
      10cf1a02
    • Tao Ma's avatar
      ocfs2: Add reflinked file's inode to inode hash eariler. · c7d260af
      Tao Ma authored 
      We used to add reflinked file's inode to inode hash when
we add it to the dest dir. But actually there is a race.
Consider the following sequence.
1. reflink happens and create the inode in orphan dir.
2. reflink thread is scheduled out because of some io.
3. recovery begins to work and calls ocfs2_recover_orphans.
   It calls ocfs2_iget and get a new inode and i_count = 1.
   It calls iput then and delete inode. the buffer's
   uptodate state is cleared.

This patch move insert_inode_hash to the create function so
that it can be found by step 3 and prevented from deleting
because i_count > 1.

This resolves the bug
http://oss.oracle.com/bugzilla/show_bug.cgi?id=1183.
Signed-off-by: default avatarTao Ma <tao.ma@oracle.com>
Signed-off-by: default avatarJoel Becker <joel.becker@oracle.com>
      c7d260af
  3. 03 Dec, 2009 2 commits
    • Tao Ma's avatar
      ocfs2: refcounttree.c cleanup. · 12d4cec9
      Tao Ma authored 
      sparse check finds some endian problem and some other minor issues.
There is an obsolete function which should be removed.
So this patch resolve all these.
Signed-off-by: default avatarTao Ma <tao.ma@oracle.com>
Signed-off-by: default avatarJoel Becker <joel.becker@oracle.com>
      12d4cec9
    • Tao Ma's avatar
      ocfs2: Find proper end cpos for a leaf refcount block. · 38a04e43
      Tao Ma authored 
      ocfs2 refcount tree is stored as an extent tree while
the leaf ocfs2_refcount_rec points to a refcount block.

The following step can trip a kernel panic.
mkfs.ocfs2 -b 512 -C 1M --fs-features=refcount $DEVICE
mount -t ocfs2 $DEVICE $MNT_DIR
FILE_NAME=$RANDOM
FILE_NAME_1=$RANDOM
FILE_REF="${FILE_NAME}_ref"
FILE_REF_1="${FILE_NAME}_ref_1"
for((i=0;i<305;i++))
do
# /mnt/1048576 is a file with 1048576 sizes.
cat /mnt/1048576 >> $MNT_DIR/$FILE_NAME
cat /mnt/1048576 >> $MNT_DIR/$FILE_NAME_1
done
for((i=0;i<3;i++))
do
cat /mnt/1048576 >> $MNT_DIR/$FILE_NAME
done

for((i=0;i<2;i++))
do
cat /mnt/1048576 >> $MNT_DIR/$FILE_NAME
cat /mnt/1048576 >> $MNT_DIR/$FILE_NAME_1
done

cat /mnt/1048576 >> $MNT_DIR/$FILE_NAME

for((i=0;i<11;i++))
do
cat /mnt/1048576 >> $MNT_DIR/$FILE_NAME
cat /mnt/1048576 >> $MNT_DIR/$FILE_NAME_1
done
reflink $MNT_DIR/$FILE_NAME $MNT_DIR/$FILE_REF
# write_f is a program which will write some bytes to a file at offset.
# write_f -f file_name -l offset -w write_bytes.
./write_f -f $MNT_DIR/$FILE_REF -l $[310*1048576] -w 4096
./write_f -f $MNT_DIR/$FILE_REF -l $[306*1048576] -w 4096
./write_f -f $MNT_DIR/$FILE_REF -l $[311*1048576] -w 4096
./write_f -f $MNT_DIR/$FILE_NAME -l $[310*1048576] -w 4096
./write_f -f $MNT_DIR/$FILE_NAME -l $[311*1048576] -w 4096
reflink $MNT_DIR/$FILE_NAME $MNT_DIR/$FILE_REF_1
./write_f -f $MNT_DIR/$FILE_NAME -l $[311*1048576] -w 4096
#kernel panic here.

The reason is that if the ocfs2_extent_rec is the last record
in a leaf extent block, the old solution fails to find the
suitable end cpos. So this patch try to walk through the b-tree,
find the next sub root and get the c_pos the next sub-tree starts
from.

btw, I have runned tristan's test case against the patched kernel
for several days and this type of kernel panic never happens again.
Signed-off-by: default avatarTao Ma <tao.ma@oracle.com>
Signed-off-by: default avatarJoel Becker <joel.becker@oracle.com>
      38a04e43
  5. 02 Dec, 2009 24 commits
  7. 01 Dec, 2009 12 commits