Hello
On Wed, 2006-01-11 at 11:09 +0200, Raymond A. Meijer wrote:
Hello,
This morning I found the following warning on my Debian server holding a 253
GB Debian archive mirror:
ReiserFS: dm-8: warning: vs-4080: reiserfs_free_block: free_block
(dm-8:46707368)[dev:blocknr]: bit already
Hello all -
The following patchset allows reiserfs to load its bitmap blocks on demand
like other file systems.
There are several reasons for this:
* Bitmap blocks, relative to other metadata blocks, are among the least used
blocks in the file system. We don't cache the root node block, so
There is a check in is_reusable to determine if a particular block is a bitmap
block. It verifies this by going through the array of bitmap block buffer
heads and comparing the block number to each one.
Bitmap blocks are at defined locations on the disk in both old and current
formats.
Similar to the SB_JOURNAL cleanup that was accepted a while ago, this patch
uses a temporary variable for buffer head references from the bitmap info
array.
This makes the code much more readable in some areas.
It also uses proper reference counting, doing a get_bh() after using the
This is the patch the three previous ones have been leading up to.
It changes the behavior of ReiserFS from loading and caching all the bitmaps
as special, to treating the bitmaps like any other bit of metadata and just
letting the system-wide caches figure out what to hang on to.
Buffer
This patch moves the bitmap loading code from super.c to bitmap.c
The code is also restructured somewhat. The only difference between new
format bitmaps and old format bitmaps is where they are. That's a two liner
before loading the block to use the correct one. There's no need for
an
Hello
Sorry for delayed answer. we had long holidays here.
Please try whether attached patch fixes the problem.
On Mon, 2006-01-02 at 01:04 -0800, Joe Feise wrote:
Vladimir V. Saveliev wrote on 12/28/05 18:31:
Hello
On Tue, 2005-12-27 at 21:25 -0800, Joe Feise wrote:
Hi,
in one
On Tue 17 Jan 2006 23:32, Vladimir V. Saveliev wrote:
Hi Vladimir,
ReiserFS: dm-8: warning: vs-4080: reiserfs_free_block: free_block
(dm-8:46707368)[dev:blocknr]: bit already cleared
This indicated a corruption in disk space allocation bitmap: used block
was marked as free.
I see..
Am
Hello,
unfortunately, the patch did not help. I still get the same errors:
$: mount -o ro,remount /usr
$: make xconfig
CHECK qt
HOSTCC scripts/kconfig/kconfig_load.o
In file included from /usr/include/sys/types.h:133,
from /usr/include/stdlib.h:433,
from
Hi.
I've been running a few tests with reiserfs and tails, and have been
unable to create a setup where the use (or lack) of tails results in a
significant difference in the amount of disk space used.
Here's what I've done:
1. Create a fresh 1GB filesystem (in a file on loopback), using
Are you saying that you allow bitmaps to be unloaded? If yes, how about
making that a separate option, and not the default?
Hans
Jeff Mahoney wrote:
This is the patch the three previous ones have been leading up to.
It changes the behavior of ReiserFS from loading and caching all the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hans Reiser wrote:
Are you saying that you allow bitmaps to be unloaded? If yes, how about
making that a separate option, and not the default?
They're released, yes. Whether or not they're unloaded is up to the rest
of the system, vm pressure, etc
The result is not expected, Vitaly please look into it.
Hans
Bruce Guenter wrote:
Hi.
I've been running a few tests with reiserfs and tails, and have been
unable to create a setup where the use (or lack) of tails results in a
significant difference in the amount of disk space used.
Here's
Jeff Mahoney wrote:
Hans Reiser wrote:
Are you saying that you allow bitmaps to be unloaded? If yes, how about
making that a separate option, and not the default?
They're released, yes. Whether or not they're unloaded is up to the rest
of the system, vm pressure, etc to determine. This
Thanks for reporting this Joe, looks like a needed patch.
Hi,
Looking the http://linuxgazette.net/122/TWDT.html#piszcz article, I
see that
in some cases ReiserFS 3.X is better than Reiser4.
Correct me if I am wrong. High numbers means poor, more delay.
Now, because we plan to support both: Reiser3 and Reiser4 in our OS,
we plan to
16 matches
Mail list logo