[Bug 785] xfs_io doesn't correctly reallocate struct getbmapx in bmap_f

[bugzilla-daemon@xxxxxxxxxxx]

http://oss.sgi.com/bugzilla/show_bug.cgi?id=785





--- Comment #4 from Tomasz Majkowski <moosh009@xxxxxxxxx>  2009-03-18 10:17:54 
CST ---
The code I looked at doesn't work correctly for files that have between 16 and
29 'holes'.

The code I looked at was from xfsprogs-2.6.25.src.tar.bz2 found inside the
xfsprogs-2.6.25-0.6.src.rpm from SLES9 sp2 i386 distribution.

Machine info (SLES9 sp2):
> uname -a
Linux blahblah 2.6.5-7.191-default #1 Tue Jun 28 14:58:56 UTC 2005 i686 athlon
i386 GNU/Linux

> xfs_info /space
meta-data=/space                 isize=256    agcount=16, agsize=311384 blks
         =                       sectsz=512
data     =                       bsize=4096   blocks=4982144, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=1
naming   =version 2              bsize=4096
log      =internal               bsize=4096   blocks=2560, version=1
         =                       sectsz=512   sunit=0 blks
realtime =none                   extsz=65536  blocks=0, rtextents=0


See below for how I reproduce this:
> cat hole.c
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>

#define SEEKBY (0x100000)

int main(int argc, char *argv[])
{
        int fd, holes, i;


        holes = 10;
        switch(argc) {
                case 2:
                        holes = atoi(argv[1]);
                default:
                        break;
        }

        fd = open("hole_file", O_CREAT | O_WRONLY, 0644);
        for (i = 0; i < holes; i++) {
                write(fd, "1", 1);
                lseek(fd, SEEKBY - 1, SEEK_CUR);
        }
        write(fd, "1", 1);
        close(fd);

        return (0);
}

> cat genfiles
#/bin/bash

for i in 10 14 15 16 17 28 29 30 31; do
        rm -f hole_file
        ./hole ${i}
        mv hole_file hole_file${i}
done

> cat runfiles
#/bin/bash

for i in 10 14 15 16 17 28 29 30 31; do
        xfs_bmap -v hole_file${i} > r${i}
done

> cat runfiles2
#/bin/bash

for i in 10 14 15 16 17 28 29 30 31; do
        ./io/xfs_io -r -p xfs_bmap -c "bmap -v" hole_file${i} > t${i}
done

> gcc hole.c -o hole
> ./genfiles
> ./runfiles


Now look in the r?? files and notice that files
hole_file15
hole_file16
hole_file17
hole_file28
hole_file29

All show to have 15 'holes' which is not correct they have 15, 16, 17, 28, 29
respectively

Now apply my patch and re-run.  See the results.

The problem is that fsx.fsx_nextents is not the same as the number of entries
required in struct getbmapx to represent that file.
Eg: a file with 1 hole (ie data, hole, data) will have fsx.fsx_nextents=2, 1
'hole' and needs 3 entries in struct getbmapx to represent it correctly.

Perhaps my patch is also not correct, but it appears more correct that the
original.

-- 
Configure bugmail: http://oss.sgi.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.