From: Hans Reiser <reiser@namesys.com>
To: Marcelo Tosatti <marcelo@conectiva.com.br>,
Oleg Drokin <green@namesys.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: [Fwd: 2.4 journal overflow fix, please forward]
Date: Tue, 04 Mar 2003 17:01:44 +0300 [thread overview]
Message-ID: <3E64B1C8.2090706@namesys.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 25 bytes --]
Please apply.
--
Hans
[-- Attachment #2: 2.4 journal overflow fix, please forward --]
[-- Type: message/rfc822, Size: 2815 bytes --]
From: Oleg Drokin <green@namesys.com>
To: reiser@namesys.com
Subject: 2.4 journal overflow fix, please forward
Date: Tue, 4 Mar 2003 16:52:24 +0300
Message-ID: <20030304165224.B8434@namesys.com>
Hello!
This changeset fixes possible journal overflow (and assertion) while deleting
large highly fragmented files on large enough fs (each file block should
be in different bitmap). While this condition is hard to trigger, it is still
possible and Philippe Gramoulle managed to reproduce it for us.
Please pull from bk://namesys.com/bk/reiser3-linux-2.4-journal-overflow-fix
Tested by me and Elena, reviewed by Chris Mason.
Diffstat:
stree.c | 15 +++++++++++++++
1 files changed, 15 insertions(+)
Plain text path:
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet 1.1009 -> 1.1010
# fs/reiserfs/stree.c 1.20 -> 1.21
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 03/03/04 green@angband.namesys.com 1.1010
# reiserfs: Fix possible transaction overflow when deleting highly fragmented large files.
#
# --------------------------------------------
#
diff -Nru a/fs/reiserfs/stree.c b/fs/reiserfs/stree.c
--- a/fs/reiserfs/stree.c Tue Mar 4 16:48:52 2003
+++ b/fs/reiserfs/stree.c Tue Mar 4 16:48:52 2003
@@ -1125,6 +1125,21 @@
journal_mark_dirty (th, p_s_sb, p_s_bh);
inode->i_blocks -= p_s_sb->s_blocksize / 512;
reiserfs_free_block(th, tmp);
+ /* In case of big fragmentation it is possible that each block
+ freed will cause dirtying of one more bitmap and then we will
+ quickly overflow our transaction space. This is a
+ counter-measure against that scenario */
+ if (journal_transaction_should_end(th, th->t_blocks_allocated)) {
+ int orig_len_alloc = th->t_blocks_allocated ;
+ pathrelse(p_s_path) ;
+
+ journal_end(th, p_s_sb, orig_len_alloc) ;
+ journal_begin(th, p_s_sb, orig_len_alloc) ;
+ reiserfs_update_inode_transaction(inode) ;
+ need_research = 1;
+ break;
+ }
+
if ( item_moved (&s_ih, p_s_path) ) {
need_research = 1;
break ;
reply other threads:[~2003-03-04 13:51 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=3E64B1C8.2090706@namesys.com \
--to=reiser@namesys.com \
--cc=green@namesys.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo@conectiva.com.br \
/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