search for: __ocfs2_extend_allocation

...5 EDT 2010 i686 i686 i386 GNU/Linux # rpm -qa | grep ocfs2 ocfs2-2.6.18-164.11.1.0.1.el5-1.4.4-1.el5 ocfs2-tools-1.4.3-1.el5 ocfs2-2.6.18-164.15.1.0.1.el5-1.4.4-1.el5 This is the latest from one of the alive hosts: # dmesg | tail -50 (2869,0):ocfs2_lock_allocators:677 ERROR: status = -5 (2869,0):__ocfs2_extend_allocation:739 ERROR: status = -5 (2869,0):ocfs2_extend_no_holes:952 ERROR: status = -5 (2869,0):ocfs2_expand_nonsparse_inode:1678 ERROR: status = -5 (2869,0):ocfs2_write_begin_nolock:1722 ERROR: status = -5 (2869,0):ocfs2_write_begin:1860 ERROR: status = -5 (2869,0):ocfs2_file_buffered_write:2039 ERROR: stat...

...Morton, The patch "[patch 05/22] ocfs2: lighten up allocate transaction" in mm tree is not the newest one, please drop it from mm tree. This patch V3 is newest, please replace it. Thanks. The issue scenario is as following: When fallocating a very large disk space for a small file, __ocfs2_extend_allocation attempts to get a very large transaction. For some journal sizes, there may be not enough room for this transaction, and the fallocate will fail. The patch below extents & restarts the transaction as necessary while allocating space, and should work with even the smallest journal. This patch...

jbd2_journal_restart() would restart a handle. In this function, it calls start_this_handle(). Before calling start_this_handle()?subtract 1 from transaction->t_updates. If start_this_handle() succeeds, transaction->t_updates increases by 1 in it. But if start_this_handle() fails, transaction->t_updates does not increase. So, when commit the handle's transaction in

Hi, This is the second batch of Ocfs2 patches intended for the merge window. The 1st batch were sent out previously: http://lkml.org/lkml/2008/12/19/280 The bulk of this set is comprised of Jan Kara's patches to add quota support to Ocfs2. Many of the quota patches are to generic code, which I carried to make merging of the Ocfs2 support easier. All of the non-ocfs2 patches should have