Re: [PATCH 4/7][TAKE5] support new modes in fallocate
From: David Chinner <hidden>
Date: 2007-06-26 23:32:53
Also in:
linux-fsdevel, linux-xfs, lkml
On Tue, Jun 26, 2007 at 11:42:50AM -0400, Andreas Dilger wrote:
On Jun 26, 2007 16:15 +0530, Amit K. Arora wrote:quoted
On Mon, Jun 25, 2007 at 03:52:39PM -0600, Andreas Dilger wrote:quoted
In XFS one of the (many) ALLOC modes is to zero existing data on allocate. For ext4 all this would mean is calling ext4_ext_mark_uninitialized() on each extent. For some workloads this would be much faster than truncate and reallocate of all the blocks in a file.In ext4, we already mark each extent having preallocated blocks as uninitialized. This is done as part of following code (which is part of patch 5/7) in ext4_ext_get_blocks() :What I meant is that with XFS_IOC_ALLOCSP the previously-written data is ZEROED OUT, unlike with fallocate() which leaves previously-written data alone and only allocates in holes. So, if you had a sparse file with some data in it: AAAAA BBBBBB fallocate() would allocate the holes: 00000AAAAA000000000BBBBBB00000000 XFS_IOC_ALLOCSP would overwrite everything: 000000000000000000000000000000000
No, it wouldn't. XFS_IOC_ALLOCSP would give you:
AAAAA BBBBBB00000000
because it only allocates the space between the old EOF and the new
EOF. Graphic demonstration - write 4k @ 4k, 4k @ 16k, allocsp out to 32k:
budgie:~ # xfs_io -f \-c "pwrite 4096 4096" \ -c "pwrite 16384 4096" \ -c "bmap -vvp" \ -c "allocsp 32768 0" \ -c "bmap -vvp" \ /mnt/test/alfred
wrote 4096/4096 bytes at offset 4096 4 KiB, 1 ops; 0.0000 sec (108.507 MiB/sec and 27777.7778 ops/sec) wrote 4096/4096 bytes at offset 16384 4 KiB, 1 ops; 0.0000 sec (260.417 MiB/sec and 66666.6667 ops/sec) /mnt/test/alfred: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL 0: [0..7]: hole 8 1: [8..15]: 5226864..5226871 4 (1022160..1022167) 8 2: [16..31]: hole 16 3: [32..39]: 5226888..5226895 4 (1022184..1022191) 8 /mnt/test/alfred: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL 0: [0..7]: hole 8 1: [8..15]: 5226864..5226871 4 (1022160..1022167) 8 2: [16..31]: hole 16 3: [32..63]: 5226888..5226919 4 (1022184..1022215) 32 budgie:~ # Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group