From: Alexander Zarochentcev <zam@namesys.com>
To: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Cc: Hans Reiser <reiser@namesys.com>, reiserfs-dev@namesys.com
Subject: [PATCH] reiserfs patch for linux-2.4.2
Date: Wed, 28 Feb 2001 22:21:30 +0300 [thread overview]
Message-ID: <20010228222130.A3131@crimson.namesys.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2282 bytes --]
Hello !
This reiserfs patch for linux-2.4.2 was prepared by all members of the reiserfs dev team.
It contains the following fixes/cleanups/improvements:
1. Fix for possible preallocated blocks leakage after a system crash
Reiserfs does block preallocation for big files like ext2 does. Preallocation
code changes both the bitmap and the free blocks count in the superblock. It
is possible to have unattached disk blocks which do not belong to any file
(i.e. free space leak) after a crash. Unlike ext2, reiserfs does not check for
consistency of a filesystem that was not cleanly unmounted. There is no simple
way to recover free space.
For a given transaction, the fix is to, at the transaction end, discard the
preallocations for those inodes which have one.
2. Object id sharing problem.
Fix for reiserfs/inode.c:reiserfs_iget () It now makes sure that it
really got inode of an object it is looking for.
3. Improvement of error handling in reiserfs_add_entry()
There is a place in reiserfs_add_entry() code where fs corruption
(existence of hidden entries--objects temporarily used in renaming), I/O
errors, or several other occurences, can produce an error message which has no
useful information.
We have had several bug reports about this vs-7032 message in the
older 3.5 version. Each time we were unable to reproduce it. We do not
understand the reason. This error handling fix will make such bug
reports much more informative for us if they should occur in the newer
version.
4. In reiserfs_add_entry(), we don't need to scan a whole bit_string for
non-zero bits to be able to use a smallest generation counter to avoid
researching for the dir entry insertion point.
5. bad block support
New ioctls added, enabling direct manipulation of block allocation bitmap by
the user space programs: ioctl to mark block as used, ioctl to mark block as
free and ioctl to update counter (stored in the super block) of blocks marked
through first two ioctls. This can be used as crude form of bad block support
(e.g., such ioctls can be used just after creation of file system on the device
with known bad blocks). User level interface to ioctls available.
6. Using integer constants from limits.h instead of self made ones
7. other minor fixes.
Regards,
Alex.
[-- Attachment #2: linux-2.4.2-reiserfs-20010227.patch.gz --]
[-- Type: application/x-gunzip, Size: 10013 bytes --]
next reply other threads:[~2001-02-28 19:21 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-02-28 19:21 Alexander Zarochentcev [this message]
2001-02-28 19:27 ` [PATCH] reiserfs patch for linux-2.4.2 Christoph Hellwig
2001-03-01 0:01 ` Keith Owens
2001-03-01 0:05 ` Christoph Hellwig
2001-03-01 3:16 ` Albert D. Cahalan
2001-03-01 8:18 ` Christoph Hellwig
2001-03-02 0:35 ` Albert D. Cahalan
2001-03-01 0:39 ` Erik Mouw
2001-03-01 10:36 ` [reiserfs-dev] " Alexander Zarochentcev
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=20010228222130.A3131@crimson.namesys.com \
--to=zam@namesys.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=reiser@namesys.com \
--cc=reiserfs-dev@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.