lkml.org 
[lkml]   [2007]   [Jun]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 4/7][TAKE5] support new modes in fallocate
    On Tue, Jun 26, 2007 at 11:42:50AM -0400, Andreas Dilger wrote:
    > On Jun 26, 2007 16:15 +0530, Amit K. Arora wrote:
    > > On Mon, Jun 25, 2007 at 03:52:39PM -0600, Andreas Dilger wrote:
    > > > 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
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-06-27 01:37    [W:7.429 / U:0.000 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site