Hi, On Mon, 2008-03-10 at 16:08 +0800, chenzp wrote: > hi all: > > I have 2 nodes node1 and node2,use kernel 2.6.22.15. . > the two node use clustat command display is ok. > in now create volume and use lock_dlm mode mkfs.gf2.( mkfs.gfs2 > -p lock_dlm -t uitcluster:gfs2 -j 8 /dev/vg-test/lv-test ) and > then > mount. (mount.gfs2 /dev/vg-test/lv-test /mnt/gfs2 ) > user dd write file in node1( dd if=/dev/zero > of=/mnt/gfs2/$(hostname).1 bs=1M count=1024 ),when write finish,check > file in node2 is > ok! > > but if delete node1.1 file in node2 ( rm -rf /mnt/gfs2node1.1) > and then use ls -l /mnt/gfs2 no file;and use ll -h /mnt/gfs2/ no file > the size > is 0; and then use df -h check , the used no any change;the > Space no free. > > my mean is: if you use node1 write file and then use node2 delete > node1 write file,and then use df -h check disk,the space no free; > if you use node1 write file and then use node1 delete node1 write > file this is ok. > > > > carry.chen > This is a bug from a while back. I suspect that if you do a drop caches then the space will magically reappear. If you use a more recent kernel, then this bug should also not occur. What is happening is that the dcache on one machine has kept the inode in cache even when another node has unlinked the inode because it hasn't seen the link count hit zero. The fix in more recent kernels results in the dentry for an unlinked inode being flushed cluster wide. Once the final iput has occurred, then the space is released to the filesystem. Steve. -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
