On 04/06/15 09:42, Steven Whitehouse wrote:
Hi,
Will glibc do the fallback path, or just return this as an error? I
think thats worth checking as it would be nice it it would transparently
fall back in this case,
You only get the fallback with posix_fallocate() but many applications
will use fallocate() directly for various reasons¹.
On 03/06/15 22:30, Abhi Das wrote:
We cannot provide an efficient implementation due to the headers
on the data blocks, so there doesn't seem much point in having it.
I'm not sure I like the idea that fallocate() could work in one
directory and fail in another... What exactly is the issue here? Is it
just the journal space required or that writing the data block headers
would be too slow?
Andy
¹ https://sourceware.org/bugzilla/show_bug.cgi?id=15661
Resolves: rhbz#1221331
Signed-off-by: Abhi Das <a...@redhat.com>
---
fs/gfs2/file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/gfs2/file.c b/fs/gfs2/file.c
index c706c6d..8252115 100644
--- a/fs/gfs2/file.c
+++ b/fs/gfs2/file.c
@@ -917,7 +917,7 @@ static long gfs2_fallocate(struct file *file, int
mode, loff_t offset, loff_t le
struct gfs2_holder gh;
int ret;
- if (mode & ~FALLOC_FL_KEEP_SIZE)
+ if ((mode & ~FALLOC_FL_KEEP_SIZE) || gfs2_is_jdata(ip))
return -EOPNOTSUPP;
mutex_lock(&inode->i_mutex);
