[lkml]   [2007]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] Heads up on sys_fallocate()
    On Sun, 4 March 2007 14:38:13 -0800, Ulrich Drepper wrote:
    > When you do it like this, who can the kernel/filesystem *guarantee* that
    > when the data is written there actually is room on the harddrive?
    > What you described seems like using truncate/ftruncate to increase the
    > file's size. That is not at all what posix_fallocate is for.
    > posix_fallocate must make sure that the requested blocks on the disk are
    > reserved (allocated) for the file's use and that at no point in the
    > future will, say, a msync() fail because a mmap(MAP_SHARED) page has
    > been written to.

    That actually causes an interesting problem for compressing filesystems.
    The space consumed by blocks depends on their contents and how well it
    compresses. At the moment, the only option I see to support
    posix_fallocate for LogFS is to set an inode flag disabling compression,
    then allocate the blocks.

    But if the file already contains large amounts of compressed data, I
    have a problem. Disabling compression for a range within a file is not
    supported, so I can only return an error. But which one?


    A surrounded army must be given a way out.
    -- Sun Tzu
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-03-05 03:07    [W:0.020 / U:25.280 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site