[PATCH] reiserfs: Truncate blocks not used by a write (v2)

[PATCH] reiserfs: Truncate blocks not used by a write (v2)

[Jan Kara]

It can happen that write does not use all the blocks allocated in write_begin
either because of some filesystem error (like ENOSPC) or because page with
data to write has been removed from memory. We truncate these blocks so that
we don't have dangling blocks beyond i_size.

CC: reiserfs-devel@vger.kernel.org
CC: jeffm@suse.com
Signed-off-by: Jan Kara <jack@suse.cz>
---
 fs/reiserfs/inode.c |   11 ++++++++---
 1 files changed, 8 insertions(+), 3 deletions(-)

  Next try, this time without vmtruncate() as Christoph asked.

diff --git a/fs/reiserfs/inode.c b/fs/reiserfs/inode.c
index a14d6cd..a83280f 100644
--- a/fs/reiserfs/inode.c
+++ b/fs/reiserfs/inode.c
@@ -2597,6 +2597,8 @@ static int reiserfs_write_begin(struct file *file,
 	if (ret) {
 		unlock_page(page);
 		page_cache_release(page);
+		/* Truncate allocated blocks */
+		reiserfs_truncate_file(inode, 0);
 	}
 	return ret;
 }
@@ -2689,8 +2691,7 @@ static int reiserfs_write_end(struct file *file, struct address_space *mapping,
 	 ** transaction tracking stuff when the size changes.  So, we have
 	 ** to do the i_size updates here.
 	 */
-	pos += copied;
-	if (pos > inode->i_size) {
+	if (pos + copied > inode->i_size) {
 		struct reiserfs_transaction_handle myth;
 		reiserfs_write_lock(inode->i_sb);
 		/* If the file have grown beyond the border where it
@@ -2708,7 +2709,7 @@ static int reiserfs_write_end(struct file *file, struct address_space *mapping,
 			goto journal_error;
 		}
 		reiserfs_update_inode_transaction(inode);
-		inode->i_size = pos;
+		inode->i_size = pos + copied;
 		/*
 		 * this will just nest into our transaction.  It's important
 		 * to use mark_inode_dirty so the inode gets pushed around on the
@@ -2735,6 +2736,10 @@ static int reiserfs_write_end(struct file *file, struct address_space *mapping,
       out:
 	unlock_page(page);
 	page_cache_release(page);
+
+	if (pos + len > inode->i_size)
+		reiserfs_truncate_file(inode, 0);
+
 	return ret == 0 ? copied : ret;
 
       journal_error:
-- 
1.6.0.2

Re: [PATCH] reiserfs: Truncate blocks not used by a write (v2)

[Andrew Morton]

On Wed, 16 Sep 2009 19:25:12 +0200
Jan Kara <jack@suse.cz> wrote:

> It can happen that write does not use all the blocks allocated in write_begin
> either because of some filesystem error (like ENOSPC) or because page with
> data to write has been removed from memory. We truncate these blocks so that
> we don't have dangling blocks beyond i_size.

This clashes a bit with the kill-the-bkl/reiserfs stuff in linux-next.

Re: [PATCH] reiserfs: Truncate blocks not used by a write (v2)

[Frederic Weisbecker]

On Wed, Sep 16, 2009 at 02:48:15PM -0700, Andrew Morton wrote:
> On Wed, 16 Sep 2009 19:25:12 +0200
> Jan Kara <jack@suse.cz> wrote:
> 
> > It can happen that write does not use all the blocks allocated in write_begin
> > either because of some filesystem error (like ENOSPC) or because page with
> > data to write has been removed from memory. We truncate these blocks so that
> > we don't have dangling blocks beyond i_size.
> 
> This clashes a bit with the kill-the-bkl/reiserfs stuff in linux-next.


Note that the kill-the-bkl/reiserfs tree has suffered from too much
lock inversion problems lately. Even though I just fixed the last one
reported, I would feel more comfortable to schedule this tree for .33
rather than .32

So this tree can be removed from -next and reintegrated once -rc1 is
released, without problem.

So that if this patch is scheduled for .32, I can fix the conflict
myself once -rc1 is released and not burden Stephen with this conflict
which is useless to handle in -next for now.

Thanks.

Re: [PATCH] reiserfs: Truncate blocks not used by a write (v2)

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 690 bytes --]

Hi Frederic,

On Thu, 17 Sep 2009 02:56:34 +0200 Frederic Weisbecker <fweisbec@gmail.com> wrote:
>
> Note that the kill-the-bkl/reiserfs tree has suffered from too much
> lock inversion problems lately. Even though I just fixed the last one
> reported, I would feel more comfortable to schedule this tree for .33
> rather than .32
> 
> So this tree can be removed from -next and reintegrated once -rc1 is
> released, without problem.

OK, I have removed it from today.  Please let me know when it should be
readded (in case I forget - which at my age is likely :-)).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH] reiserfs: Truncate blocks not used by a write (v2)

[Frederic Weisbecker]

On Thu, Sep 17, 2009 at 11:56:29AM +1000, Stephen Rothwell wrote:
> Hi Frederic,
> 
> On Thu, 17 Sep 2009 02:56:34 +0200 Frederic Weisbecker <fweisbec@gmail.com> wrote:
> >
> > Note that the kill-the-bkl/reiserfs tree has suffered from too much
> > lock inversion problems lately. Even though I just fixed the last one
> > reported, I would feel more comfortable to schedule this tree for .33
> > rather than .32
> > 
> > So this tree can be removed from -next and reintegrated once -rc1 is
> > released, without problem.
> 
> OK, I have removed it from today.  Please let me know when it should be
> readded (in case I forget - which at my age is likely :-)).


Hi Stephen,

Now that -rc1 has been released (well.. -rc2, or..hmm...), could you please
reintegrate the tree:

git://git.kernel.org/pub/scm/linux/kernel/git/frederic/random-tracing.git
	reiserfs/kill-bkl

into -next ?

It is based on linux-2.6.31, I haven't merged 32-rc3 into
it because there is no conflict between those and there are no
dependencies against latest changes.

Tell me if you need something. It's possible there are pending
patches in reiserfs for .33 in -next which might conflict, I don't
know. But if you need help to fix the conflicts, just tell me.

Thanks!
	

Re: [PATCH] reiserfs: Truncate blocks not used by a write (v2)

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2354 bytes --]

Hi Frederic,

On Thu, 8 Oct 2009 14:48:24 +0200 Frederic Weisbecker <fweisbec@gmail.com> wrote:
>
> Now that -rc1 has been released (well.. -rc2, or..hmm...), could you please
> reintegrate the tree:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/frederic/random-tracing.git
> 	reiserfs/kill-bkl
> 
> into -next ?

Done.  (Boilerplate below in case you missed out last time.)

> It is based on linux-2.6.31, I haven't merged 32-rc3 into
> it because there is no conflict between those and there are no
> dependencies against latest changes.

That should be fine.

> Tell me if you need something. It's possible there are pending
> patches in reiserfs for .33 in -next which might conflict, I don't
> know. But if you need help to fix the conflicts, just tell me.

You will hear :-)

Thanks for adding your subsystem tree as a participant of linux-next.  As
you may know, this is not a judgment of your code.  The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window. 

You will need to ensure that the patches/commits in your tree/series have
been:
     * submitted under GPL v2 (or later) and include the Contributor's
	Signed-off-by,
     * posted to the relevant mailing list,
     * reviewed by you (or another maintainer of your subsystem tree),
     * successfully unit tested, and 
     * destined for the current or next Linux merge window.

Basically, this should be just what you would send to Linus (or ask him
to fetch).  It is allowed to be rebased if you deem it necessary.

-- 
Cheers,
Stephen Rothwell 
sfr@canb.auug.org.au

Legal Stuff:
By participating in linux-next, your subsystem tree contributions are
public and will be included in the linux-next trees.  You may be sent
e-mail messages indicating errors or other issues when the
patches/commits from your subsystem tree are merged and tested in
linux-next.  These messages may also be cross-posted to the linux-next
mailing list, the linux-kernel mailing list, etc.  The linux-next tree
project and IBM (my employer) make no warranties regarding the linux-next
project, the testing procedures, the results, the e-mails, etc.  If you
don't agree to these ground rules, let me know and I'll remove your tree
from participation in linux-next.

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]