On 10/04/2012 04:17 AM, Alexander 'Leo' Bergolth wrote: > Hi! > > I am trying to create a sparse qemu qcow2 image on xfs. (Centos 6.3) > Unfortunately this doesn't produce the expected results: > Creating a 10G file results in 16GB of disk usage! > Doing the same on ext4 produces a 10G sparse file with only 1.8M allocated... > (See the block bitmaps below.) > > Is this related to dynamic speculative preallocation? > http://serverfault.com/questions/406069/why-are-my-xfs-filesystems-suddenly-consuming-more-space-and-full-of-sparse-file > It appears so. I suspect a part of that 16GB is eventually trimmed as it extends past the end of the file (and if I added correctly, the bmap output below shows around 9GB, which is what I reproduce as well). Basically for each write that extends the size of the file, XFS preallocates a certain number of blocks depending on the current file size. It starts out small and as the file size gets larger, this preallocation gets larger as well (up to 8GB). If the next write after a prealloc happens to occur after a seek into or past the preallocated space, that space becomes permanent. It looks like we have to zero said space as well, to ensure stale data is not exposed from the block device, which I think accounts for the extra time this command requires as well. > Are there any recommended filesystem options that optimize xfs behavior for hosting (sparse) virtual disk images? > As the link you posted notes, you can use the allocsize=X option to curb this behavior. E.g., when using allocsize=64k I see equivalent behavior on XFS as you have reported for ext4. Brian > Cheers, > --leo > > -------------------- 8< -------------------- > $ qemu-img create -f qcow2 -o 'preallocation=metadata' onxfs.img 10G > Formatting 'onxfs.img', fmt=qcow2 size=10737418240 encryption=off cluster_size=65536 preallocation='metadata' > $ du -hs onxfs.img 16G onxfs.img > > $ ls -ls onxfs.img 16253692 -rw-r--r-- 1 leo users 10739318784 Oct 2 14:22 onxfs.img > > # xfs_bmap -v onxfs.img onxfs.img: > EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL > 0: [0..1023]: 168294344..168295367 3 (11007944..11008967) 1024 > 1: [1024..1049215]: hole 1048192 > 2: [1049216..1049727]: 168295368..168295879 3 (11008968..11009479) 512 > 3: [1049728..2097919]: hole 1048192 > 4: [2097920..3146495]: 165668600..166717175 3 (8382200..9430775) 1048576 > 5: [3146496..3146623]: hole 128 > 6: [3146624..5243775]: 163571448..165668599 3 (6285048..8382199) 2097152 > 7: [5243776..5244159]: hole 384 > 8: [5244160..9438463]: 159377144..163571447 3 (2090744..6285047) 4194304 > 9: [9438464..9439103]: hole 640 > 10: [9439104..17827711]: 52616968..61005575 1 (188168..8576775) 8388608 > 11: [17827712..17828991]: hole 1280 > 12: [17828992..20975231]: 105886128..109032367 2 (1028528..4174767) 3146240 > > # xfs_info /srv > meta-data=/dev/mapper/vg_1-lv_srv isize=256 agcount=4, agsize=6553600 blks > = sectsz=512 attr=2 > data = bsize=4096 blocks=26214400, imaxpct=25 > = sunit=0 swidth=0 blks > naming =version 2 bsize=4096 ascii-ci=0 > log =internal bsize=4096 blocks=12800, version=2 > = sectsz=512 sunit=0 blks, lazy-count=1 > realtime =none extsz=4096 blocks=0, rtextents=0 > > -------------------- 8< -------------------- > $ qemu-img create -f qcow2 -o 'preallocation=metadata' onext4.img 10G > Formatting 'onext4.img', fmt=qcow2 size=10737418240 encryption=off cluster_size=65536 preallocation='metadata' > $ du -h onext4.img 1.8M onext4.img > > $ ls -ls onext4.img 1744 -rw-r--r-- 1 leo users 10739318784 Oct 2 14:25 onext4.img > > debugfs: stat /leo/onext4.img > Inode: 1048578 Type: regular Mode: 0644 Flags: 0x80000 > Generation: 3370152928 Version: 0x00000000:00000001 > User: 501 Group: 100 Size: 10739318784 > File ACL: 0 Directory ACL: 0 > Links: 1 Blockcount: 3488 > Fragment: Address: 0 Number: 0 Size: 0 > ctime: 0x506add38:7909fe14 -- Tue Oct 2 14:25:28 2012 > atime: 0x506add38:731c2ccc -- Tue Oct 2 14:25:28 2012 > mtime: 0x506add38:7909fe14 -- Tue Oct 2 14:25:28 2012 > crtime: 0x506add36:5320b76c -- Tue Oct 2 14:25:26 2012 > Size of extra inode fields: 28 > EXTENTS: > (0): 33856, (16): 33872, (32-79): 33888-33935, (131152-131167): 34896-34911, (262240-262255): 36960-36975, (393328-393343): 39024-39039, (524416-524447): 41088-41119, (655520-655535): 43168-43183, (786608-786623): 45232-45247, (917696-917711): 47296-47311, (1048784-1048815) > : 49360-49391, (1179888-1179903): 51440-51455, (1310976-1310991): 53504-53519, (1442064-1442079): 55568-55583, (1573152-1573183): 57632-5 > 7663, (1704256-1704271): 59712-59727, (1835344-1835359): 61776-61791, (1966432-1966447): 63840-63855, (2097520-2097551): 65904-65935, (22 > 28624-2228639): 67984-67999, (2359712-2359727): 70048-70063, (2490800-2490815): 72112-72127, (2621887-2621903): 74175-74191 > > _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
