public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Suzuki <suzuki@in.ibm.com>
To: Andrew Morton <akpm@osdl.org>
Cc: amitarora@in.ibm.com, "Vladimir V. Saveliev" <vs@namesys.com>,
	reiserfs-list@namesys.com, reiserfs-dev@namesys.com,
	lkml <linux-kernel@vger.kernel.org>,
	rdunlap@xenotime.net
Subject: Re: [BUG] Reiserfs panic while running fsstress due to multiple truncate "safe links" for a file.
Date: Mon, 27 Nov 2006 15:37:49 -0800	[thread overview]
Message-ID: <456B76CD.5000600@in.ibm.com> (raw)
In-Reply-To: <20060730161348.94ecc5e0.akpm@osdl.org>

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

Andrew Morton wrote:
> On Mon, 08 May 2006 17:03:41 +0530
> Suzuki <suzuki@in.ibm.com> wrote:
> 
> 
>>Resending, since there were no responses to the earlier post.
>>
>>Hi,
>>
>>
>>I was working on a reiserfs panic with 2.6.17-rc3, while running fs
>>stress tests.
>>
>>The panic message looked like :
>>
>>" REISERFS: panic (device Null superblock): reiserfs[4248]: assertion
>>!(truncate && (REISERFS_I(inode)->i_flags & i_link_saved_truncate_mask)
>>) failed at fs/reiserfs/super.c:328:add_save_link: saved link already re
>>exists for truncated inode 13b5a "
>>
>>------ Summary of the problem -----------
>>
>>Reiserfs uses "safe links" ( directory entries with some special key
>>value) to keep track of "truncated" or "unlinked" files to ensure
>>integrity across crashes.
>>
>>Whenever there is a truncate/unlink on a file, Reiserfs creates a safe
>>link for the same and deletes the same once the operation is complete.
>>If the machine crashes before committing the operation, whenever the fs
>>is mounted next time, the fs will look for the saved links ( easy to
>>find out, since they have special key) and commit the operation that was
>>unfinished.
>>
>>
>>The problem here occurs as follows:
>>
>>  Whenever there is an extending DIO write operation, the fs would
>>create a safe link so as to ensure the file size consistent, if there is
>>crash in between the DIO. This will be deleted once the write operation
>>finishes.
>>
>>  If the DIO write happens to go through a "HOLE" region in the file, it
>>will fall into normal "buffered write", which is done  through the
>>address space operations prepare_write() & commit_write(). Now, the
>>prepare_write() might allocate blocks for the file (if needed). So if
>>there is some error at a later point (say ENOSPC) in prepare_write(), we
>>need to discard the allocated blocks. This is done by calling
>>"vmtruncate()" on the file. This call leads to reiserfs specific
>>truncate, which would try to add a save link for the file.
>>
>>This addition causes a reiserfs_panic, since there is already a "save
>>link" stored for the file.
>>
>>
>>I have a simple testcase to reproduce the problem, which does the same 
>>as described above. I will attach it if required.
>>
>>Any thoughts on how to fix this ?
>>
> 
> 
> Did we end up fixing this?

Finally, we were able to verify this on 2.6.18-rc7. Sorry for the delay.

Vladimir wrote :

     "I am not sure why safe link is needed for write. Maybe one who 
added that still remembers why that was done and can explain, please? "


The patch attached by Vladimir has been modified to fit into the current 
level.

The patch is on 2.6.19-rc1.

Thanks,

-Suzuki

> 
> Thanks.


[-- Attachment #2: reiserfs-no-save-links-on-write.diff --]
[-- Type: text/x-patch, Size: 2601 bytes --]

* Do not add save links for O_DIRECT writes.  

We add a save link for O_DIRECT writes to protect the i_size against the crashes before we actually finish the I/O. If we hit an -ENOSPC in aops->prepare_write(), we would do a truncate() to release the blocks which might have got initialized. Now the truncate would add another save link for the same inode causing a reiserfs panic for having multiple save links for the same inode.


Signed-off-by:  Vladimir V. Saveliev <vs@namesys.com>
Signed-off-by:  Amit Arora <amitarora@in.ibm.com>
Signed-off-by:  Suzuki K P <suzuki@in.ibm.com>


Index: linux-2.6.19-rc1/fs/reiserfs/file.c
===================================================================
--- linux-2.6.19-rc1.orig/fs/reiserfs/file.c	2006-10-10 05:54:30.000000000 -0700
+++ linux-2.6.19-rc1/fs/reiserfs/file.c	2006-11-21 17:17:36.000000000 -0800
@@ -1306,56 +1306,8 @@
 			count = MAX_NON_LFS - (unsigned long)*ppos;
 	}
 
-	if (file->f_flags & O_DIRECT) {	// Direct IO needs treatment
-		ssize_t result, after_file_end = 0;
-		if ((*ppos + count >= inode->i_size)
-		    || (file->f_flags & O_APPEND)) {
-			/* If we are appending a file, we need to put this savelink in here.
-			   If we will crash while doing direct io, finish_unfinished will
-			   cut the garbage from the file end. */
-			reiserfs_write_lock(inode->i_sb);
-			err =
-			    journal_begin(&th, inode->i_sb,
-					  JOURNAL_PER_BALANCE_CNT);
-			if (err) {
-				reiserfs_write_unlock(inode->i_sb);
-				return err;
-			}
-			reiserfs_update_inode_transaction(inode);
-			add_save_link(&th, inode, 1 /* Truncate */ );
-			after_file_end = 1;
-			err =
-			    journal_end(&th, inode->i_sb,
-					JOURNAL_PER_BALANCE_CNT);
-			reiserfs_write_unlock(inode->i_sb);
-			if (err)
-				return err;
-		}
-		result = do_sync_write(file, buf, count, ppos);
-
-		if (after_file_end) {	/* Now update i_size and remove the savelink */
-			struct reiserfs_transaction_handle th;
-			reiserfs_write_lock(inode->i_sb);
-			err = journal_begin(&th, inode->i_sb, 1);
-			if (err) {
-				reiserfs_write_unlock(inode->i_sb);
-				return err;
-			}
-			reiserfs_update_inode_transaction(inode);
-			mark_inode_dirty(inode);
-			err = journal_end(&th, inode->i_sb, 1);
-			if (err) {
-				reiserfs_write_unlock(inode->i_sb);
-				return err;
-			}
-			err = remove_save_link(inode, 1 /* truncate */ );
-			reiserfs_write_unlock(inode->i_sb);
-			if (err)
-				return err;
-		}
-
-		return result;
-	}
+	if (file->f_flags & O_DIRECT) 
+		return do_sync_write(file, buf, count, ppos);
 
 	if (unlikely((ssize_t) count < 0))
 		return -EINVAL;

  parent reply	other threads:[~2006-11-27 23:37 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-08 11:33 [BUG] Reiserfs panic while running fsstress due to multiple truncate "safe links" for a file Suzuki
     [not found] ` <20060730161348.94ecc5e0.akpm@osdl.org>
2006-11-27 23:37   ` Suzuki [this message]
2006-11-28  1:26     ` Andrew Morton
2006-11-28  2:57       ` suzuki
2006-11-30  8:44         ` Vladimir V. Saveliev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=456B76CD.5000600@in.ibm.com \
    --to=suzuki@in.ibm.com \
    --cc=akpm@osdl.org \
    --cc=amitarora@in.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rdunlap@xenotime.net \
    --cc=reiserfs-dev@namesys.com \
    --cc=reiserfs-list@namesys.com \
    --cc=vs@namesys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox