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? Jörn -- A surrounded army must be given a way out. -- Sun Tzu - To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
