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 kno
Thanks for reporting this Joe, looks like a needed patch.
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 determin
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
-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, et
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 bitm
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 reiserfs
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 s
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..
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,
>
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 entire
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 he
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
pointe
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. Simpl
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 why
On Mon, Jan 16, 2006 at 11:30:20AM -0800, Joe Feise wrote:
> I also see freezes, since 2.6.15-mm2. I did not attribute that to reiser4,
> though, since there is more in the -mm patches.
I emailed to reiser list not for the freeze, but because it seems wrong to
me that filesystem starts without comp
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 alrea
17 matches
Mail list logo