From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Price Date: Thu, 04 Jun 2015 11:27:59 +0100 Subject: [Cluster-devel] [GFS2 PATCH] gfs2: Don't support fallocate on jdata files In-Reply-To: <55700F8D.3050500@redhat.com> References: <1433367046-65230-1-git-send-email-adas@redhat.com> <55700F8D.3050500@redhat.com> Message-ID: <5570282F.3010500@redhat.com> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 >> --- >> 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); >