Bug 458765 - In linux-2.6.26 / 2.03.06, GFS1 can't create more than 4kb file.
Summary: In linux-2.6.26 / 2.03.06, GFS1 can't create more than 4kb file.
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: GFS-kernel
Version: 10
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Abhijith Das
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-08-12 05:41 UTC by kyung-pyo,kim
Modified: 2009-12-17 13:53 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-12-17 13:53:59 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description kyung-pyo,kim 2008-08-12 05:41:28 UTC
Description of problem:


Version-Release number of selected component (if applicable):
- linux-2.6.26 vanilla
- cluster-2.03.06
- openais-0.80.3
- LVM2.2.02.39
- device-mapper.1.02.27

How reproducible:
- Always

Steps to Reproduce:
1. mkfs.gfs -p lock_dlm -t alpha:test -j3 /dev/vg/lv
2. mount -t gfs /dev/vg/lv /gfs
3. dd if=/dev/zero of=/gfs/test_4KB bs=1k count=4
  
Actual results:
-rw-r--r--  1 root root    0 Aug 12 20:44 test_4KB

Expected results:
-rw-r--r--  1 root root   4k Aug 12 20:44 test_4KB

Additional info:
when df, disk usage is correct report. 
in linux-2.6.25.12 / 2.03.05, every thing ok.

Hardware info:
- Intel SR2500 server, Intel(R) Xeon(TM) CPU 3.00GHz daul
- 1GB Mem
- Qlogic 2300 HBA
- Silkworm SAN Switch
- Mylex Array

Comment 1 kyung-pyo,kim 2008-08-12 06:15:42 UTC
In brust dd io test, dd command returns ok.
When monitoring with iostat, i can't found data transfer io but some meta update io.

Comment 2 Robert Peterson 2008-08-13 17:09:55 UTC
The thing is, GFS is not part of the upstream kernel.  It's out-of-tree,
so we don't track the changes needed for upstream kernels as closely as
we could.  On the other hand, GFS2 is part of the upstream kernel, so
GFS2 is kept more in sync with upstream kernels.

I changed bz product to Fedora, since this is reported on an upstream
kernel.  I tested the scenario and it works under RHEL.  I'll try to
recreate the problem with an upstream kernel and debug it from there.

Comment 3 Abhijith Das 2008-10-13 20:55:56 UTC
This change from commit: http://git.fedorahosted.org/git/cluster.git?p=cluster.git;a=commitdiff;h=95a0ca2bd81ead2036ed609d71cb4c3e1e21960a is the culprit.

diff -Nupr a/gfs-kernel/src/gfs/ops_address.c b/gfs-kernel/src/gfs/ops_address.c
--- a/gfs-kernel/src/gfs/ops_address.c  2008-07-14 00:19:23.000000000 -0500
+++ b/gfs-kernel/src/gfs/ops_address.c  2008-08-01 04:24:09.000000000 -0500
@@ -404,7 +404,7 @@ gfs_commit_write(struct file *file, stru
                if (inode->i_size < file_size)
                        i_size_write(inode, file_size);
        } else {
-               error = generic_commit_write(file, page, from, to);
+               error = block_commit_write(page, from, to);
                if (error)
                        goto fail;
        }

generic_commit_write used to do this:

loff_t pos = ((loff_t)page->index << PAGE_CACHE_SHIFT) + to;
__block_commit_write(inode,page,from,to);
/*
 * No need to use i_size_read() here, the i_size
 * cannot change under us because we hold i_mutex.
 */
if (pos > inode->i_size) {
        i_size_write(inode, pos);
        mark_inode_dirty(inode);
}

By calling block_commit_write instead of generic_commit_write, we don't update the inode size although we write the data blocks to disk.

A simple fix is doing what generic_commit_write used to do around block_commit_write. i.e something like:

--- ops_address.c.orig	2008-10-13 15:51:00.000000000 -0500
+++ ops_address.c	2008-10-13 15:52:12.000000000 -0500
@@ -404,9 +404,14 @@ gfs_commit_write(struct file *file, stru
 		if (inode->i_size < file_size)
 			i_size_write(inode, file_size);
 	} else {
+		loff_t pos = ((loff_t)page->index << PAGE_CACHE_SHIFT) + to;
 		error = block_commit_write(page, from, to);
 		if (error)
 			goto fail;
+		if (pos > inode->i_size) {
+			i_size_write(inode, pos);
+			mark_inode_dirty(inode);
+		}
 	}
 
 	ip->gfs_file_aops.commit_write = NULL;

I'll look at other fses to see if there's a better way to do it, otherwise we'll have to do the above.

Comment 4 Frederik Schueler 2008-10-14 10:42:45 UTC
Hi!

I digged around in linux-2.6 and found the following:

one year ago, new aops where introduced, and the obsoleted function was removed in .26. A commit for ext3 for example is changeset f4fc66a894546bdc88a775d0e83ad20a65210bcb

others can be found here:

http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git&a=search&h=HEAD&st=commit&s=new+aops

basically, generic_commit_write has to be replaced with generic_write_end not with generic_block_write.

Best regards
Frederik Schüler

Comment 5 Frederik Schueler 2008-10-14 11:53:22 UTC
Hi,

the gfs2 changeset in linux-2.6 is 7765ec26ae1c01bb29bedf910e4efcced8cc81d2

best regards
Frederik Schüler

Comment 6 Abhijith Das 2008-10-20 05:25:52 UTC
Checked in the workaround in comment #3 to STABLE2 and master until we fix it the right way and use write_begin/write_end instead of the prepare_write/commit_write interface we currently use.

Comment 7 Bug Zapper 2008-11-26 02:44:47 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 8 Abhijith Das 2009-05-15 15:19:10 UTC
GFS2 has been using the write_begin/write_end interface for sometime now. Marking this bug modified.

Comment 9 Bug Zapper 2009-11-18 07:53:48 UTC
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping


Note You need to log in before you can comment on or make changes to this bug.