[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.368 / U:2.144 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site