Hi List! I've got a file here on which i cannot use xfs_bmap to determine it's fragments. All that i know is that it must have a really great number of them. It was the result of running a smbd without strict allocate. The machine itself has 8GiB of RAM and 10GiB of swap available, so that shouldn't be the problem. I guess this is some bug in xfs_bmap. Or is it a known limitation? # xfs_bmap /backup/tmp/cannot_allocate_memory.vhd xfs_bmap: xfsctl(XFS_IOC_GETBMAPX) iflags=0x0 ["/backup/tmp/cannot_allocate_memory.vhd"]: Cannot allocate memory Another thing i noticed is that when i use the filefrag utility it reports a different fragment count when invoked with -v than without it, which i found pretty strange too. From that output i judge that the real count is 62715, which is also not in sync with 45487. # filefrag /backup/tmp/cannot_allocate_memory.vhd /backup/tmp/cannot_allocate_memory.vhd: 1364 extents found # filefrag -v /backup/tmp/cannot_allocate_memory.vhd | tail -n5 62711 43265805 57280748 57265654 17 62712 43266061 57265655 57280764 1 62713 43266317 57396971 57265655 17 62714 43266573 57265656 57396987 1 eof /backup/tmp/cannot_allocate_memory.vhd: 45487 extents found Other than that everything works perfectly well and xfs_repair doesn't report any problems with the filesystem. So it's only a "cosmetical" issue. Thanks for any hints, Michael _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
