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.
On Wed, Feb 28, 2001 at 10:21:30PM +0300, Alexander Zarochentcev wrote:
> 6. Using integer constants from limits.h instead of self made ones
Urgg. limits.h is a userlevel header...
The attached patch will make similar atempts fail (but not this one as
there is also a limits.h in gcc's include dir).
Christoph
--
Of course it doesn't work. We've performed a software upgrade.
--- linux-2.4.0/Makefile Mon Dec 25 19:21:14 2000
+++ linux/Makefile Mon Dec 25 23:30:03 2000
@@ -85,7 +85,8 @@
# standard CFLAGS
#
-CPPFLAGS := -D__KERNEL__ -I$(HPATH)
+GCCINCDIR = $(shell gcc -print-search-dirs | sed -ne 's/install: \(.*\)/\1include/gp')
+CPPFLAGS := -D__KERNEL__ -nostdinc -I$(HPATH) -I$(GCCINCDIR)
CFLAGS := $(CPPFLAGS) -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing
AFLAGS := -D__ASSEMBLY__ $(CPPFLAGS)
On Wed, Feb 28, 2001 at 10:21:30PM +0300, Alexander Zarochentcev wrote:
> 6. Using integer constants from limits.h instead of self made ones
That's a userland header file. Don't use it in the kernel.
> 7. other minor fixes.
Does this patch contain Chris Mason's "tail conversion" fix that he
made after my bug report?
Erik
--
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands
Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [email protected]
WWW: http://www-ict.its.tudelft.nl/~erik/
On Thu, Mar 01, 2001 at 11:01:59AM +1100, Keith Owens wrote:
> On Wed, 28 Feb 2001 20:27:33 +0100,
> Christoph Hellwig <[email protected]> wrote:
> >Urgg. limits.h is a userlevel header...
> >
> >The attached patch will make similar atempts fail (but not this one as
> >there is also a limits.h in gcc's include dir).
> >
> >--- linux-2.4.0/Makefile Mon Dec 25 19:21:14 2000
> >-CPPFLAGS := -D__KERNEL__ -I$(HPATH)
> >+GCCINCDIR = $(shell gcc -print-search-dirs | sed -ne 's/install: \(.*\)/\1include/gp')
> >+CPPFLAGS := -D__KERNEL__ -nostdinc -I$(HPATH) -I$(GCCINCDIR)
>
> cc: trimmed to l-k.
>
> CPPFLAGS apply to the kernel compiler which can be a cross compiler but
> you are extracting data from the host gcc. What exactly are you trying
> to do here?
Prevent inclusion of the usual (/usr/include) headers.
> Are you trying to prevent the use of user space includes
> or are you trying to pick up the cross compiler includes?
Ok, gcc should be replaced by $(CC).
Christoph
--
Of course it doesn't work. We've performed a software upgrade.
On Wed, 28 Feb 2001 20:27:33 +0100,
Christoph Hellwig <[email protected]> wrote:
>Urgg. limits.h is a userlevel header...
>
>The attached patch will make similar atempts fail (but not this one as
>there is also a limits.h in gcc's include dir).
>
>--- linux-2.4.0/Makefile Mon Dec 25 19:21:14 2000
>-CPPFLAGS := -D__KERNEL__ -I$(HPATH)
>+GCCINCDIR = $(shell gcc -print-search-dirs | sed -ne 's/install: \(.*\)/\1include/gp')
>+CPPFLAGS := -D__KERNEL__ -nostdinc -I$(HPATH) -I$(GCCINCDIR)
cc: trimmed to l-k.
CPPFLAGS apply to the kernel compiler which can be a cross compiler but
you are extracting data from the host gcc. What exactly are you trying
to do here? Are you trying to prevent the use of user space includes
or are you trying to pick up the cross compiler includes?
Christoph Hellwig writes:
> Urgg. limits.h is a userlevel header...
>
> The attached patch will make similar atempts fail (but not this one as
> there is also a limits.h in gcc's include dir).
There are very few files needed from gcc's include dir. Linux ought to
be able to survive without them. Linux is already gcc-specific anyway.
On Wed, Feb 28, 2001 at 10:16:02PM -0500, Albert D. Cahalan wrote:
> Christoph Hellwig writes:
>
> > Urgg. limits.h is a userlevel header...
> >
> > The attached patch will make similar atempts fail (but not this one as
> > there is also a limits.h in gcc's include dir).
>
> There are very few files needed from gcc's include dir. Linux ought to
> be able to survive without them. Linux is already gcc-specific anyway.
I think we want stdarg.h from gcc...
Christoph
--
Of course it doesn't work. We've performed a software upgrade.
On Thu, Mar 01, 2001 at 01:39:46AM +0100, Erik Mouw wrote:
> On Wed, Feb 28, 2001 at 10:21:30PM +0300, Alexander Zarochentcev wrote:
> > 6. Using integer constants from limits.h instead of self made ones
>
> That's a userland header file. Don't use it in the kernel.
>
> > 7. other minor fixes.
>
> Does this patch contain Chris Mason's "tail conversion" fix that he
> made after my bug report?
No.
The "tail conversion" fix was sent to Alan.
It is already included into 2.4.2-ac6.
All fixes are in one combined patch:
ftp://ftp.namesys.com/pub/reiserfs-for-2.4/linux-2.4.2-reiserfs-20010301-full.patch.gz
Tail conversion fix is available as separate patch at namesys.com ftp site:
ftp://ftp.namesys.com/pub/reiserfs-for-2.4/another-null.diff .
> Erik
>
> --
> J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
> of Electrical Engineering, Faculty of Information Technology and Systems,
> Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands
> Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [email protected]
> WWW: http://www-ict.its.tudelft.nl/~erik/
Thanks,
Alex.
Christoph Hellwig writes:
> On Wed, Feb 28, 2001 at 10:16:02PM -0500, Albert D. Cahalan wrote:
>> Christoph Hellwig writes:
>>
>>> Urgg. limits.h is a userlevel header...
>>>
>>> The attached patch will make similar atempts fail (but not this one as
>>> there is also a limits.h in gcc's include dir).
>>
>> There are very few files needed from gcc's include dir. Linux ought to
>> be able to survive without them. Linux is already gcc-specific anyway.
>
> I think we want stdarg.h from gcc...
Yes, just as apps want <linux/*.h> files.
The kernel can have a copy. If the stack frame layout changes enough
to cause trouble with stdarg.h, then most likely there will be huge
trouble in 42 other places.
If you insist on using whatever random stdarg.h might be on the
system, then just copy it into the build area. The compile might
even run a bit faster without the extra directory to search.