On Sun, Sep 22, 2013 at 04:25:15PM +0800, Jeff Liu wrote: > From: Jie Liu <jeff.liu@xxxxxxxxxx> > > At xfs_iext_realloc_direct(), the new_size is changed by adding > if_bytes if originally the extent records are stored at the inline > extent buffer, and we have to switch from it to a direct extent > list for those new allocated extents, this is wrong. e.g, > > Create a file with three extents which was showing as following, > > xfs_io -f -c "truncate 100m" /xfs/testme > > for i in $(seq 0 5 10); do > offset=$(($i * $((1 << 20)))) > xfs_io -c "pwrite $offset 1m" /xfs/testme > done > > Inline > ------ > irec: if_bytes bytes_diff new_size > 1st 0 16 16 > 2nd 16 16 32 > > Switching > --------- rnew_size > 3rd 32 16 48 + 32 = 80 roundup=128 > > In this case, the desired value of new_size should be 48, and then > it will be roundup to 64 and be assigned to rnew_size. Ok, so it allocates 128 bytes instead of 64 bytes. It tracks that allocation size correctly ifp->if_real_bytes, and all it means is that there are 4 empty extra slots in the extent array. The code already handles having empty slots in the direct extent array, so what impact is there as a result of the oversized initial allocation that is currently happening? i.e. if fixing the oversized results in more memory allocations due to resizing more regularly, then is there a benefit to changing this code given that the rewrite of the ifp->if_bytes value in the case where we do inline->direct conversion prevents this over-allocation from being a problem... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
