Hi Dave!
>
> Ah, there's a mismatch betwenteh man page and the implementation,
> then. The man page implies that "-n <num>" means query num extents
> at a time to map the entire file. It's implemented as "map the first
> <num> extents", though.
>
> You could try this:
>
> # xfs_io -f -c "fiemap -v" <file>
>
> Because fiemap loops doing getting a small number of extents at a
> time...
>
Ok, after i found out that fiemap is bleeding-edge (xfsprogs 3.1.5
doesn't support it) i compiled the latest git version of xfsprogs.
"fiemap -v" doesn't bail out on this file but continues to print extents
forever. I stopped it after the redirected output had already reached
90GiB and printed negative numbers. I guess it must have run into an
endless loop somewhere. xfs_bmap from the git version also throws
"Cannot allocate memory" at me.
# ./io/xfs_io -f -c "fiemap" /backup/tmp/cannot_allocate_memory.vhd >
/tmp/fiemap_output.txt
(Control-C)
# ls -lh /tmp/fiemap_output.txt
-rw-r--r-- 1 root root 90G 2011-07-05 15:06 /tmp/fiemap_output.txt
# tail -n10 /tmp/fiemap_output.txt
-1925931740: [599928..602239]: 399016..401327
-1925931739: [602240..603895]: hole
-1925931738: [603896..603903]: 2480..2487
-1925931737: [603904..606199]: hole
-1925931736: [606200..608127]: 366632..368559
-1925931735: [608128..1183]: hole
-1925931734: [1184..134279]: 444611744..444744839
-1925931733: [134280..134399]: hole
-1925931732: [134400..206495]: 433472688..433544783
-1925931731: [206496..210455]: hole
# ./io/xfs_io -f -c "bmap" /backup/tmp/cannot_allocate_memory.vhd
xfs_io: xfsctl(XFS_IOC_GETBMAPX) iflags=0x0
["/backup/tmp/cannot_allocate_memory.vhd"]: Cannot allocate memory
cheers,
Michael
|