25 Mar, 2015

1 commit

  • FALLOC_FL_INSERT_RANGE command is the opposite command of
    FALLOC_FL_COLLAPSE_RANGE that is needed for someone who wants to add
    some data in the middle of file.

    FALLOC_FL_INSERT_RANGE will create space for writing new data within
    a file after shifting extents to right as given length. This command
    also has same limitations as FALLOC_FL_COLLAPSE_RANGE in that
    operations need to be filesystem block boundary aligned and cannot
    cross the current EOF.

    Signed-off-by: Namjae Jeon
    Signed-off-by: Ashish Sangwan
    Reviewed-by: Dave Chinner
    Signed-off-by: Dave Chinner

    Namjae Jeon
     

13 Oct, 2012

1 commit


27 Sep, 2012

1 commit


13 Jan, 2011

1 commit

  • Hole punching has already been implemented by XFS and OCFS2, and has the
    potential to be implemented on both BTRFS and EXT4 so we need a generic way to
    get to this feature. The simplest way in my mind is to add FALLOC_FL_PUNCH_HOLE
    to fallocate() since it already looks like the normal fallocate() operation.
    I've tested this patch with XFS and BTRFS to make sure XFS did what it's
    supposed to do and that BTRFS failed like it was supposed to. Thank you,

    Signed-off-by: Josef Bacik
    Signed-off-by: Al Viro

    Josef Bacik
     

24 Jun, 2009

1 commit


18 Jul, 2007

1 commit

  • fallocate() is a new system call being proposed here which will allow
    applications to preallocate space to any file(s) in a file system.
    Each file system implementation that wants to use this feature will need
    to support an inode operation called ->fallocate().
    Applications can use this feature to avoid fragmentation to certain
    level and thus get faster access speed. With preallocation, applications
    also get a guarantee of space for particular file(s) - even if later the
    the system becomes full.

    Currently, glibc provides an interface called posix_fallocate() which
    can be used for similar cause. Though this has the advantage of working
    on all file systems, but it is quite slow (since it writes zeroes to
    each block that has to be preallocated). Without a doubt, file systems
    can do this more efficiently within the kernel, by implementing
    the proposed fallocate() system call. It is expected that
    posix_fallocate() will be modified to call this new system call first
    and incase the kernel/filesystem does not implement it, it should fall
    back to the current implementation of writing zeroes to the new blocks.
    ToDos:
    1. Implementation on other architectures (other than i386, x86_64,
    and ppc). Patches for s390(x) and ia64 are already available from
    previous posts, but it was decided that they should be added later
    once fallocate is in the mainline. Hence not including those patches
    in this take.
    2. Changes to glibc,
    a) to support fallocate() system call
    b) to make posix_fallocate() and posix_fallocate64() call fallocate()

    Signed-off-by: Amit Arora

    Amit Arora