possible bug with non-default extent sizes

possible bug with non-default extent sizes

[Iustin Pop]

Hi,

I've seen a strange behaviour related to sparse files with non-default
extent sizes and I'm not sure if it's a bug or expected behaviour
(certainly I was not expecting it).

cd $TMPDIR
/usr/sbin/xfs_io -c "extsize 16k" .
python <<EOF
f = open("test", "w+")
f.truncate(1024*64)
f.write("A")
f.close()
EOF

what I see if I look at the file now with od for example, is that the
first filesystem block contains "A" and then zeroes, but after the 4k
offset the file contains stale data from the disk.

This doesn't happen for all values of extsize and the file size. What
I've seen that for an extent size N, file size bigger than 2*N very
often result in stale data. Many times, even a file bigger than two
blocks (8k) will show stale data too.

I haven't found any bug related to this, and I would not expect stale
data (since this is doable even by normal users, and maybe could leak
old data).

Is this a known issue?

thanks,
iustin

Re: possible bug with non-default extent sizes

[David Chinner]

On Tue, Sep 18, 2007 at 08:33:08PM +0200, Iustin Pop wrote:
> Hi,
> 
> I've seen a strange behaviour related to sparse files with non-default
> extent sizes and I'm not sure if it's a bug or expected behaviour
> (certainly I was not expecting it).
> 
> cd $TMPDIR
> /usr/sbin/xfs_io -c "extsize 16k" .
> python <<EOF
> f = open("test", "w+")
> f.truncate(1024*64)
> f.write("A")
> f.close()
> EOF

FWIW:

/usr/sbin/xfs_io -f \
	-c "extsize 16k" \
	-c "truncate 64k" \
	-c "pwrite 0 4k" \
	-c "bmap -vp" \
	$TMPDIR/test

Is my usual way of writing these quick sort of tests.

> what I see if I look at the file now with od for example, is that the
> first filesystem block contains "A" and then zeroes, but after the 4k
> offset the file contains stale data from the disk.

Yeah, there's a bug there that I've been trying to work out the
best way to fix - basically the delalloc is supposed to convert
the extent size to 4k of written data and 12k of unwritten data,
but the unwritten flag is not getting set on the unwritten
section. and so we are allocating 16k when we are only writing to
4k.

> I haven't found any bug related to this, and I would not expect stale
> data (since this is doable even by normal users, and maybe could leak
> old data).
> 
> Is this a known issue?

Yes - it was discovered a few months back amongst a raft of other
issues similar to this. This is the only one I know of that I
haven't fixed yet - I've had a couple of attempts and they drowned
in complexity. I'll have another look at it seeing as I have a
better understanding of what is supposed to happen since I last
tried to fix it....

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group