Re: Reiser4 support on parted ...
On Thu, May 05, 2005 at 06:05:51PM -0500, David Masover wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew Clausen wrote: On Thu, May 05, 2005 at 05:10:08PM -0500, David Masover wrote: To support doing what to Reiser4? parted is a disk management project -- specifically, a way to create, delete, and resize partitions. Think of it as fdisk with nicer units and built-in resizefs tools. This would, I think, involve creating a fully functional resizefs.reiser4 -- something I distinctly remember Hans telling me not to do, because my approach also created (most of) an online repacker, which is something Hans wants to do for money. It would be possible to implement mkfs and fsck support only. Couldn't this just be a wrapper to mkfs.reiser4 and fsck.reiser4? libreiser4 was designed to support embedding into parted easily. The AAL lib provides block device abstraction layer which is needed in parted. -- Alex.
Re: reiser4 on PPC
Hi, On Sun, May 01, 2005 at 12:03:13PM -0500, Jake Maciejewski wrote: Now that reiser4 seems to be working on AMD64, I'm trying to test it on PPC. Unfortunately, I haven't even been able to mount a reiser4 FS. Unfortunately we could not test reiser4 on PPC because of lack of test machine. Currently no idea where it might fail. I get the following error: mount: No such file or directory. I've tried a loopback filesystem and a native partition. The same native patition works when formatted with reiserFS. I've tried the code as a module and builtin. I was using reiser4progs 1.0.4 and the latest -mm patch on vanilla, which while not officially supported works on AMD64 and x86 and shouldn't cause a problem like this. fsck.reiser4 says the unmountable filesystem is consistent. Is there anything else I should try? can you look at your machine /var/log/messages or dmesg(8) output for reiser4 messages? If you have possibility to check the fs by an fsck.reiser4 compiled on i386, please do it. If you don't have i386 around or have no time to compile the progs there, make a small file with reiser4 fs image , compress it and make it downloadable. -- Jake Maciejewski [EMAIL PROTECTED] Thanks in advance, Alex.
Re: Less disk space with reiser4?
On Wed, Apr 13, 2005 at 11:35:12PM -0500, David Masover wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stefan Andersson wrote: Alex Zarochentsev wrote: On Wed, Apr 13, 2005 at 02:51:13PM +0200, Stefan Andersson wrote: Thanks for all the answers. Now would it be possible to change the 5% to something else? even if the fs would be unreliable? That is what I want to test, or if someone knows the answer to that. The only indication I've heard that it would make the FS unreliable is if you had less space reserved than you had RAM available to stack up writes which haven't been allocated. In your case, it's a bug that you haven't been able to set this on your own. Note that I said unreliable, not slow. Everyone keeps telling us that you'll get slow with 25% space available, so the 5% is really just a sanity check, but you're probably fine there, too. My question to the Namesys guys is, have you actually tested situations like this? no, it the 5% is our rough estimation. it would never reached. It is like extends of all files address only 1 block each. If you want to artificially create that situation, you can probably just shrink the values down a bunch -- make an fs on a 1 gig drive on a virtual machine (qemu + accelerator) with only a couple megs of RAM available for cache/buffer, then try to fill it. How close can you get to 100% full before something blows up? Suppose the index part of the tree would take only 0.5%. And what? Any successful test will not prove that the new estimation is correct (reliable). We need to re-design the estimation, make it adaptive, for example, to be aware of well-allocated files. Or we have to change the current disk space reservation scheme completely. -- Alex.
Re: Less disk space with reiser4?
On Wed, Apr 13, 2005 at 02:51:13PM +0200, Stefan Andersson wrote: Thanks for all the answers. Now would it be possible to change the 5% to something else? even if the fs would be unreliable? I have been looking at the code but havent been able to figure out what it is I need to change to test it. So far I have only looked at the kernel code, not the reiser4progs or libaal. //Stefan -- Alex.
Re: Less disk space with reiser4?
On Mon, Apr 11, 2005 at 04:30:53PM +0200, Stefan Andersson wrote: Hi, I have a disk array wich I used reiserfs(v3) on, and got 932G. Now I started to test reiser4 on it and get less space, 886G. Is it suppose to be like this or is there something wrong? reiser4 reserves 5% of disk space. That is so because of delayed block allocation impelented in reiser4. Actual block allocation is done near the transaction commit, it means the allocation has to be reliable -- we can't return ENOSPC because the write(2) call when we could return an error was already completed successfully. The reserved space makes the allocation reliable because it covers possible insertions (and growing of the internal reiser4 tree) of new extent items insertions on a highly fragmented fs. I'am using linux 2.6.11.4 and default settings for mkfs.reiser4 and mkfs.reiserfs, and reiser4 patch from 2.6.11-mm3. //Stetan -- Alex.
Re: [patch 1/1] reiserfs: make resize option auto-get new device size
Hi,
On Fri, Apr 08, 2005 at 06:55:50AM +0200, [EMAIL PROTECTED] wrote:
Cc: [EMAIL PROTECTED], reiserfs-list@namesys.com, [EMAIL PROTECTED]
It's trivial for the resize option to auto-get the underlying device size,
while
it's harder for the user. I've copied the code from jfs.
Since of the different reiserfs option parser (which does not use the superior
match_token used by almost every other filesystem), I've had to use the
resize=auto and not resize option to specify this behaviour. Changing the
option parser to the kernel one wouldn't be bad but I've no time to do this
cleanup in this moment.
do people really need it?
user-level utility reisize_reiserfs, being called w/o size argument,
calculates the device size and uses resize mount option with correct value.
Btw, the mount(8) man page should be updated to include this option. Cc the
relevant people, please (I hope I cc'ed the right people).
Signed-off-by: Paolo 'Blaisorblade' Giarrusso [EMAIL PROTECTED]
---
linux-2.6.11-paolo/fs/reiserfs/super.c | 21 ++---
1 files changed, 14 insertions(+), 7 deletions(-)
diff -puN fs/reiserfs/super.c~reiserfs-resize-option-like-jfs-auto-get
fs/reiserfs/super.c
--- linux-2.6.11/fs/reiserfs/super.c~reiserfs-resize-option-like-jfs-auto-get
2005-04-07 20:37:58.0 +0200
+++ linux-2.6.11-paolo/fs/reiserfs/super.c2005-04-08 01:01:18.0
+0200
@@ -889,12 +889,18 @@ static int reiserfs_parse_options (struc
char * p;
p = NULL;
- /* resize=NNN */
- *blocks = simple_strtoul (arg, p, 0);
- if (*p != '\0') {
- /* NNN does not look like a number */
- reiserfs_warning (s, reiserfs_parse_options: bad value %s,
arg);
- return 0;
+ /* resize=NNN or resize=auto */
+
+ if (!strcmp(arg, auto)) {
+ /* From JFS code, to auto-get the size.*/
+ *blocks = s-s_bdev-bd_inode-i_size
s-s_blocksize_bits;
+ } else {
+ *blocks = simple_strtoul (arg, p, 0);
+ if (*p != '\0') {
+ /* NNN does not look like a number */
+ reiserfs_warning (s, reiserfs_parse_options: bad value
%s, arg);
+ return 0;
+ }
}
}
@@ -903,7 +909,8 @@ static int reiserfs_parse_options (struc
unsigned long val = simple_strtoul (arg, p, 0);
/* commit=NNN (time in seconds) */
if ( *p != '\0' || val = (unsigned int)-1) {
- reiserfs_warning (s, reiserfs_parse_options: bad value
%s, arg); return 0;
+ reiserfs_warning (s, reiserfs_parse_options: bad value
%s, arg);
+ return 0;
}
*commit_max_age = (unsigned int)val;
}
_
--
Alex.
Re: resizer?
hello, On Sun, Apr 03, 2005 at 10:55:12PM -0500, David Masover wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 What happened to resizefs.reiser4? I know repacking/shrinking is gone/proprietary, but what about growing? I distinctly remember that I used to be able to grow a Reiser4 partition. i guess it was reiserfs. How much work would you expect a repacker to be? (I might try writing a proof-of-concept on my own...) no idea, new version should be smarter then the old one, the algorithm is not scratched yet. -- Alex.
Re: reiserfs partition unmountable
On Sat, Apr 02, 2005 at 04:46:47PM +0200, Lars Segelken wrote: Hi, i have a reiserfs partition which can't be mounted under Suse 9.2 and Unbuntu 5.04 (Linux 2.6.8 and 2.6.10, i think) after there was a system crash. Same partition can still be mounted with Knoppix 3.2. what kernel used by Knoppix 3.2? can you send here output of debugreiserfs -J /dev/the device ? -- Alex.
Re: strange dmesg output?
On Mon, Apr 04, 2005 at 11:15:39AM -0400, Nicolas Smallwood wrote: reiser4[vianoderepos(1501)]: commit_current_atom (fs/reiser4/txnmgr.c:1206)[niki ta-3176]: WARNING: Flushing like mad: 16384 Saw this in dmesg this morning... is it anything to really worry about? no, if it was single nikita-3176 message. Thank You, Nicolas Smallwood Maya Design, Inc Suite 702 2100 Wharton Street Pittsburgh, PA 15203 412-488-2900 (voice) 412-488-2940 (fax) -- Alex.
Re: ReiserFS 3.6 errors
Hi, On Tue, Mar 29, 2005 at 09:58:33AM -0600, Dan Oglesby wrote: Greetings, I just finished installing a machine that uses ReiserFS v3.6 filesystems, one of which is on a RAID-5 device off of a 3Ware 7506 controller. After the build, a stress test was run that generates a lot of disk I/O, and I saw the following in dmesg: vs-500: unknown uniqueness 1162690892 vs-500: unknown uniqueness 1162690892 vs-500: unknown uniqueness 1162690892 vs-500: unknown uniqueness 1162690892 vs-500: unknown uniqueness 1162690892 vs-500: unknown uniqueness 1162690892 , item_len 14136, item_location 10272, free_space(entry_count) 11827 vs-5150: search_by_key: invalid format found in block 2029494. Fsck? vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat data of [40 171378 0x0 SD] is_leaf: item location seems wrong (second one): *3.6* [40 357194 0x0 SD], item_len 44, item_location 2412, free_space(entry_count) 65535 vs-5150: search_by_key: invalid format found in block 3864557. Fsck? vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat data of [40 357181 0x0 SD] vs-500: unknown uniqueness 1647255672 vs-500: unknown uniqueness 1647255672 vs-500: unknown uniqueness 1647255672 vs-500: unknown uniqueness 1647255672 vs-500: unknown uniqueness 1647255672 vs-500: unknown uniqueness 1647255672 , item_len 27951, item_location 29803, free_space(entry_count) 28265 vs-5150: search_by_key: invalid format found in block 4488286. Fsck? vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat data of [40 453681 0x0 SD] I did see something in the FAQ about requiring a reboot after changing partitions on a disk. Unfortunately, I didn't see this until after the machine was built. Could these errors be caused from a lack of a reboot between partitioning the disk and running mkreiserfs? This is on a RedHat 7.3 system, using kernel 2.4.20. isn't it a vanilla 2.4.20 kernel from ftp.kernel.org? there were reports that reiserfs does not work well in RH kernels. stock 2.4.20 might work much better. usually their kernels are patched a lot, some kernel patch may cause reiserfs instability. -- Alex.
Re: umount and sync delays
Hello, On Mon, Mar 14, 2005 at 08:59:00PM +0100, Gorazd Golob wrote: I have no idea, and so I must guess. I guess that if you try the same application on a different computer it will work reasonably fast and that the problem is hardware doing extensive retries. We have tests on ext3 and it wasn't like fast, but few minutes, not 30 minutes.. Or, you are doing completely random IO with tiny little bits of dirty data in a large file, and so each 4k is a seek. I doubt this, but in theory No.. there is really random data in this files, but files are small (most of them less than 4 kb). can you repeat the test with earlier kernel, like 2.6.9 + the patch from ftp.namesys.com ? just to be sure that the bug wasn't introduced recently. Or you have something else on that machine dirtying lots of memory after the application closes, and perhaps there is a flaw in our method for forcing atoms to disk after they get old that we should look into. There were no other applications on that system and none of user land deamons were using that partition. Finally, it could be none of the above and something is wrong in our sync algorithms, and somebody should log onto your machine and look at it. Thanks. It is better to find how to reproduce the bug in our test environment (kGDB :-). Probably all guesses are wrong, but I have to ask them as a start. Hope it helped.. if you have managed to create tons of independed atoms, tons of independed commits may take a lot of time :( tnx, gorazd -- Alex.
Re: reiser4 bug
Hello, On Sun, Feb 27, 2005 at 07:34:11PM +, Szabolcs Illes wrote: Hi All, I have been using reiser4fs for 4 months without any problem since today. After tryinig to open a movie with mplayer a have this in my log: how large was the movie file? We have another similar bug report related to writing/reading of a large (20GB) tar file, so file size may be important. Feb 27 14:00:22 sunset kernel: reiser4[mc(9192)]: write_sd_by_inode_common (fs/reiser4/plugin/object.c:480)[nikita-2221]: Feb 27 14:00:22 sunset kernel: WARNING: Failed to save sd for 1599330: -5 Feb 27 14:00:22 sunset kernel: reiser4[mc(9192)]: create_child_common (fs/reiser4/plugin/dir/dir.c:501)[nikita-2219]: Feb 27 14:00:22 sunset kernel: WARNING: Failed to create sd for 1599330 Feb 27 14:00:23 sunset kernel: reiser4[cupsd(3296)]: parse_node40 (fs/reiser4/plugin/node/node40.c:767)[nikita-494]: Feb 27 14:00:23 sunset kernel: WARNING: Wrong level found in node: 1 != 95 Feb 27 14:00:23 sunset kernel: reiser4[cupsd(3296)]: parse_node40 (fs/reiser4/plugin/node/node40.c:767)[nikita-494]: Feb 27 14:00:23 sunset kernel: WARNING: Wrong level found in node: 1 != 95 Feb 27 14:00:24 sunset kernel: reiser4[cupsd(3296)]: parse_node40 (fs/reiser4/plugin/node/node40.c:767)[nikita-494]: Feb 27 14:00:24 sunset kernel: WARNING: Wrong level found in node: 1 != 95 Thanks, -- Alex.
Re: where are reiser4 sources
hello On Mon, Feb 21, 2005 at 05:16:47PM +0100, Mark Junker wrote: Hi, where are the Reiser4 sources? I just want to use Reiser4 in a separate application and don't like the idea of extracting the sources from the linux 2.6 patch. public access to our bk repository works again (there were problems with bk pull) bk://bk.namesys.com/bk/reiser4 -- it contains fs/reiser4/**. Regards, Mark -- Alex.
Re: reiser4 bug
On Sun, Feb 27, 2005 at 07:34:11PM +, Szabolcs Illes wrote: Hi All, I have been using reiser4fs for 4 months without any problem since today. After tryinig to open a movie with mplayer a have this in my log: no other reiser4 messages in the log for 4 months? like delimiting keys mismatch reports? there was wrong bitmap checksum. actually I haven't seen such reports until now. are you sure your computer's disk/ram work well? Feb 27 14:00:22 sunset kernel: reiser4[mc(9192)]: write_sd_by_inode_common (fs/reiser4/plugin/object.c:480)[nikita-2221]: Feb 27 14:00:22 sunset kernel: WARNING: Failed to save sd for 1599330: -5 Feb 27 14:00:22 sunset kernel: reiser4[mc(9192)]: create_child_common (fs/reiser4/plugin/dir/dir.c:501)[nikita-2219]: Feb 27 14:00:22 sunset kernel: WARNING: Failed to create sd for 1599330 Feb 27 14:00:23 sunset kernel: reiser4[cupsd(3296)]: parse_node40 (fs/reiser4/plugin/node/node40.c:767)[nikita-494]: Feb 27 14:00:23 sunset kernel: WARNING: Wrong level found in node: 1 != 95 Feb 27 14:00:23 sunset kernel: reiser4[cupsd(3296)]: parse_node40 (fs/reiser4/plugin/node/node40.c:767)[nikita-494]: Feb 27 14:00:23 sunset kernel: WARNING: Wrong level found in node: 1 != 95 Feb 27 14:00:24 sunset kernel: reiser4[cupsd(3296)]: parse_node40 (fs/reiser4/plugin/node/node40.c:767)[nikita-494]: Feb 27 14:00:24 sunset kernel: WARNING: Wrong level found in node: 1 != 95 .. 1000x times were there unclear reboots? That shouldn't be a problem unless disk write caching is disabled. After trying to reboot: http://nuk.teteny.elte.hu/~selli/dscf0437.jpg (using 2.6.9-cko3) http://nuk.teteny.elte.hu/~selli/dscf0438.jpg http://nuk.teteny.elte.hu/~selli/dscf0439.jpg I had to install a new root filesystem, and using that I was able to fix the filesystem. ( --build-sb, build-fs, and fix ) I have lost some file but fortunatly I was able to use my system again. The affair happend when I was using 2.6.10 with reiser4 patch(from namesys.com). I tried to reboot with my previos kernel (2.6.9-cko3) but had the some bug (see screenshots). Sorry but I forgot to save the outout of the fsck prog :(. If U need any information do not hesitate contacting me.( I am not on the mailing list) Some info in advanve: Hardware: Dell Inpiron 8600c (1600Mhz Centrion processor) Kernel config: [...] -- Alex.
Re: Reiser4fs and SPARC64?
hello On Mon, Feb 21, 2005 at 01:23:25PM +0100, [EMAIL PROTECTED] wrote: These 2 patches are no more needed for me and my sparc64 since you released 1.0.4? Today i compiled my 2.6.10-mm3-reiser4 kernel and it works fine. Only have you tried reiser4? problem left is LVM cause the kernel gets too big (3.5MB) with LVM compiled in it. So my root filesystem will be no LVM... greetz Florian -- Alex.
Re: Reiser4fs and SPARC64?
On Thu, Feb 17, 2005 at 10:38:16AM +0100, [EMAIL PROTECTED] wrote: Hi Alex and Vitaly, so i will use: http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10/2.6.10-mm3/2.6.10-mm3.bz2 against 2.6.10 and after that the 5 patches you two emailed me. vitaly's patches are for user-land utilities. should work? How can I know it? I have no sparc64 around. -- Alex.
Re: Bitmap alignment issues....
On Tue, Feb 15, 2005 at 04:37:29PM -0500, Tom Evans wrote:
do you see aligment faults in the bitmap code after my patch?
The patch that was presented a few days ago caused corruption of the volume.
I used a patch I did that simply used the unaligned macros.
did you apply the patch (see below) which i sent to amd64 guys?
--
diff -Nru a/plugin/space/bitmap.c b/plugin/space/bitmap.c
--- a/plugin/space/bitmap.c Wed Feb 16 07:53:36 2005
+++ b/plugin/space/bitmap.c Wed Feb 16 07:53:36 2005
@@ -165,7 +165,7 @@
static int
find_next_zero_bit_in_word(ulong_t word, int start_bit)
{
- ulong_t mask = 1 start_bit;
+ ulong_t mask = 1UL start_bit;
int i = start_bit;
while ((word mask) != 0) {
@@ -235,7 +235,7 @@
assert (zam-965, start_bit BITS_PER_LONG);
assert (zam-966, start_bit = 0);
- bit_mask = (1 nr);
+ bit_mask = (1UL nr);
while (bit_mask != 0) {
if (bit_mask word)
--
I will try the new patch this evening.
Thanks,
...tom
--
Alex.
Re: ReiserFS V3 and linux-kernel-2.6
On Thu, Feb 10, 2005 at 08:36:05AM +0200, Oleg O. Ossovitskii wrote: Hello, Alex! Wednesday, February 9, 2005, 5:56:26 PM, you wrote: VFS: Cannot open root device hdc8 or unknown-block(0,0) Please append a correct root= boot option Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) AZ please make sure that the rootfs block device driver (IDE disk) was compiled AZ into the kernel. yes it compiled in the kernel AZ can you try to following? AZ 1) boot w/o devfs No, my /dev directory is empty without devfs. It's mountpoint only AZ 2) check that the block device driver is loaded successfully AZand partition table is read properly AZ(look at kernel boot messages) As I can see (messages disappears too fast and Ctrl-PgUp don't work) ide driver loaded, but I'm not sure. How can I see kernel messages after kernel panic? 1. serial console. 2. netconsole (linux-src/Documentation/networking/netconsole.txt) -- Alex.
Re: Bitmap alignment issues....
On Thu, Feb 10, 2005 at 12:10:14AM -0500, Thomas Evans wrote: Thanks for the patch the helped with the vast majority of the fixups. Now there are just a trickle occurring in various places - would it be helpful for me to track them down, or are there folks who are already pursuing this? which kernel are you using for alpha axp ? did it require additional patches to vanilla kernel? ...tom -- Alex.
Re: ReiserFS V3 and linux-kernel-2.6
On Wed, Feb 09, 2005 at 11:05:14AM +0200, Oleg O. Ossovitskii wrote: Hello! I run self compiled kernel 2.4.27 w/devfs and want to upgrade to 2.6.10 w/devfs. All kernels without using initrd /dev/hdc2 - /boot - ext2 /dev/hdc8 - / - ReiserFS V3 gcc 3.4.3, modultils-2.4.21, glibc-2.3.4 I installed module-init-tools-3.1.tar.bz2 sysfsutils-1.1.0.tar.bz2 hotplug-2004_09_23.tar.bz2 udev-051 and all that I found in Changes from kernel-2.6.10 In the grub config i have: # For booting GNU/Linux title GNU/Linux-2.6.x kernel (hd0,1)/vmlinuz root=/dev/hdc8 rw devfs=mount title GNU/Linux-2.4.x kernel (hd0,1)/vmlinuz-2.4 root=/dev/hdc8 rw devfs=mount -- I can boot into 2.4.x kernel, but when I try to boot to 2.6.10 kernel I get error message kernel panic: VFS: Cannot open root device hdc8 or unknown-block(0,0) Please append a correct root= boot option Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) please make sure that the rootfs block device driver (IDE disk) was compiled into the kernel. -- Alex.
Re: ReiserFS V3 and linux-kernel-2.6
On Wed, Feb 09, 2005 at 05:09:24PM +0200, Oleg O. Ossovitskii wrote: Hello, Alex! Wednesday, February 9, 2005, 4:44:46 PM, you wrote: # For booting GNU/Linux title GNU/Linux-2.6.x kernel (hd0,1)/vmlinuz root=/dev/hdc8 rw devfs=mount title GNU/Linux-2.4.x kernel (hd0,1)/vmlinuz-2.4 root=/dev/hdc8 rw devfs=mount -- I can boot into 2.4.x kernel, but when I try to boot to 2.6.10 kernel I get error message kernel panic: VFS: Cannot open root device hdc8 or unknown-block(0,0) Please append a correct root= boot option Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) AZ please make sure that the rootfs block device driver (IDE disk) was compiled AZ into the kernel. can you try to following? 1) boot w/o devfs 2) check that the block device driver is loaded successfully and partition table is read properly (look at kernel boot messages) btw, I have no troubles switching my system between 2.4.x and 2.6.x -- Alex.
Re: Bitmap alignment issues....
hello,
On Wed, Feb 09, 2005 at 12:59:17PM -0500, Tom Evans wrote:
Hi All -
I am new to the list - I have been using Reiser4 on Linux/Alpha
for several months now and like very much what it offers.
(I use a -mm kernel from kernel.org with a Debian distro)
Recently I became aware or a large number or alignment fixups
occurring in the kernel, specifically in the reiser4 code.
(My machine(s) would occasionally slow to a crawl when doing
intense disk i/o - I thought it was because I had recently
started using IDE drives in my systems (the IDE controllers
on these boards are notoriously slow) ).
I determined that 50k+ alignment faults were happening
per second - I traced the majority down to these 3 functions:
1) reiser4_find_next_set_bit (in fs/reiser4/plugins/space/bitmap.c)
2) find_next_zero_bit (in asm/bitops.h)
3) replace_extent (in fs/reiser4/plugins/item/extent.c)
The first 2 accounted for ~4million faults during boot - essentially,
the base address of the bit array is not aligned properly
for ulong accesses on Alpha (which are 64bit).
I worked around this by using get_unaligned() for the array
accesses in #1 and implemented a version of find_next_zero_bit
local to reiser4 that handles unaligned base addresses (no need
for all other users of the function to suffer the same performance hit).
Those 2 changes brought the number of alignment fixups to 0 on a boot -
the #3 issue accounts for a very small number of fixups - I have not
yet found the exact location.
While these changes eliminated the faults, they are not optimal,
get_unaligned() adds many cycles over a standard load.
I wanted to see if anyone here was already familiar with this issue and
what the process would be for getting it addressed.
it is known. ca you try the attached patch?
Thanks for your patience!
...tom
--
Alex.
= plugin/space/bitmap.c 1.186 vs edited =
--- 1.186/plugin/space/bitmap.c Wed Jan 19 18:52:52 2005
+++ edited/plugin/space/bitmap.cSun Feb 6 19:23:01 2005
@@ -54,13 +54,15 @@
#define CHECKSUM_SIZE4
+#define BYTES_PER_LONG (sizeof(long))
+
#if BITS_PER_LONG == 64
# define LONG_INT_SHIFT (6)
#else
# define LONG_INT_SHIFT (5)
#endif
-#define LONG_INT_MASK (BITS_PER_LONG - 1)
+#define LONG_INT_MASK (BITS_PER_LONG - 1UL)
typedef unsigned long ulong_t;
@@ -179,17 +181,46 @@
#include asm/bitops.h
+#if BITS_PER_LONG == 64
+
+#define OFF(addr) (((ulong_t)(addr) (BYTES_PER_LONG - 1)) 3)
+#define BASE(addr) ((ulong_t*) ((ulong_t)(addr) ~(BYTES_PER_LONG - 1)))
+
+static inline void reiser4_set_bit(int nr, void * addr)
+{
+ ext2_set_bit(nr + OFF(addr), BASE(addr));
+}
+
+static inline void reiser4_clear_bit(int nr, void * addr)
+{
+ ext2_clear_bit(nr + OFF(addr), BASE(addr));
+}
+
+static inline int reiser4_test_bit(int nr, void * addr)
+{
+ return ext2_test_bit(nr + OFF(addr), BASE(addr));
+}
+static inline int reiser4_find_next_zero_bit(void * addr, int maxoffset, int
offset)
+{
+ int off = OFF(addr);
+
+ return ext2_find_next_zero_bit(BASE(addr), maxoffset + off, offset +
off) - off;
+}
+
+#else
+
#define reiser4_set_bit(nr, addr)ext2_set_bit(nr, addr)
#define reiser4_clear_bit(nr, addr) ext2_clear_bit(nr, addr)
#define reiser4_test_bit(nr, addr) ext2_test_bit(nr, addr)
#define reiser4_find_next_zero_bit(addr, maxoffset, offset) \
ext2_find_next_zero_bit(addr, maxoffset, offset)
+#endif
/* Search for a set bit in the bit array [EMAIL PROTECTED], @max_offset[,
offsets
* are counted from @addr, return the offset of the first bit if it is found,
* @maxoffset otherwise. */
-static bmap_off_t reiser4_find_next_set_bit(
+static bmap_off_t __reiser4_find_next_set_bit(
void *addr, bmap_off_t max_offset, bmap_off_t start_offset)
{
ulong_t *base = addr;
@@ -225,6 +256,21 @@
return max_offset;
}
+
+#if BITS_PER_LONG == 64
+
+static bmap_off_t reiser4_find_next_set_bit(
+ void *addr, bmap_off_t max_offset, bmap_off_t start_offset)
+{
+ bmap_off_t off = OFF(addr);
+
+ return __reiser4_find_next_set_bit(BASE(addr), max_offset + off,
start_offset + off) - off;
+}
+
+#else
+#define reiser4_find_next_set_bit(addr, max_offset, start_offset) \
+ __reiser4_find_next_set_bit(addr, max_offset, start_offset)
+#endif
/* search for the first set bit in single word. */
static int find_last_set_bit_in_word (ulong_t word, int start_bit)
Re: AMD64 progress?
On Tue, Feb 08, 2005 at 12:25:58PM -0600, Jake Maciejewski wrote: On Mon, 2005-02-07 at 22:51 +0300, Alex Zarochentsev wrote: On Mon, Feb 07, 2005 at 01:34:56PM -0600, Jake Maciejewski wrote: I'm running reiser4progs 1.0.3 and 2.6.10 patched with reiser4 from 2.6.11-rc3-mm1 (and this patch). I've been doing the simultaneous dd and kernel compilation that has always crashed reiser4 on AMD64 in the past. After about an hour with debugging and two hours without debugging, I'm thinking of more ways to torture the FS. For now it looks like reiser4 is working on AMD64! i think so. reiser4/amd64 passed 5h of stress testing instead of crashing in first 30min. Have you been stress testing with debugging disabled? I was doing some extreme testing and crashed reiser4 with this patch twice. The same test how it crashed? Was the fs corrupted after the crash? that crashed it one of the times passes on reiserfs (didn't try the other), and if enable debugging, I can torture reiser4 all night and still not crash it. I'll do some more tests and try to identify a simple, reproducible crash scenario. Thanks, Alex.
Re: AMD64 progress?
Hello,
On Sat, Jan 15, 2005 at 09:26:01PM -0500, Isaac Chanin wrote:
Also tested this patch, similar results as to what I've been getting -
ie. working for awhile (more than a few hours even this time, but that
could just be coincidence, i suppose) and then going down with the normal
reiser4_find_next_zero_bit(bnode_working_data(bnode), end_offset,
start_offset) = end_offset error. For the exact message see
http://users.wpi.edu/~chanin/r4newpatch.txt.
please try attached patch (it is for fs/reiser4 subtree)
--
Alex.
= plugin/space/bitmap.c 1.186 vs edited =
--- 1.186/plugin/space/bitmap.c Wed Jan 19 18:52:52 2005
+++ edited/plugin/space/bitmap.cMon Feb 7 16:18:37 2005
@@ -165,7 +165,7 @@
static int
find_next_zero_bit_in_word(ulong_t word, int start_bit)
{
- ulong_t mask = 1 start_bit;
+ ulong_t mask = 1UL start_bit;
int i = start_bit;
while ((word mask) != 0) {
@@ -235,7 +235,7 @@
assert (zam-965, start_bit BITS_PER_LONG);
assert (zam-966, start_bit = 0);
- bit_mask = (1 nr);
+ bit_mask = (1UL nr);
while (bit_mask != 0) {
if (bit_mask word)
Re: AMD64 progress?
On Mon, Feb 07, 2005 at 01:34:56PM -0600, Jake Maciejewski wrote: I'm running reiser4progs 1.0.3 and 2.6.10 patched with reiser4 from 2.6.11-rc3-mm1 (and this patch). I've been doing the simultaneous dd and kernel compilation that has always crashed reiser4 on AMD64 in the past. After about an hour with debugging and two hours without debugging, I'm thinking of more ways to torture the FS. For now it looks like reiser4 is working on AMD64! i think so. reiser4/amd64 passed 5h of stress testing instead of crashing in first 30min. How did you track this bug down anyway? Do you have AMD64 hardware, or yes, we have amd64 h/w now. did you look over the code and discover an invalid assumption? I found it only after realizing that reiser4_find_next_set_bit is broken :( (its simple replacement worked fine) If this bug is indeed fixed, are we any closer to inclusion in vanilla? On Mon, 2005-02-07 at 16:29 +0300, Alex Zarochentsev wrote: Hello, On Sat, Jan 15, 2005 at 09:26:01PM -0500, Isaac Chanin wrote: Also tested this patch, similar results as to what I've been getting - ie. working for awhile (more than a few hours even this time, but that could just be coincidence, i suppose) and then going down with the normal reiser4_find_next_zero_bit(bnode_working_data(bnode), end_offset, start_offset) = end_offset error. For the exact message see http://users.wpi.edu/~chanin/r4newpatch.txt. please try attached patch (it is for fs/reiser4 subtree) -- Jake Maciejewski [EMAIL PROTECTED] -- Alex.
Re: Errors reported with dmesg using reiser4
Hello, On Tue, Jan 25, 2005 at 03:28:54PM -0500, [EMAIL PROTECTED] wrote: Hello, for the record, this is from a system running the following specs: Gentoo Linux 2.6.10-gentoo-r6 patched with reiser4-for-2.6.10-1 3ware 7000 series card with 4 SATA 250GB Western Digitial Drives with no raid configured. I am running a test pushing millions of directories onto one of the drives using a UUID as the directory name. These all reside in the base directory of the filesystem. The directories are now being propogated by two python scripts creating random data inside these folders on two of the other drives. When about 1.5gb has collected, they begin moving the folders onto the main drive. This latest test was started last Thursday, with the drive being about 34 GBs full of data from related testing. Since then, the drive has filled to 92GB, but at some point, I discovered the following error: reiser4[mv(28692)]: key_warning (fs/reiser4/plugin/object.c:97)[nikita-717]: WARNING: Error for inode 215673251 (-2) reiser4[mv(28692)]: write_sd_by_inode_common (fs/reiser4/plugin/object.c:480[nikita-2221]: WARNING: Failed to save sd for 215673251: -2 These messages are then repeated nine times. Any suggestions on further checks I can make? can you run fsck.reiser4 --check on that drive? Thank You, Nicolas Smallwood [EMAIL PROTECTED] -- Alex.
Re: shrink reiserfs
Hello, On Sun, Jan 23, 2005 at 08:48:14AM -0700, Jake Hawkes wrote: Hi. resize_reiserfs says that there are already too many allocated blocks. which resize_reiserfs command produces the error message? This isn't the exact error message, but I hope you get the idea. [EMAIL PROTECTED] jake $ df -h FilesystemSize Used Avail Use% Mounted on /dev/hda4 38G 7.1G 31G 20% / /dev/hda2 16G 15G 1.6G 91% /mnt/xp none 506M 0 506M 0% /dev/shm so how can this be possible if it is only 20% used? the shrinker can't make the fs less than 7.1G in size. -- Alex.
Re: shrink reiserfs
On Sun, Jan 23, 2005 at 10:49:56AM -0700, Jake Hawkes wrote: Alex Zarochentsev said: Hello, On Sun, Jan 23, 2005 at 08:48:14AM -0700, Jake Hawkes wrote: Hi. resize_reiserfs says that there are already too many allocated blocks. which resize_reiserfs command produces the error message? resize_reiserfs -v -s -1G /dev/hda4 and when that failed, I tried resize_reiserfs -v -s -1M /dev/hda4 and it failed too? which reiserfsprogs version are you using? It is possible that this bug is fixed already in the latest release of reiserfsprogs (3.6.19). [EMAIL PROTECTED] jake $ df -h FilesystemSize Used Avail Use% Mounted on /dev/hda4 38G 7.1G 31G 20% / /dev/hda2 16G 15G 1.6G 91% /mnt/xp none 506M 0 506M 0% /dev/shm so how can this be possible if it is only 20% used? the shrinker can't make the fs less than 7.1G in size. I had to read that af ew times before I realised you were talking about my installation and not a general reiserfs issue :D given the command above then, what can I do? -- Alex.
Re: shrink reiserfs
On Sun, Jan 23, 2005 at 12:11:36PM -0700, Jake Hawkes wrote: Alex Zarochentsev said: On Sun, Jan 23, 2005 at 10:49:56AM -0700, Jake Hawkes wrote: Alex Zarochentsev said: Hello, On Sun, Jan 23, 2005 at 08:48:14AM -0700, Jake Hawkes wrote: Hi. resize_reiserfs says that there are already too many allocated blocks. which resize_reiserfs command produces the error message? resize_reiserfs -v -s -1G /dev/hda4 and when that failed, I tried resize_reiserfs -v -s -1M /dev/hda4 and it failed too? yep which reiserfsprogs version are you using? It is possible that this bug is fixed already in the latest release of reiserfsprogs (3.6.19). jacobh log # esearch reiserfsprogs [ Results for search key : reiserfsprogs ] [ Applications found : 1 ] * sys-fs/reiserfsprogs Latest version available: 3.6.19 Latest version installed: 3.6.18 Size of downloaded files: [no/bad digest] Homepage:http://www.namesys.com/ Description: Reiserfs Utilities yes, it see, new reiserfsprogs has this bug (v3.0.9 does not :-/) . As a workaround I suggest don't use relative values in current resizer. please try resize_reiserfs -v -s 21G /dev/hda4 . I'm using 3.6.18 Thanks for the report. -- Alex.
Re: shrink reiserfs
On Sun, Jan 23, 2005 at 10:49:18PM +0300, Alex Zarochentcev wrote: On Sun, Jan 23, 2005 at 12:11:36PM -0700, Jake Hawkes wrote: Alex Zarochentsev said: On Sun, Jan 23, 2005 at 10:49:56AM -0700, Jake Hawkes wrote: Alex Zarochentsev said: Hello, On Sun, Jan 23, 2005 at 08:48:14AM -0700, Jake Hawkes wrote: Hi. resize_reiserfs says that there are already too many allocated blocks. which resize_reiserfs command produces the error message? resize_reiserfs -v -s -1G /dev/hda4 and when that failed, I tried resize_reiserfs -v -s -1M /dev/hda4 and it failed too? yep which reiserfsprogs version are you using? It is possible that this bug is fixed already in the latest release of reiserfsprogs (3.6.19). jacobh log # esearch reiserfsprogs [ Results for search key : reiserfsprogs ] [ Applications found : 1 ] * sys-fs/reiserfsprogs Latest version available: 3.6.19 Latest version installed: 3.6.18 Size of downloaded files: [no/bad digest] Homepage:http://www.namesys.com/ Description: Reiserfs Utilities yes, it see, new reiserfsprogs has this bug (v3.0.9 does not :-/) . oops, i can't reproduce the bug anymore, seems i forgot '-' in -s -1G option in my first resize attempt. 3.6.19, 3.6.18 work well for me. As a workaround I suggest don't use relative values in current resizer. please try resize_reiserfs -v -s 21G /dev/hda4 . I'm using 3.6.18 Thanks for the report. -- Alex. -- Alex.
Re: Erased start of voulme...
Hello, On Thu, Jan 13, 2005 at 05:03:30PM -0800, Louis Erickson wrote: I don't know how it happened, but the start of the /var partition of one of the machines I run has gotten itself zeroed out. Only the first little bit - 4k or so - is nulls, then a large amount of very plausible data appears. I can't get reiserfsck to even think this is a reiserfs volume - the program doesn't think this is a reiserfs volume any more. Is there any chance of getting the data back off of this disk? Can reiserfsck be told to look harder and recover more deeply or something? Or is this a lesson in why backups are important? Any suggestions you can give are welcome. reiserfsck --rebuild-sb can re-create the super block. I'm currently running dd from the mangled partition to a file to be able to try some things without losing my only copy of the data. If there's anything special I have to do to make that work, please let me know. Thank you! -- Louis Erickson - [EMAIL PROTECTED] - http://www.rdwarf.com/~wwonko/ Oh Dad! We're ALL Devo! -- Alex.
Re: AMD64 progress?
On Wed, Jan 12, 2005 at 11:33:27PM -0600, Jake Maciejewski wrote:
There was mention of Namesys getting an AMD64 machine. Do you guys have
it yet? Has there been any progress on my reiser4 bug(s), particularly
the reiser4_find_next_zero_bit(bnode_working_data(bnode), end_offset,
start_offset) = end_offset problem?
can you test the following patch? I know that amd64 does not require
strong word aligment, but may be amd64 bitops coded in assembler
do that?
= plugin/space/bitmap.c 1.185 vs edited =
--- 1.185/plugin/space/bitmap.c Sun Dec 5 19:49:52 2004
+++ edited/plugin/space/bitmap.cFri Jan 14 23:15:53 2005
@@ -57,13 +57,15 @@
#define CHECKSUM_SIZE4
+#define BYTES_PER_LONG (sizeof(long))
+
#if BITS_PER_LONG == 64
# define LONG_INT_SHIFT (6)
#else
# define LONG_INT_SHIFT (5)
#endif
-#define LONG_INT_MASK (BITS_PER_LONG - 1)
+#define LONG_INT_MASK (BITS_PER_LONG - 1UL)
typedef unsigned long ulong_t;
@@ -182,12 +184,41 @@
#include asm/bitops.h
+#if BITS_PER_LONG == 64
+
+#define OFF(addr) (((ulong_t)(addr) (BYTES_PER_LONG - 1)) 3)
+#define BASE(addr) ((ulong_t*) ((ulong_t)(addr) ~(BYTES_PER_LONG - 1)))
+
+static inline void reiser4_set_bit(int nr, void * addr)
+{
+ ext2_set_bit(nr + OFF(addr), BASE(addr));
+}
+
+static inline void reiser4_clear_bit(int nr, void * addr)
+{
+ ext2_clear_bit(nr + OFF(addr), BASE(addr));
+}
+
+static inline int reiser4_test_bit(int nr, void * addr)
+{
+ return ext2_test_bit(nr + OFF(addr), BASE(addr));
+}
+static inline int reiser4_find_next_zero_bit(void * addr, int maxoffset, int
offset)
+{
+ int off = OFF(addr);
+
+ return ext2_find_next_zero_bit(BASE(addr), maxoffset + off, offset +
off) - off;
+}
+
+#else
+
#define reiser4_set_bit(nr, addr)ext2_set_bit(nr, addr)
#define reiser4_clear_bit(nr, addr) ext2_clear_bit(nr, addr)
#define reiser4_test_bit(nr, addr) ext2_test_bit(nr, addr)
#define reiser4_find_next_zero_bit(addr, maxoffset, offset) \
ext2_find_next_zero_bit(addr, maxoffset, offset)
+#endif
/* Search for a set bit in the bit array [EMAIL PROTECTED], @max_offset[,
offsets
* are counted from @addr, return the offset of the first bit if it is found,
Re: [reiserfs-list] Severe problem with fsck.reiser4 1.0.3
Hello, On Wed, Jan 12, 2005 at 08:30:09PM +0100, Simon Raffeiner wrote: I managed to boot my Box with Kanotix and this is the result of a mount Operation: reiser4[mount(2457)]: zget (fs/reiser4/znode.c:567)[jmacd-504]: WARNING: Wrong level for cached block 936512: 2 expecting 1 reiser4[mount(2457)]: key_warning (fs/reiser4/plugin/object.c:97)[nikita-717]: WARNING: Error for inode 42 (-5) isn't your system amd64? This is exactly the same error as Kernel 2.6.9-mm1 and 2.6.10-mm1 display when I try to boot Gentoo Linux, with 2.6.10-mm1 showing a slightly different behaviour: It tries to remount the root partition 10 times and than fails (displaying the error message from above 10 times), 2.6.9-mm1 fails after the first mount attempt. Could this be due to a faulty hard drive (it's about 3 years old and has been heavily used) or is it some kind of file system corruption? In the second case please fix reiser4progs to deal with such errors and make fsck.reiser4 fix it so I can get my machine back up working. do you mean that fsck.reiser4 reports that no fs corruption found? Regards, Simon Raffeiner -- Alex.
Re: ftp.namesys.com: connection refused
On Sat, Jan 08, 2005 at 07:05:07AM +0100, Lars Tobias B?rsting wrote: Hi, I have been trying to download the patch for the 2.6.10 kernel from ftp.namesys.com but I get connection refused from the server: % ncftp ftp.namesys.com NcFTP 3.0.3 (April 15, 2001) by Mike Gleason ([EMAIL PROTECTED]). Could not connect to 212.16.7.65: Connection refused. Sleeping 17 seconds... Is there anyone of you who can connect to the ftp server? And does anyone know a secondary place to download the latest patches? it works now. the storage is also accessible through http://ftp.namesys.com/pub/ Regards, -- Lars Tobias B?rsting -- Alex.
Re: Congratulations! we have got hash function screwed up
Hello, On Tue, Dec 28, 2004 at 11:12:18PM +0100, Marc A. Lehmann wrote: Hi! When trying to upgrade or reinstall the xfonts-75dpi, xfonts-75dpi-transcoded or 100dpi transcoded debian packages on my 2.6.10-rc3 amd64 reiserfsv3 host, I get the following errors: dpkg: error processing /var/cache/apt/archives/xfonts-75dpi_4.3.0.dfsg.1-10_all.deb (--unpack): unable to make backup link of `./usr/X11R6/lib/X11/fonts/75dpi/lutBS19-ISO8859-1.pcf.gz' before installing new version: Device or resource busy dpkg-deb: subprocess paste killed by signal (Broken pipe) Preparing to replace xfonts-75dpi-transcoded 4.3.0.dfsg.1-10 (using .../xfonts-75dpi-transcoded_4.3.0.dfsg.1-10_all.deb) ... dpkg: error processing /var/cache/apt/archives/xfonts-75dpi-transcoded_4.3.0.dfsg.1-10_all.deb (--unpack): unable to make backup link of `./usr/X11R6/lib/X11/fonts/75dpi/lutBS19-ISO8859-10.pcf.gz' before installing new version: Device or resource busy dpkg-deb: subprocess paste killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/xfonts-75dpi_4.3.0.dfsg.1-10_all.deb /var/cache/apt/archives/xfonts-75dpi-transcoded_4.3.0.dfsg.1-10_all.deb And at the same time, I get this in my kernel log: ReiserFS: hdg2: warning: reiserfs_add_entry: Congratulations! we have got hash function screwed up Sure sounds like a filesystem bug to me. Is this 2.6.10-rc3-specific or a generic bug in handling hash collisions? Tea hash is designed to be more resistant. there is a generic problem with overloading of the generation counter, but tea hash should mix file names better and have less chances to 'screw the hash function up'. Does the debian install all X font files into one dir? May be you have your own font files installed in the same dir? I suggest to split the dir into several ones. Deleteing the fonts and installing the package works, but the next upgrade makes the error appear again. -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE -- Alex.
Re: reiser4 and apache (was: Re: Reiser4 and ZFS)
Hi, On Tue, Dec 28, 2004 at 12:12:39PM +0100, Sander wrote: [EMAIL PROTECTED] wrote (ao): On Mon, 27 Dec 2004 13:28:15 +0100, Sander said: [EMAIL PROTECTED] wrote (ao): For many shops, it's quite likely that a ZFS with more scalability and administration is The Right Choice, especially if it does *NOT* include lots of odd new features and quirks that might break production code (remember the joys in getting Apache running on reiser4, until it was discovered that the 'file-as-directory' stuff broke programs that weren't expecting it?). I just got bitten by this. Is it possible to get apache to run on reiser4, and if so, how? I think the archives have pointers to both a reiser4 patch that disables the file as directory, and a patch to apache to deal with the situation... I can't find it in the archives, nor with google or on the Namesys website (namely download, getting started with v4, and the FAQ). I did find this mail from Hans about the issue and his request for a patch for apache: http://www.dragoninc.on.ca/mail-archives/reiserfs/2004-08/0583.html That thread doesn't contain a patch unfortunately. Can somebody please point me to a patch to disable the file as a directory feature? it is disabled in the recent reiser4 code. mount options 'nopseudo' should work for older versions. Hans, would this be something for a mount option? And shouldn't more info on this be on the website? Thanks in advance. -- Alex.
Re: making reiser4/AMD64 hardlock
Hi
On Tue, Dec 07, 2004 at 03:46:58PM -0600, Jake Maciejewski wrote:
With this patch get
reiser4[cc1(10284)]: check_blocks_bitmap
(fs/reiser4/plugin/space/bitmap.c:1174)[zam-623]:
code: -2 at fs/reiser4/search.c:1285
reiser4 panicked cowardly: assertion failed:
reiser4_find_next_zero_bit(bnode_working_data(bnode), end_offset,
start_offset) = end_offset
did you begin the tests with mkfs.reiser4 /dev/ ?
details at
http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/12-07-04/zam-patch/
which is pretty much the same thing documented in 11-20-04/sync_mount/ ,
11-10-04/with_bitmap.c.diff/ , 11-09-04/ , 11-08-04/test2/ ,
11-04-04/all-R4/ , and 11-04-04/R3-R4/
When I also used Vladimir's 10 Nov 2004 19:08:47 +0300 bitmap.c.diff,
my logs filled (~1.7 million lines) with
WARNING: Wrong level found in node: 1 != 0
reiser4[cc1(11554)]: parse_node40
(fs/reiser4/plugin/node/node40.c:767)[nikita-494]:
code: -2 at fs/reiser4/search.c:1312
see 12-07-04/both-patches/
The only other time I've seen an error like this was 11-08-04/test1/
repeating
WARNING: Failed to delete file body 84672
reiser4[make(22140)]: parse_node40
(fs/reiser4/plugin/node/node40.c:767)[nikita-494]:
code: -2 at fs/reiser4/search.c:1278
If you want, I'll run it again and probably hit the
reiser4_find_next_zero_bit error instead. I didn't bother with
fsck.reiser4 --build-fs and --check because now that I think about it,
this isn't the sort of thing fsck needs to be able to fix. If fsck
should be able to handle these cases, someone speak up and I'll provide
more reports like 11-20-04/sync_mount/corruption/.
On Tue, 2004-12-07 at 15:20 +0300, Alex Zarochentsev wrote:
On Wed, Nov 10, 2004 at 01:45:40PM -0600, Jake Maciejewski wrote:
Does this show what you want?
http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/11-10-04/with_bitmap.c.diff/
Please apply the patch below. it definitely fixes one reiser4/amd64 bug.
= plugin/space/bitmap.c 1.183 vs edited =
--- 1.183/plugin/space/bitmap.c Wed Oct 13 17:22:01 2004
+++ edited/plugin/space/bitmap.cSun Dec 5 00:18:55 2004
@@ -170,7 +170,7 @@
static int
find_next_zero_bit_in_word(ulong_t word, int start_bit)
{
- unsigned int mask = 1 start_bit;
+ ulong_t mask = 1 start_bit;
int i = start_bit;
while ((word mask) != 0) {
@@ -234,7 +234,7 @@
/* search for the first set bit in single word. */
static int find_last_set_bit_in_word (ulong_t word, int start_bit)
{
- unsigned bit_mask;
+ ulong_t bit_mask;
int nr = start_bit;
assert (zam-965, start_bit BITS_PER_LONG);
--
Jake Maciejewski [EMAIL PROTECTED]
--
Alex.
Re: making reiser4/AMD64 hardlock
On Wed, Nov 10, 2004 at 01:45:40PM -0600, Jake Maciejewski wrote:
Does this show what you want?
http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/11-10-04/with_bitmap.c.diff/
Please apply the patch below. it definitely fixes one reiser4/amd64 bug.
= plugin/space/bitmap.c 1.183 vs edited =
--- 1.183/plugin/space/bitmap.c Wed Oct 13 17:22:01 2004
+++ edited/plugin/space/bitmap.cSun Dec 5 00:18:55 2004
@@ -170,7 +170,7 @@
static int
find_next_zero_bit_in_word(ulong_t word, int start_bit)
{
- unsigned int mask = 1 start_bit;
+ ulong_t mask = 1 start_bit;
int i = start_bit;
while ((word mask) != 0) {
@@ -234,7 +234,7 @@
/* search for the first set bit in single word. */
static int find_last_set_bit_in_word (ulong_t word, int start_bit)
{
- unsigned bit_mask;
+ ulong_t bit_mask;
int nr = start_bit;
assert (zam-965, start_bit BITS_PER_LONG);
Re: AMD64/Reiser4 testing and problems
Hello Isaac
On Thu, Dec 02, 2004 at 06:13:39PM -0500, Isaac Chanin wrote:
Hi,
I did some testing with Resier4 on AMD and was wondering if perhaps
debug information or anything on this could help with getting Resier4
stable and working on AMD64.
I have read that if AMD would give an AMD64 cpu that would be a big
help, but it doesn't seem inheriantly impossible to fix the problem from
error reports and such.
Anyways, here are the results for my testing. I used a mm 2.6.10-rc2
kernel and the filesystem was in a file mounted by loopback.
http://users.wpi.edu/~chanin/r4log.txt
thanks a lot for the report. can you try the following patch?
= plugin/space/bitmap.c 1.183 vs edited =
--- 1.183/plugin/space/bitmap.c Wed Oct 13 17:22:01 2004
+++ edited/plugin/space/bitmap.cSun Dec 5 00:18:55 2004
@@ -170,7 +170,7 @@
static int
find_next_zero_bit_in_word(ulong_t word, int start_bit)
{
- unsigned int mask = 1 start_bit;
+ ulong_t mask = 1 start_bit;
int i = start_bit;
while ((word mask) != 0) {
@@ -234,7 +234,7 @@
/* search for the first set bit in single word. */
static int find_last_set_bit_in_word (ulong_t word, int start_bit)
{
- unsigned bit_mask;
+ ulong_t bit_mask;
int nr = start_bit;
assert (zam-965, start_bit BITS_PER_LONG);
Re: Oops with large file in 2.6.8, reiser 3.6.13
Hello,
On Fri, Oct 29, 2004 at 10:55:36AM +0100, Richard Gregory wrote:
Hi Alex,
That fixed it. I created a 617gig file that filled the filesystem. It
then deleted without a problem. The delete took a long time, but at
least it got there.
Thanks a lot. Your reply is what we needed to make a correct fix.
Thanks,
Richard
Alex Zarochentsev wrote:
Hello,
please try the following patch (it is for 2.6.6,
but i expect it to work with 2.6.8):
=
--- linux-2.6.6/fs/reiserfs/stree.c.orig 2004-10-23
16:43:11.412335592 +0400
+++ linux-2.6.6/fs/reiserfs/stree.c 2004-10-23 17:09:36.983292168 +0400
@@ -1721,8 +1721,14 @@ void reiserfs_do_truncate (struct reiser
set_cpu_key_k_offset (s_item_key, n_file_size);
do {
+loff_t to_size;
+
+to_size = n_file_size - (p_s_inode-i_sb-s_blocksize * 2);
+if (to_size n_new_file_size)
+to_size = n_new_file_size;
+
/* Cut or delete file item. */
-n_deleted = reiserfs_cut_from_item(th, s_search_path, s_item_key,
p_s_inode, page, n_new_file_size);
+n_deleted = reiserfs_cut_from_item(th, s_search_path, s_item_key,
p_s_inode, page, to_size);
if (n_deleted 0) {
reiserfs_warning (vs-5665: reiserfs_do_truncate:
reiserfs_cut_from_item failed);
reiserfs_check_path(s_search_path) ;
@@ -1731,7 +1737,7 @@ void reiserfs_do_truncate (struct reiser
RFALSE( n_deleted n_file_size,
PAP-5670: reiserfs_cut_from_item: too many bytes deleted:
deleted %d, file_size %lu, item_key %K,
-n_deleted, n_file_size, s_item_key);
+n_deleted, to_size, s_item_key);
/* Change key to search the last file item. */
n_file_size -= n_deleted;
@@ -1747,7 +1753,7 @@ void reiserfs_do_truncate (struct reiser
** sure the file is consistent before ending the current trans
** and starting a new one
*/
-if (journal_transaction_should_end(th, th-t_blocks_allocated)) {
+if (1 || journal_transaction_should_end(th,
th-t_blocks_allocated)) {
int orig_len_alloc = th-t_blocks_allocated ;
decrement_counters_in_path(s_search_path) ;
=
On Tue, Oct 19, 2004 at 01:28:20PM +0100, Richard Gregory wrote:
Have managed to create an Oops in the reiser code, dmesg output below.
This was on a software raid5 setup, with 8 160Gb disks, creating around
1.1Tb of storage. There was around 400Gb of content on this filesystem,
then as an over night test, /dev/zero was dd'ed to a file on the
filesystem, creating an approx 720Gb file and filling the filesystem.
The problem came when I tried to delete it, rm'ing it caused an Oops in
the reiser code. The system was rebooted, but mounting the filesystem
gave the oops below.
Am currently running reiserfsck --check to see if this file can be
removed some other way, otherwise, it will mean a very long reformat and
copy operation.
Something else, this filesystem had recently been resized from 960Gb to
the 1.1Tb with the addition of the eighth drive. This is on a FC2 based
install, Duron 833, 256 meg.
Richard
ReiserFS: md0: found reiserfs format 3.6 with standard journal
ReiserFS: md0: using ordered data mode
ReiserFS: md0: journal params: device md0, size 8192, journal first
block 18, max trans len 1024, max batch 900, max commit age 30, max
trans age 30
ReiserFS: md0: checking transaction log (md0)
ReiserFS: md0: replayed 3 transactions in 18 seconds
ReiserFS: md0: Using r5 hash to sort names
ReiserFS: md0: Removing [2 1282214 0x0 SD]..0REISERFS: panic (device
md0): journal-1413: journal_mark_dirty: j_len (1024) is too big
[ cut here ]
kernel BUG at fs/reiserfs/prints.c:362!
invalid operand: [#1]
Modules linked in: raid5 xor iteraid sd_mod autofs4 r8169 sg scsi_mod
dm_mod uhci_hcd button battery asus_acpi ac ext3 jbd
CPU:0
EIP:0060:[c019416a]Not tainted
EFLAGS: 00010292 (2.6.8-1.521custom)
EIP is at reiserfs_panic+0x4a/0x70
eax: 005c ebx: c03422a8 ecx: c0380f78 edx: c0380f78
esi: c13b1e00 edi: c13b1f2c ebp: c13b1e00 esp: cc852950
ds: 007b es: 007b ss: 0068
Process mount (pid: 1204, threadinfo=cc852000 task=cccb2310)
Stack: c0347a48 c13b1f2c c0419c60 cc852d1c ca5a59a0 c01a28f8
c13b1e00
c03498dc 0400 c13b1e00 c019e589 17bc d08f50e4 7fff
c13b1e00
7fff c13b1e00 17bc 0bde7fff c017e384 cc852a20
c95ee018
Call Trace:
[c01a28f8] journal_mark_dirty+0x288/0x2a0
[c019e589] get_bitmap_node+0x39/0xa0
[c017e384] _reiserfs_free_block+0xf4/0x180
[c019ac35] prepare_for_delete_or_cut+0x515/0x710
[c0190d61] unfix_nodes+0x61/0x140
[c019bbbc] reiserfs_cut_from_item+0xac/0x4f0
[c019c2fc] reiserfs_do_truncate+0x26c/0x520
[c019b6bb] reiserfs_delete_object+0x2b/0x60
[c0185777
Re: when will it end?
On Tue, Oct 26, 2004 at 07:57:36PM -0500, David Masover wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have 512 megs of RAM and one 200 gig hard drive (effectively 177 gig filesystem) that is 86% full. I started the reiser4 repacker two days ago, with very minimal system use since then (an hour or two a day of playing music and reading email). See below for my df and top. 200GB / 48 / 3600 ~= 1MB/sec, right? I think it is a bug. Hopefully, after some developing efforts, the repacker whould work faster. -- Alex.
Re: when will it end?
On Tue, Oct 26, 2004 at 07:57:36PM -0500, David Masover wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have 512 megs of RAM and one 200 gig hard drive (effectively 177 gig filesystem) that is 86% full. I started the reiser4 repacker two days ago, with very minimal system use since then (an hour or two a day of playing music and reading email). See below for my df and top. Thankfully, the kernel seems intelligent enough about memory management that once things other than Doom 3 start, they run reasonably smoothly, even video (must be that anticipatory IO scheduler). Three questions: When will it end? How can I kill it if I get sick of waiting? try this: echo 0 /sys/fs/riser4/hda5/repacker/start Is it conceivable that the repacker could be optimized to run faster? current repacker code state is 'unsupported', it is even removed from the latest -mm kernels. Namesys plans are to make the repacker proprietary. -- Alex.
Re: Oops with large file in 2.6.8, reiser 3.6.13
Hello,
please try the following patch (it is for 2.6.6,
but i expect it to work with 2.6.8):
=
--- linux-2.6.6/fs/reiserfs/stree.c.orig2004-10-23 16:43:11.412335592 +0400
+++ linux-2.6.6/fs/reiserfs/stree.c 2004-10-23 17:09:36.983292168 +0400
@@ -1721,8 +1721,14 @@ void reiserfs_do_truncate (struct reiser
set_cpu_key_k_offset (s_item_key, n_file_size);
do {
+ loff_t to_size;
+
+ to_size = n_file_size - (p_s_inode-i_sb-s_blocksize * 2);
+ if (to_size n_new_file_size)
+ to_size = n_new_file_size;
+
/* Cut or delete file item. */
- n_deleted = reiserfs_cut_from_item(th, s_search_path, s_item_key, p_s_inode,
page, n_new_file_size);
+ n_deleted = reiserfs_cut_from_item(th, s_search_path, s_item_key, p_s_inode,
page, to_size);
if (n_deleted 0) {
reiserfs_warning (vs-5665: reiserfs_do_truncate: reiserfs_cut_from_item
failed);
reiserfs_check_path(s_search_path) ;
@@ -1731,7 +1737,7 @@ void reiserfs_do_truncate (struct reiser
RFALSE( n_deleted n_file_size,
PAP-5670: reiserfs_cut_from_item: too many bytes deleted: deleted %d,
file_size %lu, item_key %K,
- n_deleted, n_file_size, s_item_key);
+ n_deleted, to_size, s_item_key);
/* Change key to search the last file item. */
n_file_size -= n_deleted;
@@ -1747,7 +1753,7 @@ void reiserfs_do_truncate (struct reiser
** sure the file is consistent before ending the current trans
** and starting a new one
*/
-if (journal_transaction_should_end(th, th-t_blocks_allocated)) {
+if (1 || journal_transaction_should_end(th, th-t_blocks_allocated)) {
int orig_len_alloc = th-t_blocks_allocated ;
decrement_counters_in_path(s_search_path) ;
=
On Tue, Oct 19, 2004 at 01:28:20PM +0100, Richard Gregory wrote:
Have managed to create an Oops in the reiser code, dmesg output below.
This was on a software raid5 setup, with 8 160Gb disks, creating around
1.1Tb of storage. There was around 400Gb of content on this filesystem,
then as an over night test, /dev/zero was dd'ed to a file on the
filesystem, creating an approx 720Gb file and filling the filesystem.
The problem came when I tried to delete it, rm'ing it caused an Oops in
the reiser code. The system was rebooted, but mounting the filesystem
gave the oops below.
Am currently running reiserfsck --check to see if this file can be
removed some other way, otherwise, it will mean a very long reformat and
copy operation.
Something else, this filesystem had recently been resized from 960Gb to
the 1.1Tb with the addition of the eighth drive. This is on a FC2 based
install, Duron 833, 256 meg.
Richard
ReiserFS: md0: found reiserfs format 3.6 with standard journal
ReiserFS: md0: using ordered data mode
ReiserFS: md0: journal params: device md0, size 8192, journal first
block 18, max trans len 1024, max batch 900, max commit age 30, max
trans age 30
ReiserFS: md0: checking transaction log (md0)
ReiserFS: md0: replayed 3 transactions in 18 seconds
ReiserFS: md0: Using r5 hash to sort names
ReiserFS: md0: Removing [2 1282214 0x0 SD]..0REISERFS: panic (device
md0): journal-1413: journal_mark_dirty: j_len (1024) is too big
[ cut here ]
kernel BUG at fs/reiserfs/prints.c:362!
invalid operand: [#1]
Modules linked in: raid5 xor iteraid sd_mod autofs4 r8169 sg scsi_mod
dm_mod uhci_hcd button battery asus_acpi ac ext3 jbd
CPU:0
EIP:0060:[c019416a]Not tainted
EFLAGS: 00010292 (2.6.8-1.521custom)
EIP is at reiserfs_panic+0x4a/0x70
eax: 005c ebx: c03422a8 ecx: c0380f78 edx: c0380f78
esi: c13b1e00 edi: c13b1f2c ebp: c13b1e00 esp: cc852950
ds: 007b es: 007b ss: 0068
Process mount (pid: 1204, threadinfo=cc852000 task=cccb2310)
Stack: c0347a48 c13b1f2c c0419c60 cc852d1c ca5a59a0 c01a28f8
c13b1e00
c03498dc 0400 c13b1e00 c019e589 17bc d08f50e4 7fff
c13b1e00
7fff c13b1e00 17bc 0bde7fff c017e384 cc852a20
c95ee018
Call Trace:
[c01a28f8] journal_mark_dirty+0x288/0x2a0
[c019e589] get_bitmap_node+0x39/0xa0
[c017e384] _reiserfs_free_block+0xf4/0x180
[c019ac35] prepare_for_delete_or_cut+0x515/0x710
[c0190d61] unfix_nodes+0x61/0x140
[c019bbbc] reiserfs_cut_from_item+0xac/0x4f0
[c019c2fc] reiserfs_do_truncate+0x26c/0x520
[c019b6bb] reiserfs_delete_object+0x2b/0x60
[c0185777] reiserfs_delete_inode+0xb7/0x100
[c011a587] printk+0xf7/0x140
[c01856c0] reiserfs_delete_inode+0x0/0x100
[c015eb04] generic_delete_inode+0x74/0xf0
[c015ecdc] iput+0x4c/0x60
[c01912f5] finish_unfinished+0x1c5/0x310
[c0154e09] __lookup_hash+0x89/0xb0
[c01a29a6] journal_end+0x96/0xc0
[c01931ba] reiserfs_fill_super+0x4da/0x640
[c0187ef0]
Re: Â 2.6.9-mm1
Hi, On Sat, Oct 23, 2004 at 12:39:57PM -0700, Andrew Morton wrote: Hilzinger Marcel [EMAIL PROTECTED] wrote: SuSE Linux 9.2 will contain reiser4 hm. Nobody ever tells me anything. Does that mean that SuSE are using 8k stacks? We have several reiser4/4KSTACKS successful reports. However, enabling reiser4 debugging and, probably, using reiser4 over dmapper, make things less stable. -- Alex.
Re: [PATCH] ReiserFS v3 I/O error handling
On Wed, Sep 22, 2004 at 08:39:06AM -0700, Hans Reiser wrote: Chris Mason wrote: On Wed, 2004-09-15 at 10:31, Hans Reiser wrote: Jeff Mahoney wrote: Alex Zarochentsev wrote: | I assume that was tested with some simulated i/o errors, wasn't it?. Of course. The debugging code is since removed, but every place there was a !buffer_uptodate(bh) check, I added a trigger such that I could trigger each error path individually. I triggered various error paths while running fsx, stress.sh, and/or ltp's fsstress. Your patch is much needed stuff. Would be nice to see it for reiser4 someday.;-) ;-) Any objections if we start by sending this to Andrew for v3? no objections. -chris I'll let zam answer for me. -- Alex.
Re: repacker ?
On Tue, Sep 21, 2004 at 09:36:09AM +0800, Thomas Graham wrote: hey all, I might miss some of the info, what is echo 1 .../direction use for ? I know echo 1 for repacker, but what is direction ? Thanks. the repacker scans whole reiser4 internal tree and repacks/relocates nodes. .../direction controls whether the repacker scans the tree forward (from smallest key to the biggest one, direction=0) or backward (direction=1). see also http://namesys.com/v4/v4.html#repacker -- HK Celtic Orchestra leader and coordanator: Thomas Graham Lau Phone number: 852-93239670(24hours a day, 7days a week non-stop phone) Web site: http://sml.dyndns.org Email: [EMAIL PROTECTED] -- Alex.
Re: Repacker cause fs corruption:
On Tue, Sep 14, 2004 at 10:59:08AM +0200, Spam wrote: I tried the resier4 repacker yesterday on a 2GB device that I use for /usr/portage in Gentoo. This morning I found these errors in the kernel log: Thanks for the report. How did you start the repacker? which direction did you run it in? ## Repacker: I am alive, pid = 32717 reiser4[k_reiser4_repac(32717)]: renew_sibling_link (fs/reiser4/tree_walk.c:441)[nikita-3532]: WARNING: Sibling nodes on the different levels: 1 != 1 reiser4 repacker: 659 formatted node(s) processed, 170984 unformatted node(s) processed, ret = -5 We have similar bug report, but no information that the breakage was connected to the repacker. ## I did a fsck. This is the output from this: ## * fsck.reiser4 started at Tue Sep 14 10:30:09 2004 Reiser4 journal (journal40) on usr_portage.loop: 0 transactions replayed of the total 0 blocks. Reiser4 fs was detected on usr_portage.loop. Master super block (16): magic: ReIsEr4 blksize:4096 format: 0x0 (format40) uuid: fb81301f-8994-49db-a70a-02d1dcb1ad4c label: usr_portage Format super block (17): plugin: format40 description:Disk-format for reiser4, ver. 1.0.1 magic: ReIsEr40FoRmAt flushes:0 mkfs id:0x6624937f blocks: 524288 free blocks:359376 root block: 152472 tail policy:0x2 (smart) next oid: 0x3041e file count: 96887 tree height:4 key policy: LARGE CHECKING STORAGE TREE FSCK: Node (89186): The last key [15a4b:4(FB):6c657373746966:15a4f:45d] in the node is greater then the right delimiting key [15a4b:4(FB):4368616e67654c:15a50:5aa]. FSCK: Node (152380), item (74), unit (0): Points to the node [89186] with wrong delimiting keys. The whole subtree is skipped. Read nodes 23702 Nodes left in the tree 23701 Leaves of them 23321, Twigs of them 373 Nodes with wrong delimiting keys 1 Leaves of them 1, Twigs of them 0 Time interval: Tue Sep 14 10:30:11 2004 - Tue Sep 14 10:33:23 2004 CHECKING EXTENT REGIONS. Read twigs 373 Time interval: Tue Sep 14 10:33:24 2004 - Tue Sep 14 10:33:31 2004 Warn : Fatal corruptions were found. Semantic pass is skipped. * fsck.reiser4 finished at Tue Sep 14 10:33:31 2004 Closing fs...done 1 fatal corruptions were detected in FileSystem. Run with --build-fs option to fix them. ## Here follows the output from --build-fs: ## * fsck.reiser4 started at Tue Sep 14 10:35:37 2004 Reiser4 journal (journal40) on usr_portage.loop: 0 transactions replayed of the total 0 blocks. Reiser4 fs was detected on usr_portage.loop. Master super block (16): magic: ReIsEr4 blksize:4096 format: 0x0 (format40) uuid: fb81301f-8994-49db-a70a-02d1dcb1ad4c label: usr_portage Format super block (17): plugin: format40 description:Disk-format for reiser4, ver. 1.0.1 magic: ReIsEr40FoRmAt flushes:0 mkfs id:0x6624937f blocks: 524288 free blocks:359376 root block: 152472 tail policy:0x2 (smart) next oid: 0x3041e file count: 96887 tree height:4 key policy: LARGE CHECKING STORAGE TREE FSCK: Node (89186): The last key [15a4b:4(FB):6c657373746966:15a4f:45d] in the node is greater then the right delimiting key [15a4b:4(FB):4368616e67654c:15a50:5aa]. FSCK: Node (152380), item (74), unit (0): Points to the node [89186] with wrong delimiting keys. Removed, content will be inserted later item-by-item. Read nodes 23702 Nodes left in the tree 23701 Leaves of them 23321, Twigs of them 373 Nodes with wrong delimiting keys 1 Leaves of them 1, Twigs of them 0 Time interval: Tue Sep 14 10:35:39 2004 - Tue Sep 14 10:41:01 2004 CHECKING EXTENT REGIONS. Read twigs 373 Time interval: Tue Sep 14 10:41:15 2004 - Tue Sep 14 10:41:25 2004 LOOKING FOR UNCONNECTED NODES Read nodes 0 Good nodes 0 Leaves of them 0, Twigs of them 0 Time interval: Tue Sep 14 10:41:32 2004 - Tue Sep 14 10:41:32 2004 CHECKING EXTENT REGIONS. Read twigs 0 Time interval: Tue Sep 14 10:41:32 2004 - Tue Sep 14 10:41:32 2004 INSERTING UNCONNECTED NODES 1. Twigs: done 2. Twigs by item: done 3. Leaves: done 4. Leaves by item: done Twigs: read 0, inserted 0, by item 0, empty 0 Leaves: read 0, inserted 0, by item 0 Time interval: Tue Sep 14 10:41:38 2004 - Tue Sep 14 10:41:38 2004
Re: Repacker cause fs corruption:
On Tue, Sep 14, 2004 at 12:08:31PM +0200, Spam wrote: On Tue, Sep 14, 2004 at 10:59:08AM +0200, Spam wrote: I tried the resier4 repacker yesterday on a 2GB device that I use for /usr/portage in Gentoo. This morning I found these errors in the kernel log: Thanks for the report. How did you start the repacker? which direction did you run it in? The direction is 0. I started by issuing: echo 1 /sys/fs/reiser4/loop0/repacker/start It looks like the repacker triggers a bug in reiser4. the forward run does not modify reiser4 nodes by itself. ~S ## Repacker: I am alive, pid = 32717 reiser4[k_reiser4_repac(32717)]: renew_sibling_link (fs/reiser4/tree_walk.c:441)[nikita-3532]: WARNING: Sibling nodes on the different levels: 1 != 1 reiser4 repacker: 659 formatted node(s) processed, 170984 unformatted node(s) processed, ret = -5 -- Alex.
Re: EACCESS vs ENOENT for nonexistent files-within-files
On Mon, Sep 13, 2004 at 03:06:37PM +0100, Joe Orton wrote:
Hi, we had a bug report that Apache httpd logs a spurious error for
every file served from a reiser4 filesystem, because httpd assumes that
/path/to/file/.htaccess (where /path/to/file is a normal file) returns
ENOENT or ENOTDIR, but reiser4 returns EACCES in this case.
Can someone explain the justification behind reiser4's behaviour?
httpd's assumption does not seem unreasonable, and EACCES seems to make
little sense for this error case.
It is because open(name, O_DIRECTORY) is successful for regular files in
reiser4. Once it succedes, Apache2 thinks that is a directory and tries to
open .htaccess under it. It does not matter what error code is receives there,
the problem is that apache2 has decided that the file is a directory.
There are two solutions:
1) mount reiser4 partition with nopseudo mount option. it makes /metas/* files
unaccessible.
2) apply the patch:
= fs/namei.c 1.104 vs edited =
--- 1.104/fs/namei.cTue Aug 10 16:59:38 2004
+++ edited/fs/namei.c Sun Sep 12 11:00:18 2004
@@ -816,7 +816,7 @@
break;
if (lookup_flags LOOKUP_DIRECTORY) {
err = -ENOTDIR;
- if (!inode-i_op || !inode-i_op-lookup)
+ if (!S_ISDIR(inode-i_mode))
break;
}
goto return_base;
===
Regards,
joe
--
Alex.
Re: EACCESS vs ENOENT for nonexistent files-within-files
On Mon, Sep 13, 2004 at 07:52:55PM +0100, Joe Orton wrote: On Mon, Sep 13, 2004 at 08:13:26PM +0400, Alex Zarochentsev wrote: On Mon, Sep 13, 2004 at 03:06:37PM +0100, Joe Orton wrote: Hi, we had a bug report that Apache httpd logs a spurious error for every file served from a reiser4 filesystem, because httpd assumes that /path/to/file/.htaccess (where /path/to/file is a normal file) returns ENOENT or ENOTDIR, but reiser4 returns EACCES in this case. what does the user get in the browser? Can someone explain the justification behind reiser4's behaviour? httpd's assumption does not seem unreasonable, and EACCES seems to make little sense for this error case. It is because open(name, O_DIRECTORY) is successful for regular files in reiser4. Once it succedes, Apache2 thinks that is a directory and tries to open .htaccess under it. I don't think that has anything to do with it. It's a simple open() without O_DIRECTORY which is failing with EACCES. The reporter confirmed this with the simplest of tests: $ touch newfile.txt $ cat newfile.txt/.htaccess cat: newfile.txt/.htaccess: Permission denied But what is the reason why apache2 looks at regular file/.htaccess ? can you ask the user to add execute permitions (just for test) to the file and see would apache2 work with the file. this is the behaviour I'm trying to find the justification for. There are two solutions: 1) mount reiser4 partition with nopseudo mount option. it makes /metas/* files unaccessible. If this is broken by default, our users will continue to complain, so that doesn't really help. 2) apply the patch: OK, does this mean you do consider this a bug in reiser4 which will be fixed in future releases, then? it requires Linux VFS changes, the changes are being discussed in LKML still. Regards, joe -- Alex.
Re: Squid eating up all CPU
On Tue, Sep 07, 2004 at 04:50:46PM +0300, Raymond A. Meijer wrote: On Tue 7 September 2004 15:52, Alex Zarochentsev wrote: Hi Alex, Everything seems to work well, except..the Squid process is eating up all CPU: PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 4787 proxy 39 0 45700 10m 2580 R 87.7 1.4 7:12.94 squid can you boot the kernel with profile=2 boot parameter and get profile info for the period when nothing except squid is active? echo 1 /proc/profile sleep 300 cat /proc/profile | readprofile -m [actual system map file | sort -rn | head -n 20 I think reiser4 should be built not as a module otherwise System.map would not contain reiser4 symbols. I don't think Reiser4 is at fault here: I found out that the Weatherfox plugin for Firefox had caused Firefox to crash, and therefore every time I started Firefox the Quality Feedback Agent tried to send a message. For some reason that didn't work, and the following entries showed up in Squid's access.log after a LONG time: 1094561818.215 1041126 127.0.0.1 TCP_MISS/504 1467 POST http://talkback.mozilla.org/spiral-bin/Collector.dll - DIRECT/207.126.111.208 text/html 1094561860.054 1004601 127.0.0.1 TCP_MISS/504 1467 POST http://talkback.mozilla.org/spiral-bin/Collector.dll - DIRECT/207.126.111.208 text/html 1094561860.054 945630 127.0.0.1 TCP_MISS/504 1467 POST http://talkback.mozilla.org/spiral-bin/Collector.dll - DIRECT/207.126.111.208 text/html Apparently the QFA continued to do this even after closing both its window and Firefox, without any relevant processes showing up with ps..?! Does this sound familiar? there should be the QFA process, I think. After I uninstalled the Weatherfox extension the symptoms disappeared. I'll try to reproduce it though.. Ray -- Alex.
Re: reiser4 plugins
On Fri, Aug 27, 2004 at 10:55:50PM +0400, Nikita Danilov wrote: Hans Reiser writes: Nikita Danilov wrote: Hans Reiser writes: Christophe Saout wrote: I don't know, ask Hans. How could the VFS know it a filesystem wants to do something specific with a file that is completely transparent to the VFS? To know what method to use, you must determine the pluginid, and then find the method within that plugin for that vfs operation. As for overhead, well, who eats whose dust in the benchmarks? Whoever sponsors the benchmark usually wins. Had you forgotten that mongo setup used by http://www.namesys.com/benchmarks.html was specially `tuned' to reach peak reiser4 performance? Remember why you decided to turn OVERWRITE and MODIFY phases off? People on #reiser4 report 90 _second_ stalls with reiser4 under high io loads (large atom is obviously being flushed and everyone waits on it...). In my opinion, it is such things that are of utmost importance for real reiser4 acceptance, not how to name `metas' sub-directory. Nikita. If you ask real users, they say that reiser4 is fast, and their experience matches our benchmark. You can criticize the benchmark if They experience 90 second stalls. And please, do not tell me how fast reiser4 is, I spent a lot of time working with it, and I know very well when it's fast, and when it's deadly slow. you want, but then you should run your own and publish it. I did, after which you told me to turn OVERWRITE and MODIFY phases off, beause performance was horrible. Hmm, I think not the modify/overwrite phases performance were the problem. The modify and overwrite mongo phases fragment the filesystem too much, it had a bad effect visible in the read phase and even in delete phase. We measured/optimized read performance in assumption that fs is not fragmented, why we should measure bad effect of overwrite instead? other fs do not relocate already allocated blocks, negative effect of file set overwrite is zero for them. We could do the same for reiser4 by tuning flush algorithm and journal blocks allocation. If users want to see read and delete performance as they are, overwrite phase should be excluded, at least until we teach flush algorithm to not break good block allocation. If one wants to measure overwite performance, it is easy to enable overwrite phase in mongo, but read and delete speed will be affected (it was so when I tried to optimize delete). I not criticizing mongo benchmark per se. I think that it is fundamentally wrong to use results that were deliberatly manipulated to get best appearance to reiser4 (by omitting work-loads where it performs poorly) as an argument. It's not clear who will, according to your colorful expression, `eat dust' as a result of this. Or do you think that users never overwrite of modify files in real life? not whole file set. I mean it is unusual to overwrite all files in the fs. The 90 second stalls, those should be fixed by debugging copy on capture and turning it on, yes? You can hardly claim I failed to push for the No. I described so many times to you, why COC is ineffectual here. There are other ideas :) but, it seems to me, if we will focus on benchmarks, we never complete plugins, metafiles and other useful things. What I want from reiser4 is a possiblity to encrypt and compress ~/Mail/ :). Hans Nikita. -- Alex.
Re: reiser4 plugins
On Fri, Aug 27, 2004 at 05:29:07PM -0500, Steve Bergman wrote:
On Fri, 2004-08-27 at 11:15 -0700, Hans Reiser wrote:
If you ask real users, they say that reiser4 is fast, and their
experience matches our benchmark. You can criticize the benchmark if
you want, but then you should run your own and publish it.
As a real desktop user who just converted all his partitions from ext3
to reiser4, I have not, as yet, noticed any startling performance
increase. Being slightly slightly irked to hear that the benchmark
numbers that have been paraded around on Slashdot and the internet in
general, at ext3's expense, have had reiser4's bad results surgically
extracted, I am running my own benchmarks to get the real story on
reiser4/ext3 mongo performance on my, rather average, desktop hardware.
I am using the latest Mongo on FC/rawhide and the 2.6.8.1-mm4 kernel.
Unfortunately, I get an error from mongo.pl that Done is not a numeric
argument at line 439.
I have done this to fix it:
--- mongo.pl2004-08-27 17:07:01.681723313 -0500
+++ mongo_fixed.pl 2004-08-27 17:06:51.369306735 -0500
@@ -429,8 +429,8 @@
if ( -e ${ERR_FILE}) {
DIE (\nEXITED WITH FAIL\n);
}
- my $real = (split ' ', $time_output[0])[1];
- my $cpu = (split ' ', $time_output[2])[1];
+ my $real = (split ' ', $time_output[1])[1];
+ my $cpu = (split ' ', $time_output[3])[1];
unless ( $real =~ /\s*\d+/ $cpu =~ /\s*\d+/) {
LOG @time_output;
What it gets me is the real line of the time output for STAT
REAL_TIME and the sys line of the time output for STAT CPU_TIME.
i.e. only system time is counted. I believe this was the intent of the
original code, but want to verify before continuing.
it works on our test servers which are SuSE9.0/9.1.
I think there is a dependency on system utilities, Done is not printed by
mongo.pl or any other program from the mongo package.
It would be nice to tell us what linux distro you are using and what mongo
phase fails.
Thanks,
Steve Bergman
Thanks.
--
Alex.
Re: reiser4 plugins
On Sat, Aug 28, 2004 at 05:09:28AM -0500, Steve Bergman wrote: On Fri, 2004-08-27 at 23:54 -0700, Hans Reiser wrote: I didn't write this (more precisely, it only vaguely resembles what I wrote in 1996). Are you saying that it reports system time as real time? If yes, then it is an error, we need to go remove a bunch of numbers from our benchmarks, and thanks for finding it. Zam, please comment. No. I'm saying that on my setup (kernel 2.6.8.1-mm4/perl 5.8.5/bash 3.00) the first line returned from running the test is the: [1]+ Done ... line which throws the array indexes off by 1 and I always get 0 for the real time and, yes, the real time gets reported as the system time, I think. Plus I get a warning about the fact that Done is not numeric. This is obviously a problem with my particular setup. Yes. but that real/sys time parsing isn't reliable. After bumping the indexes up by 1, I get the correct real time reported as STAT REAL_TIME. And the system time is reported as STAT CPU_TIME. STAT CPU_UTIL, however is computed in a completely different way based on numbers collected from /proc/stat. If I'm, reading linux/Documentation/filesystems/proc.txt correctly, it is trying to return the (system time) / (total time). The total time agrees with STAT REAL_TIME. However, the (system time) that it comes up with here is always considerably higher than STAT CPU_TIME. CPU_UTIL counts other background processes too. The foreground process may just wait when all work is done by pdflush. I think CPU_UTIL is more useful than CPU_TIME. User error is quite possible, as I am: 1. Just getting to know mongo. 2. Not a perl guy. i don't like perl too much, but seems Perl is perfect for the things you just did (the fixes). 3. There is obviously something mongo.pl doesn't like about my setup. -Steve Bergman P.S. In the 2 tests I've run, reiser4 is not doing all that badly against ext3 in OVERWRITE and MODIFY, though ext3 does come in faster. Reiser4 trails badly on APPEND however, ext3 (data=ordered, without htree) being some 2.5 - 4 times faster. -- Alex.
Re: reiser4 plugins
On Sat, Aug 28, 2004 at 05:09:28AM -0500, Steve Bergman wrote: On Fri, 2004-08-27 at 23:54 -0700, Hans Reiser wrote: I didn't write this (more precisely, it only vaguely resembles what I wrote in 1996). Are you saying that it reports system time as real time? If yes, then it is an error, we need to go remove a bunch of numbers from our benchmarks, and thanks for finding it. Zam, please comment. No. I'm saying that on my setup (kernel 2.6.8.1-mm4/perl 5.8.5/bash 3.00) the first line returned from running the test is the: [1]+ Done ... line which throws the array indexes off by 1 and I always get 0 for the real time and, yes, the real time gets reported as the system time, I think. Plus I get a warning about the fact that Done is not numeric. This is obviously a problem with my particular setup. Yes. but that real/sys time parsing isn't reliable. After bumping the indexes up by 1, I get the correct real time reported as STAT REAL_TIME. And the system time is reported as STAT CPU_TIME. STAT CPU_UTIL, however is computed in a completely different way based on numbers collected from /proc/stat. If I'm, reading linux/Documentation/filesystems/proc.txt correctly, it is trying to return the (system time) / (total time). The total time agrees with STAT REAL_TIME. However, the (system time) that it comes up with here is always considerably higher than STAT CPU_TIME. CPU_UTIL counts other background processes too. The foreground process may just wait when all work is done by pdflush. I think CPU_UTIL is more useful than CPU_TIME. User error is quite possible, as I am: 1. Just getting to know mongo. 2. Not a perl guy. i don't like perl too much, but seems Perl is perfect for the things you just did (the fixes). 3. There is obviously something mongo.pl doesn't like about my setup. -Steve Bergman P.S. In the 2 tests I've run, reiser4 is not doing all that badly against ext3 in OVERWRITE and MODIFY, though ext3 does come in faster. Reiser4 trails badly on APPEND however, ext3 (data=ordered, without htree) being some 2.5 - 4 times faster. -- Alex.
Re: silent semantic changes with reiser4
On Thu, Aug 26, 2004 at 04:04:34PM +0100, Jamie Lokier wrote: Christophe Saout wrote: What reiser4 can do, but the VFS can't is to insert or remove data in the middle of a file. Adding this above the page cache would probably be almost impossible (truncate seems already complicated enough). That would be one of those special features that a VFS-plus-userspace implementation of archive views could take advantage of on reiser4, while using a slower method (sometimes much slower) on all other filesystems. By the way, can reiser4 share parts of files between different files? no, those file plugins are not written yet :) Do you mean COW files or some another thing? For COW files, the reiser4 support is not enough, we need to teach cp(1) or another utility to inform the fs layer that copying can be done by creation of COW files. -- Jamie -- Alex.
Re: silent semantic changes with reiser4
On Wed, Aug 25, 2004 at 10:08:59PM +0200, Christoph Hellwig wrote: On Wed, Aug 25, 2004 at 12:53:28PM -0700, Hans Reiser wrote: You ignored everything I said during the discussion of xattrs about how there is no need to have attributes when you can just have files and directories, and that xattrs reflected a complete ignorance of name space design principles. Actually in most of the discussion you simply didn't participate. While xattrs might not be the nicest interface they have the advantag of not breaking the SuS assumption of what directories vs files are, and they do not break the Linux O_DIRECTORY semantics that are defined and need to solve real-world races either. Reiser4 may have a mount option for whoose who like or have to use traditional O_DIRECTORY semantics. There would be no /metas under non-directories, if user wants that. [ ... ] -- Alex.
Re: fsck.reiser4 wrong size error (?)
On Thu, Aug 12, 2004 at 11:08:06PM +0200, Francesco Biscani wrote:
Hi,
On Thursday 12 August 2004 22:08, Alex Zarochentsev wrote:
a. mkfs.reiser4 has options to set default fibration plugin.
b. you can change fibration plugin for empty dir through metas/ interface.
and
On Thursday 12 August 2004 22:31, Vitaly Fertman wrote:
default plugins in progs play role for mkfs only, and they have nothing to
do with already created fs. You have created it with dot-o default, so the
current fibration fs default is dot-o, and you can change it for some
partitcular directory only, an empty one, with :
echo -e ext-1\0 dir/metas/plugin/fibration
Then all children will be created with with ext-1 also.
Thanks for the quick response Alex and Vitaly.
I know about the metas interface. What I would like to know, though, is:
1) is there a way to have all newly created dirs default to ext-1 fibrate,
without re-creating the fs with mkfs?
Changing fs root dir fibration plugin would do that if the root dir was empty.
Current code does not allow it.
So, the problen cannot be fully solved. However, you can re-create all second
level sub-directories and assign another fibration plugins to them.
2) is there a place where a detailed description of mount options for reiser4
is available? I've googled around without much luck.
fs/reiser4/vfs_opts.c:reiser4_parse_options contains opts[] -- an array of
all reiser4 mount option descriptions.
...
opt_desc_t opts[] = {
/* trace_flags=N
set trace flags to be N for this mount. N can be C numeric
literal recognized by %i scanf specifier. It is treated as
bitfield filled by values of debug.h:reiser4_trace_flags
enum
*/
SB_FIELD_OPT(trace_flags, %i),
/* log_flags=N
...
Thanks again,
Francesco
--
Alex.
Re: implementing reiserfs in C++ for a new OS
On Wed, Aug 11, 2004 at 09:43:13AM -0700, Hans Reiser wrote: Nikita Danilov wrote: Copyright to result of translation belongs to the translator. At least, according to Russian law. I may be completely wrong legally, esp. in Russia. I personally think it should belong to the original author if the original copyright is still valid. Otherwise harry potter can get translated and no need to pay rowling. one needs to pay rowling and pay translator. Hans -- Alex.
Re: Was able to reproduce cp: cannot stat file.x: Input/output error
On Mon, Aug 09, 2004 at 11:21:17PM -0400, [EMAIL PROTECTED] wrote: On Sat, 07 Aug 2004 00:49:43 PDT, Hans Reiser said: I think I have discovered the problem - unless there was a reason mongo was issuing mount/unmount commands at the start/end of a mongo 'run' as well as before/after _each phase_. Probably someone wanted to separate the measurement of the phases. It has been a while since I read mongo. Note that an unmount/mount pair will force a flush of all dirtied pages in the in-memory file cache, and *really* not return until it's really done and really out on disk. In addition, sync() will force stuff to disk, but *not* invalidate in-cache pages - more drastic measures are needed if you want to benchmark with a cold cache (which is almost a must if you're doing actual filesystem benchmarking, as otherwise you're benching the in-core cache instead). That was designed to have result in each phase as independent as we can. For example, if we have read slowdown in mongo, we will analyze only reads and, probably, fs fragmentation, we won't deal with unmeasurable cache state before the read phase. Known and persistent cold cache effect is better than unknown hot cache one :) And, mongo phases are designed to be long and keep the cold cache effect at minimum. As an aside, although the Linux fs/buffer:do_sync() won't return until it's all really done, there is no mandate that the sync() syscall wait (and in fact, is the source of the old type 'sync' three times, then 'halt' - the second and third times you typed sync and hit return hopefully gave the I/O scheduled by the *first* sync time to complete. At least one 'Unix for Dummies' book proved their lack of depth of understanding when they recommended: # sync;sync;sync;halt -- Alex.
Re: Apache2 problems
On Tue, Aug 10, 2004 at 02:55:55AM +0930, Tom Lanyon wrote: Hello, Can someone please inform me of how to stop the dreaded sendfile issues while using reiser4 and apache2? I just setup reiser4 on a nice new hard drive and tried to run apache2 and ended up with many kernel panics and then the machine locked up. I used ab2 test tool, apache2 from SuSE9.1 and the latest reiser4 code. It works fine for me. I thought this issue was fixed in reiser4? If not, how can I go about stopping this from happening? This is reiser4-2004.07.23-19.37-linux-2.6.8-rc2-bk4.diff on a 2.6.8-rc2 kernel. I'm about to try the latest snapshot on a vanilla 2.6.8-rc3 and see if it helps.. Thanks for any help, Tom. -- Alex.
Re: Was able to reproduce cp: cannot stat file.x: Input/output error
On Tue, Aug 10, 2004 at 10:35:58AM -0700, Hans Reiser wrote: Alex Zarochentsev wrote: On Mon, Aug 09, 2004 at 11:21:17PM -0400, [EMAIL PROTECTED] wrote: On Sat, 07 Aug 2004 00:49:43 PDT, Hans Reiser said: I think I have discovered the problem - unless there was a reason mongo was issuing mount/unmount commands at the start/end of a mongo 'run' as well as before/after _each phase_. Probably someone wanted to separate the measurement of the phases. It has been a while since I read mongo. Note that an unmount/mount pair will force a flush of all dirtied pages in the in-memory file cache, and *really* not return until it's really done and really out on disk. In addition, sync() will force stuff to disk, but *not* invalidate in-cache pages - more drastic measures are needed if you want to benchmark with a cold cache (which is almost a must if you're doing actual filesystem benchmarking, as otherwise you're benching the in-core cache instead). That was designed to have result in each phase as independent as we can. For example, if we have read slowdown in mongo, we will analyze only reads and, probably, fs fragmentation, we won't deal with unmeasurable cache state before the read phase. Known and persistent cold cache effect is better than unknown hot cache one :) And, mongo phases are designed to be long and keep the cold cache effect at minimum. Let me be more precise here. Is the time spent mounting and umounting included in the time for the phase? oops. sync time included. mount/umount time is not. -- Alex.
Re: Mongo error while building HTML results
On Fri, Aug 06, 2004 at 03:29:23PM +0200, Philippe Gramoull? wrote: Hello, After the latest snapshot successfully fixed my mount/umount bug, i ran some mongo benchmarks (first to mimic David Dabbs results here : http://dabbs.net/reiser4/mongo.html), i couldn't build the HTML results of the dd phases by using mongo_parser.pl. Mongo says that there are uninitialized data: (i'm using mongo found here : http://thebsh.namesys.com/benchmarks/mongo-2004.07.26.tar.gz) I posted the 3 log files and the config file here: http://philou.org/linux/reiser4/mongo/reiser4.tbl http://philou.org/linux/reiser4/mongo/reiserfs.tbl http://philou.org/linux/reiser4/mongo/ext3.tbl http://philou.org/linux/reiser4/mongo/config-2.6.8-rc2-mm2 did you use LOG= option? where those *.tbl files are from? The broken HTML output is here: http://philou.org/linux/reiser4/mongo/mongo.html While running the reiser4 mongo run i have the following error at the dd write sequence: Argument records isn't numeric in addition (+) at ./mongo.pl line 445. Argument bytes isn't numeric in addition (+) at ./mongo.pl line 446. Thanks, Philippe Thank you. -- Alex.
Re: Reiser4
On Wed, Jun 30, 2004 at 04:16:33PM +0200, Ronni Nielsen wrote: I rally want to test reiser4 - but i have this problem: modprobe reiser4: FATAL: Error inserting reiser4 (/lib/modules/2.6.7-mm4/kernel/fs/reiser4/reiser4.ko): Unknown symbol in module, or unknown parameter (see dmesg) dmesg: ... reiser4: Unknown symbol __pagevec_release reiser4: Unknown symbol pagevec_lookup_tag reiser4: Unknown symbol __iget I downloaded the 2.6.7 kernel and patched it with the 2.6.7-mm4 patch. Then i downloaded reiser4-2004.06.30-09.12-linux-2.6.7-mm4.diff.gz from http://www.namesys.com/auto-snapshots/ What is the problem??? And how can I help in testing the new filesystem? exporting of those symbols should help to build reiser4 as a module. -- Alex.
Re: reiser4 on alpha
On Sat, Jun 26, 2004 at 09:57:32AM +0200, Jure Pe??ar wrote:
On Sat, 26 Jun 2004 10:41:31 +0400
Alex Zarochentsev [EMAIL PROTECTED] wrote:
{standard input}: Assembler messages:
{standard input}:5: Warning: setting incorrect section attributes for
.got
Does only reiser4 produce the above warning?
No. I get these from various parts of the kernel, but are a lot less
frequent now on 2.6.7 than on previous kernels.
Looking at fs/reiser4/debug.h suggest that this is something done on
purpose to guard against other problems.
yes, duplicated case value is a result of our compile-time assertion if
it fails.
But the assertion is wrong because the assumtion that struct coord has no
implicit padding is wrong on alpha.
Do i undestrand that right, the fix is just to comment out the c1-pad line
there?
you can remove the wrong caccert.
--
Alex.
Re: Some errors, tree-related?
On Mon, Jun 28, 2004 at 10:47:41PM +0300, Markus Trnqvist wrote: Hi While I was toying around with unrelated stuff, I noticed I got the good old jamming problems that I had with some older auto-snapshot, that is, apt-get would lock on 93% and tab expansion would as well, then everything would lock. Rebooting needs the SysRq trio. Now I got the behavior again, and noted some stuff in the log that I could swear wasn't there when I last had these problems. On the other hand, I don't know if they're related. That's why I'm mailing here :) Jun 28 22:18:53 shrike kernel: reiser4[xmms(3797)]: traverse_tree (fs/reiser4/search.c:747)[nikita-1481]: Jun 28 22:18:53 shrike kernel: WARNING: Too many iterations: 1048576 Jun 28 22:19:15 shrike kernel: reiser4[xmms(3797)]: traverse_tree (fs/reiser4/search.c:747)[nikita-1481]: Jun 28 22:19:15 shrike kernel: WARNING: Too many iterations: 2097152 Jun 28 22:19:46 shrike kernel: reiser4[xmms(3797)]: traverse_tree (fs/reiser4/search.c:747)[nikita-1481]: Jun 28 22:19:46 shrike kernel: WARNING: Too many iterations: 4194304 Then I restarted the computer. Bugger me, I can't remember if I restarted because of a lock-up there or not, but this I got later: Jun 28 22:36:21 shrike kernel: reiser4[xmms(3834)]: renew_sibling_link (fs/reiser4/tree_walk.c:441)[nikita-3532]: Jun 28 22:36:21 shrike kernel: WARNING: Sibling nodes on the different levels: 1 != 2 [...] Jun 28 22:38:51 shrike kernel: reiser4[xmms(4068)]: renew_sibling_link (fs/reiser4/tree_walk.c:441)[nikita-3532]: Jun 28 22:38:51 shrike kernel: WARNING: Sibling nodes on the different levels: 1 != 2 So, what's up here? Is it related to any known stability issue? it shows serious tree corruption. which reiser4 snapshot is on shrike? I re-mkfs'd my home partition, but did an fsck on the / partition, when it was last needed. Could that affect here? Do I _really_ have to mkfs again? Or am I barking up the wrong tree? (No pun intended :D) Thanks! -- mjt -- Alex.
Re: www.namesys.com down
On Thu, Jun 24, 2004 at 11:02:31AM +0200, Sander wrote: Hi, I notice www.namesys.com is down for quite some time now. At first it was not pingable, but now just the webserver refuses to 'serve the web'. Is this due to the migration to reiserfs4? Yes. Yesterday we resolved apache2/reiser4 issue. Now the server is reconfigured again. -- Alex.
Re: reiser4 vs. apache2 bad interaction?
On Wed, Jun 23, 2004 at 09:27:33PM +0200, Cyrille Chepelov wrote: Hi Alex, can you try http://namesys.com/auto-snapshots/reiser4-2004.06.23-14.56-linux-2.6.7-rc3-mm1.diff.gz ? there was a bug in readpages_unix_file() which affected reiser4_sendfile(). Unfortunately, this kernel FTBFS: CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 arch/i386/kernel/built-in.o(.text+0xc7fc): dans la fonction acpi_register_gsi : : undefined reference to `mp_register_gsi' make[1]: *** [.tmp_vmlinux1] Erreur 1 make[1]: quittant le r?pertoire ? /usr/src/linux/build/traminer/linux-ketchup ? make: *** [stamp-build] Erreur 2 we enable PM and ACPI for curing that. ... though I highly doubt it's reiser4's fault (this system can only support APM power management, not ACPI. I even disabled power management completely in this second compilation, for the same result; .config.bz2 attached, just in case. Can you give me a patch against the Linus tree? There are rumors that the patch applies to and works for stock 2.6.7, but we did not test that. -- Cyrille -- Alex.
Re: Reiser4's status of this week.
On Sat, Jun 19, 2004 at 02:15:39PM -0400, Nicholas S. Wourms wrote: Hans Reiser wrote: [EMAIL PROTECTED] wrote: Hi,Hans: Your website are saying Reiser4 is in final testing, and will ship soon! It has been saying that for a long time :( When could Reiser4 be finaly released? We are eager to try it. Regards. Stone. next week. or so we hope. Hans, I've noticed that there seems to be a problem with your reiser4-linux-2.6 bitkeeper repository. Unlike the 2.5 version I used awhile back, this one seems to just be an old copy of the stock linux-2.6.5 kernel with the 2.6.5-mm2 patches added. None of the reiser4 base or extra patches seem to have been added (excluding the ones for fs/reiser4). Would someone mind fixing this? Don't you have an internal repository with all the modifications in the base and extra series applied? Yes we have. We work with an internal bk repository. The public repositories are copies of the internal ones, we have a script to update public repositories once per day. We will figure out after weekend why it does not after weekend. If your internal tree can't be exported, can you provide a snapshot BK-style(not gnu) patch against linus-current? we have two repositories, one for core kernel + our local changes to the core, reiser4 itself is in another BK. I think we can't provide one bk-style patch easily. I've also noticed, as has been noted in the past, that bk pulls are still broken. Someone mentioned that it is a problem with the new bk. If this is true, why not contact Larry for support? Flx did, but the problem still there. Not that it matters now, since the reiser4-linux-2.6 isn't usable, but it might be helpful for future syncs. Cheers, Nicholas -- Alex.
Re: Problem with the latest auto snapshot
On Sun, Jun 13, 2004 at 03:37:54PM +0200, Henning Westerholt wrote: Am Samstag, 12. Juni 2004 21:46 schrieb Markus T?rnqvist: I had something similar, with an old auto-snapshot, but I didn't get those log messages. It also repeated on, 2004.06.09 under some mild load, compiling .11-19.36 and doing a dist-upgrade. I'll dig out some traces if it still repeats with this kernel, as they seem to have systematically receeded. I wonder if we have something different concerning debug? [EMAIL PROTECTED]:~$ zgrep -i reiser4 /proc/config.gz [snip] Hello Markus, i'm using the same reiser4 config like you. I just rebuild the partition, and start a small compile job. After them i started a fsck. It reported a new fatal error about a broken node. I attached the output from fsck. I could reproduce this error two times. new fsck 0.5.5 is available for testing (http://www.namesys.com/snapshots/2004.06.14-internal.testing/), please try it. Can you also enable CONFIG_REISER4_CHECK and CONFIG_REISER4_DEBUG? It may help to catch a bug faster. -- Alex.
Re: Problem with the latest auto snapshot
On Tue, Jun 15, 2004 at 12:06:53PM +0400, Alex Zarochentcev wrote: On Sun, Jun 13, 2004 at 03:37:54PM +0200, Henning Westerholt wrote: Am Samstag, 12. Juni 2004 21:46 schrieb Markus T?rnqvist: I had something similar, with an old auto-snapshot, but I didn't get those log messages. It also repeated on, 2004.06.09 under some mild load, compiling .11-19.36 and doing a dist-upgrade. I'll dig out some traces if it still repeats with this kernel, as they seem to have systematically receeded. I wonder if we have something different concerning debug? [EMAIL PROTECTED]:~$ zgrep -i reiser4 /proc/config.gz [snip] Hello Markus, i'm using the same reiser4 config like you. I just rebuild the partition, and start a small compile job. After them i and please try new mkfs.reiser4 as well. started a fsck. It reported a new fatal error about a broken node. I attached the output from fsck. I could reproduce this error two times. new fsck 0.5.5 is available for testing (http://www.namesys.com/snapshots/2004.06.14-internal.testing/), please try it. Can you also enable CONFIG_REISER4_CHECK and CONFIG_REISER4_DEBUG? It may help to catch a bug faster. -- Alex. Thanks. -- Alex.
Re: Problem with the latest auto snapshot
On Tue, Jun 15, 2004 at 06:50:44PM +0200, Henning Westerholt wrote: Am Dienstag, 15. Juni 2004 10:14 schrieb Alex Zarochentsev: Can you also enable CONFIG_REISER4_CHECK and CONFIG_REISER4_DEBUG? It may help to catch a bug faster. Hello Alex, thanks for your reply. I restarted with a debug-enabled kernel, after the fsck --build-sb --fix run on the three partitions i use. The fsck reports a consistent fs on all of them. The first access to a reiser4 fs during the boot (cleaning the tmp dir) causes several kernel oopses. I captured them with pen and paper, as these message don't appear in the system log. I try to capture them with the serial console on a second pc, but without success. do you use a kernel with 4k stacks? What CONFIG_4KSTACKS is set to? This option should be switched off for reiser4. [ ... ] reiser4 kernel config: CONFIG_REISER4_FS=y # CONFIG_REISER4_FS_SYSCALL is not set CONFIG_REISER4_LARGE_KEY=y CONFIG_REISER4_CHECK=y CONFIG_REISER4_DEBUG=y # CONFIG_REISER4_FS_SYSCALL_DEBUG is not set # CONFIG_REISER4_DEBUG_MODIFY is not set # CONFIG_REISER4_DEBUG_MEMCPY is not set # CONFIG_REISER4_DEBUG_NODE is not set # CONFIG_REISER4_ZERO_NEW_NODE is not set # CONFIG_REISER4_TRACE is not set # CONFIG_REISER4_EVENT_LOG is not set # CONFIG_REISER4_STATS is not set # CONFIG_REISER4_PROF is not set CONFIG_REISER4_DEBUG_OUTPUT=y # CONFIG_REISER4_NOOPT is not set CONFIG_REISER4_USE_EFLUSH=y # CONFIG_REISER4_COPY_ON_CAPTURE is not set # CONFIG_REISER4_BADBLOCKS is not set Hope you could use this report. Best regards, Henning -- Alex.
Re: Problem with the latest auto snapshot
On Tue, Jun 15, 2004 at 12:55:50AM +0200, Henning Westerholt wrote: Am Montag, 14. Juni 2004 20:22 schrieb Alex Zarochentsev: On Sat, Jun 12, 2004 at 09:31:25PM +0200, Henning Westerholt wrote: Thanks for the report. do you use SMP, RAID, LVM ? No. After some few disk operation a process try to access some data on the partition, and hung forever. I got the following log entries: Were there reiser4 messages in the log before [nikita-2219]... Failed to initialize dir for...? No other messages, sorry. [snip...] The latest officially released reiser4 utils are not aware of recent stat data extensions. That can explain item has wrong length errors. However, that does not explain points to the already used block errors :(. Thank you for the explanation. Is the reiser4progs-0.5.5 release aware of these extensions? yes. Best regards, Henning -- Alex.
Re: How long will a shrinkfs take?
On Fri, Jun 11, 2004 at 09:29:11AM +0100, David Greaves wrote: Alex Zarochentsev wrote: On Thu, Jun 10, 2004 at 09:13:35PM +0100, David Greaves wrote: Hi I have a 1Tb reiserfs that I want to shrink to 500Gb 400Gb of data is used. Any estimates as to how long this will take? Sustained I/O is about 33Mb/s at the fs level, 44 Mb/s at the lv level and 65Mb/s at the md0 level. ReiserFs shrinker reads all tree nodes as fsck does (reiserfsck --check may be used for rough estimation) plus shrinker writes relocated nodes (this highly depends on how many nodes are above 500GB boundary). OK - well I know that fsck --check is of the order of minutes rather than hours (did that rather too recently ;) ) So if I asume even spread, 50% is above so 200 Gb needs reading + then writing so say 1Gb/min = 3-4 hours OK ta. BTW, is resizefs safely interruptible? So can I run it for a couple of hours, interrupt, fsck, remount and do it again? (The system's in use and I only get short windows when I can do this kind of thing) no. interrupting it is not safe. fs errors are not so serious, but bitmap content does not match relocated tree so fsck would suggest --rebuild-tree. I understand that if this happens the fs won't have been resized. I envisage the behaviour to be: 1 calc new top boundary 2 scan for files (nodes) with data above boundary it scans internal reiserfs tree, not fs tree. 3 foreach file 3.1 copy data below boundary 3.2 change node to reflect new position 3.3 mark old space as free 4 set new top boundary most of the time being spent in 3. David Anyway running reiserfsck --check before shrinking is a good practice. (I didn't expect the fs to be so slow so I'm going to try a few tuning params on the new 500Gb space before copying over the data and growing back to a Tb) Is it proportional to the amount of shrinkage (ie 2 hrs to reduce by 50G, 20 hrs to reduce by 500Gb) David -- Alex.
Re: How long will a shrinkfs take?
On Thu, Jun 10, 2004 at 09:13:35PM +0100, David Greaves wrote: Hi I have a 1Tb reiserfs that I want to shrink to 500Gb 400Gb of data is used. Any estimates as to how long this will take? Sustained I/O is about 33Mb/s at the fs level, 44 Mb/s at the lv level and 65Mb/s at the md0 level. ReiserFs shrinker reads all tree nodes as fsck does (reiserfsck --check may be used for rough estimation) plus shrinker writes relocated nodes (this highly depends on how many nodes are above 500GB boundary). Anyway running reiserfsck --check before shrinking is a good practice. (I didn't expect the fs to be so slow so I'm going to try a few tuning params on the new 500Gb space before copying over the data and growing back to a Tb) Is it proportional to the amount of shrinkage (ie 2 hrs to reduce by 50G, 20 hrs to reduce by 500Gb) David -- Alex.
Re: Working Reiser4 patch for kernel 2.6.6(-mm2)?
On Fri, Jun 04, 2004 at 12:44:20PM +0300, Raymond A. Meijer wrote: On Fri 4 June 2004 10:29, Raymond A. Meijer wrote: please try this patch: [forward.h patch] Okay, patch applied and recompiling... So far so good. fsck.reiser4 found no errors, and everything mounted properly. Thanks a lot! Thanks a lot for the report. -- Alex.
regular reiser4 snapshots are in http://www.namesys.com/auto-snapshots/
Hi All, now we have regular reiser4 snapshots (night snapshots) in http://www.namesys.com/auto-snapshots/ . It is an addition to public repositories at bk://bk.namesys.com/, which do not fully work (bk pull does not work) . We have troubles with setting both secure and valid public BK repository configuration since some bitkeeper code update. There is no automated control whether a snapshot is stable or not. It might be even not compilable. Time stamp in each patch name is in GMT. No snapshots at weekends. Regards, Alex.
Re: Working Reiser4 patch for kernel 2.6.6(-mm2)?
On Wed, Jun 02, 2004 at 03:54:11PM +0300, Raymond A. Meijer wrote: Hi, Can someone point me to a WORKING Reiser4 patch for kernel 2.6.6 or 2.6.6-mm2? I have tried the reiser4-2004.05.31-19.36-linux-2.6.6-mm2.diff.gz patch from http://www.namesys.com/auto-snapshots/ and it compiles and boots cleanly, but it won't mount my Reiser4 partitions :( what reiser4 messages were in the log? -- Alex.
Re: reiser4 bk pull problem
On Sat, May 29, 2004 at 03:54:18PM +0200, Lorenzo Allegrucci wrote: I can bk clone the reiser4-linux-2.6 repository but I can't bk pull, it waits forever. I've tried upgrating to bitkeeper 3.2 (from 3.0.4) but the problem is still there. Does bk pull work for you? thanks, It is known problem. bk does not like something in our public repository. However, we are testing reiser4 snapshot script, it puts reiser4 patches in http://www.namesys.com/auto-snapshots/ . -- Lorenzo -- Alex.
Re: dd/rebuild of a small used part of a huge reiserfs on lvm?
On Fri, May 28, 2004 at 02:28:08AM -0400, Alexy Khrabrov wrote: I'd like to recover some files from a huge reiserfs file system. It is created above an LVM volume, which in its turn sits on a RAID. The LVM volume is the only one in a group which consists of the sole RAID device. I just deleted two files in a directory I know by name, the directory is still there. No writing was done after the rm, except all files copied elsewhere and diff -r'ed checked, hope that does not alter the originals. Now I'd like to play with the dd copying of the whole reiserfs (I'm avoiding the word partition since it covers the whole logical volume which spans the whole RAID device). I simply do not have space to copy the whole RAID, but the size of the used space on this reiserfs volume was under about 9 GB. I wonder how can I copy just about that -- I assume it fills the logical volume contiguously, so I can dd the first 9 GB and then try the loopback mount/rebuild. Now that I'm running it, it scrolls lines pass0: reading block 20626210 failed like crazy, perhaps up to the whole 150 GB original size declared somewhere... yes, it is declared in the reiserfs superblock. Can I use resize_reiserfs on the loopback before running rebuild? Are there LVM methods to shrink it/copy just the used blocks in conjunction with reiserfs? Before our reiserfsck master answers I can suggest reiserfsck --rebuild-sb, it re-creates superblock and can change the declared fs size. I hope your file was on the first 9 GB. Then run reiserfsck --rebuild-tree --scan-whole-partition and look at lost+found dir for your file. Just curious... -- Cheers, Alexy Khrabrov :: www.setup.org :: Age Quod Agis -- Alex.
Re: reiser4 and bonnie problems
On Tue, Apr 20, 2004 at 08:18:27PM +0200, Paul Wagland wrote: On Apr 20, 2004, at 16:51, Alex Zarochentsev wrote: On Tue, Apr 20, 2004 at 05:37:39PM +0400, Nikita Danilov wrote: Paul Wagland writes: Just to summarise everything that is written below, this is what bonnie is doing: 1. write 3.5 GB onto a 4GB partition. This works 2. delete 3.5 GB from a 4GB partition. This works. Disk blocks freed during transaction are not actually freed until transaction commits. Under what conditions do transactions get committed? Alex mentioned below that every write is an implicit commit. no. write should cause a commit _only_ if no free space. df (for reiser4) does not show correct free block counter value. It shows (1) amount of reiser4 free blocks plus (2) blocks which can be freed by atom commits. Those blocks are _potentially_ free. If blocks (1) are not enough, reiser4 has to commit atoms to free blocks (2). The explanation above is simplified a bit. Indeed, atom commit may free more blocks, some blocks are reserved for wandered log and they are freed after commit, some blocks can be freed by squalloc (node squeeze and allocate) operation which precedes atom commit. Is that the only situation? Other than sync obviously :-) 1. atom (transaction) is too old or too large. 2. VM asks for memory and reiser4 failed to free memory ways other than atom commit. 3. fsync. 4. reiser4 consideres the situation as close to OOM. reiser4_writepage() may force atoms to commit. 3. I check using df that the disk space is free. That works. But that delayed freeing confused users (they did cp, rm, but df has still showed that space is used), so that statfs(2) (system call used by df) was modified to take these delayed blocks into account and pretend that they are free. OK, that I can deal with, rm'ing a file should free the space ;-). However, if the transaction is not committed at this point, what happens if I lose power at this point? Is the filesystem rolled back to before the deletions? 4. write 3.5GB onto a 4GB partition. This fails. Try to repeat this with sync before step 4. OK, here is the results of the test. I have decided to run it without bonnie, just to make sure that it was not the determining factor. - tidbit:~# mount | grep /mnt/sdr /dev/sdr1 on /mnt/sdr type reiser4 (rw) tidbit:~# df /mnt/sdr Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdr1 3984228 292 3983936 1% /mnt/sdr tidbit:~# dd if=/dev/zero of=/mnt/sdr/ddtest bs=512K count=7K ; rm /mnt/sdr/ddtest; df /mnt/sdr; dd if=/dev/zero of=/mnt/sdr/ddtest bs=512K count=7K ; rm /mnt/sdr/ddtest; df /mnt/sdr 7168+0 records in 7168+0 records out 3758096384 bytes transferred in 70.899981 seconds (53005605 bytes/sec) Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdr1 3984228 292 3983936 1% /mnt/sdr dd: writing `/mnt/sdr/ddtest': No space left on device 613+0 records in 612+0 records out 321384448 bytes transferred in 3.378787 seconds (95118291 bytes/sec) Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdr1 3984228 296 3983932 1% /mnt/sdr tidbit:~# dd if=/dev/zero of=/mnt/sdr/ddtest bs=512K count=7K ; rm /mnt/sdr/ddtest; df /mnt/sdr; sync; dd if=/dev/zero of=/mnt/sdr/ddtest bs=512K count=7K ; rm /mnt/sdr/ddtest; df /mnt/sdr 7168+0 records in 7168+0 records out 3758096384 bytes transferred in 73.244216 seconds (51309122 bytes/sec) Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdr1 3984228 296 3983932 1% /mnt/sdr 7168+0 records in 7168+0 records out 3758096384 bytes transferred in 70.666456 seconds (53180768 bytes/sec) Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdr1 3984228 292 3983936 1% /mnt/sdr At the time of failure, according to df there is stiff 3.5 GB free. So, I say that reiser4 has a problem. df lies. No. df tells the user what reiser4 tells df. If df is lying it is because reiser4 has lied to it. If df tells me that there is 3.9GB available on the filesystem, then I expect that filesystem to allow me to write 3.9GB to it. Yes. reiser4_stafs() was changed expecting that reiser4_filewrite(), for example, would free that space if necessary. I committed a fix for reiser4_write(). However it is not tested yet. reiser4_statfs() was changed to report deleted blocks as free space immediately after rm(1). As mentioned above, this makes perfect sense, and leads to more 'intuitive' behaviour from the filesystem. I fully expect that the filesystem should change established semantics, and in this sense the above change keeps these semantics, which is a good thing :-) It was done because reiser4_write() should trigger fs commit and recover free space
Re: Please /dev/null html-only mail rather than sending it out on this list
On Mon, Apr 19, 2004 at 03:45:51PM +0400, Alexander Lyamin wrote: Sun, Apr 18, 2004 at 05:45:04PM -0400, Pierre Abbat wrote: On Sunday 18 April 2004 17:26, Whit Blauvelt wrote: Hi, :0 B * H ?? Content-Type: multipart * Content-Type: text/html * ! Content-Type: text/plain * ! ^Received: /dev/null #The Received check is there because I am a postmaster. procmail is BD :) we use a really small bit of shell instead # we check if message was spoiled by spamassassin in previous # round of spamcheck (qmailq). preflag=`printf %s\n $input | $M822FIELD X-Spam-Flag | sed 's/^ //'` if [ $preflag = YES ]; then # .. and if its spammy enough already, we reinject. printf %s\n $input | $FORWARDBIN $FORWARD if [ $? -eq 0 ]; then #so qmail will not do any further deliveries in .qmail file exit 99 fi # problem calling inject - temp failure exit 111 fi # i cant send HTML only to /dev/null cause Hans Reiser thinks ASCII (we are all using) is obsoleted by *ML's ;) More strong anti-spam rules for the mailing list may help. As an example rejecting HTML-only e-mails may be wrong for filtering private e-mail and good for the reiserfs-list. but we do a lil tweakig there and there, changing weights and writing new spamassassin rules. for example for today spamassassin blocked 162 spam messages that were sent to this list ;) well some got through. we are not perfect, but i'm working on it (being perfect).. Also block mail from IP addresses known to be open relays, open proxies, rooted boxes, etc. its intresting discussion, but lets move it off the list. -- the liberation loophole will make it clear.. lex lyamin -- Alex.
Re: fsck.reiser4 v. 0.51 problem
On Wed, Feb 25, 2004 at 07:03:44PM +, Henning Westerholt wrote: Hello all, i try the latest snapshot of the reiser4 code with 2.6.3 on my system. I create a new reiser4 partition with mkfs version 0.51. After one hour the compilation of xfree on this fs aborts with a linker error. what was the error? does the log contain something looks like reiser4 errors messages? I try to fix the filesystem with fsck, it complains about a fatal corruption and suggested the option build-fs. Fsck with --build-fs aborts with the following error for me: Ok. We will concentrate on things which are different in your tests and our. At least we don't use fsck so often. Thanks for the report. -- Alex.
Re: Bug report: Reiser4 freezes during file copy
hi, On Wed, Feb 18, 2004 at 11:13:14AM -0700, Jonathan Briggs wrote: The software: Linux kernel 2.6.3 with Reiser4 patch dated February 6th. Compiled with gcc 3.4.0 20040129 (I know the GCC is still in testing, but Reiser3 works fine with it, so...) After I'd created a new Reiser4 filesystem, I was copying my backup files onto it. While I was doing that, it just stopped. Did you create reiser4 on a loopback or RAID/LVM device? Here is the cp process from a process dump: cpD C83F583C 0 20232 20159 (NOTLB) c83f57b4 00200082 dd505014 c83f583c c83f58ec 0002 0002 0002 0002 00072f8f 972dc381 21ec d0ffad00 d0ffaec0 c83f5f0c 00200292 c83f4000 d0ffad00 c010714b c83f5f14 0001 d0ffad00 c011c620 Call Trace: [c010714b] __down+0x7b/0x110 [c011c620] default_wake_function+0x0/0x20 [c01f6356] extent_size+0x96/0xa0 [c0107088] __down_failed+0x8/0xc [c01c2f9b] .text.lock.lock+0xf/0x14 [c01c90e7] atom_wait_event+0x57/0x80 [c01ea84f] plugin_by_coord_node40+0x2f/0x40 [c01d5dd8] write_fq+0x18/0x1d0 [c01c2487] longterm_unlock_znode+0xa7/0x140 [c01cc720] write_prepped_nodes+0x50/0x60 [c01cfb27] flush_current_atom+0x757/0xbc0 [c01de320] reiser4_writepages+0x0/0xc0 [c01c9d14] flush_some_atom+0x174/0x290 [c01da903] reiser4_sync_inodes+0xb3/0x120 [c0177d26] sync_sb_inodes+0x16/0x30 [c0177ed9] writeback_inodes+0x49/0x92 [c013db8e] balance_dirty_pages_ratelimited+0x8e/0x190 [c01f3e7d] item_balance_dirty_pages+0xbd/0x190 [c01f9bdd] write_extent+0x89d/0xf10 [c0206fcb] hint_validate+0xab/0xd0 [c0206739] equal_to_rdk+0x29/0x60 [c01ea84f] plugin_by_coord_node40+0x2f/0x40 [c0207d13] write_flow+0x253/0x460 [c01f9340] write_extent+0x0/0xf10 [c01c8396] all_grabbed2free+0x36/0x40 [c0208148] write_unix_file+0x178/0x2a0 [c01dd72f] reiser4_write+0x8f/0x100 [c01dd6a0] reiser4_write+0x0/0x100 [c015642a] vfs_write+0x10a/0x150 [c0156522] sys_write+0x42/0x70 [c0108249] sysenter_past_esp+0x52/0x71 -- Jonathan Briggs [EMAIL PROTECTED] -- Alex.
Re: Bug report: Reiser4 freezes during file copy
On Wed, Feb 18, 2004 at 12:19:06PM -0700, Jonathan Briggs wrote: On Wed, 2004-02-18 at 11:43, Alex Zarochentsev wrote: hi, On Wed, Feb 18, 2004 at 11:13:14AM -0700, Jonathan Briggs wrote: The software: Linux kernel 2.6.3 with Reiser4 patch dated February 6th. Compiled with gcc 3.4.0 20040129 (I know the GCC is still in testing, but Reiser3 works fine with it, so...) After I'd created a new Reiser4 filesystem, I was copying my backup files onto it. While I was doing that, it just stopped. Did you create reiser4 on a loopback or RAID/LVM device? I knew I should have included more details! Sorry... Yes, it was on a MD device on top of two SCSI drives. RAID 0. This is know problem. That snapshot does not work with RAID devices due to error in bio constructing code. We are about releasing new snapshot which the fixes. -- Alex.
Re: resize reiserfs
On Thu, Feb 05, 2004 at 12:11:22AM +0100, Farkas Barnab?s wrote: On Wed, 2004-02-04 at 22:25, Vitaly Fertman wrote: On Wednesday 04 February 2004 21:27, Farkas Barnab?s wrote: Hello World, Hello Farkas, I would like to resize my reiserfs partition. When its finished, I couldn't mount the partition. I've got error messages I tried --rebuild-tree Did resize_reiserfs finish properly or fail? Could you describe you steps more precisely? How did you run resizer_reiserfs? What did you do next? Did you run reiserfsck --rebuild-sb? Etc. I made the resizing with QtParted-0.4.1 with reiserfs support through libreiserfs, yes? There was no error. but I can't mount again. --rebuild-sb linux:~ # /usr/local/sbin/reiserfsck --rebuild-sb /dev/hda1 reiserfsck 3.6.11 (2003 www.namesys.com) * ** If you are using the latest reiserfsprogs and it fails ** ** please email bug reports to [EMAIL PROTECTED], ** ** providing as much information as possible -- your ** ** hardware, kernel, patches, settings, all reiserfsck ** ** messages (including version), the reiserfsck logfile, ** ** check the syslog file for any related information. ** ** If you would like advice on using this program, support ** ** is available for $25 at www.namesys.com/support.html. ** * Will check superblock and rebuild it if needed Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes Reiserfs super block in block 16 on 0x301 of format 3.6 with standard journal Count of blocks on the device: 7327648 Number of bitmaps: 224 Blocksize: 4096 Free blocks (count of blocks - used [journal, bitmaps, data, reserved] blocks): 7327648 Root block: 0 Filesystem is cleanly umounted Tree height: 0 Hash function used to sort names: r5 Objectid map size 2, max 972 Journal parameters: Device [0x0] Magic [0x0] Size 8193 blocks (including 1 for journal header) (first block 18) Max transaction length 1024 blocks Max batch size 900 blocks Max commit age 30 Blocks reserved by journal: 0 Fs state field: 0x0: sb_version: 2 inode generation number: 0 UUID: 4e4889c5-8054-4d5a-b050-754856b0d279 LABEL: Set flags in SB: Super block seems to be correct linux:~ # /usr/local/sbin/reiserfsck --rebuild-tree /dev/hda1 reiserfsck 3.6.11 (2003 www.namesys.com) reiserfsck --rebuild-tree started at Wed Feb 4 19:20:21 2004 ### Pass 0: ### Pass 0 ### Loading on-disk bitmap .. ok, 8434 blocks marked used Skipping 8434 blocks (super block, journal, bitmaps) 0 blocks will be read Could not find a hash in use. Using r5 r5 hash is selected Flushing..finished Read blocks (but not data blocks) 0 Leaves among those 0 Objectids found 2 Pass 1 (will try to insert 0 leaves): ### Pass 1 ### Looking for allocable blocks .. finished Flushing..finished 0 leaves read 0 inserted ### Pass 2 ### Flushing..finished No reiserfs metadata found. debugreiserfs 3.6.11 (2003 www.namesys.com) Count of blocks on the device: 7327648 Free blocks: 7327648 Thanks -- Alex.
new reiser4 snapshot is available
[resend to LKML] Hi All, New snapshot arrived fetch it http://namesys.com/snapshots/2003.11.12/linux-2.6.0-test9-reiser4.diff.gz for description look at http://namesys.com/snapshots/2003.11.12/READ.ME reiser4progs and libaal packages should be taken from the previous snapshot dir http://namesys.com/snapshot/2003.10.17/. good luck -- -- Alex.
Re: new reiser4 snapshot is available
On Fri, Nov 14, 2003 at 12:04:25PM +0100, Gianni Tedesco wrote: On Fri, 2003-11-14 at 10:42, Alex Zarochentsev wrote: fetch it http://namesys.com/snapshots/2003.11.12/linux-2.6.0-test9-reiser4.diff.gz Seems to be combined with the UML patch... zcat linux-2.6.0-test9-reiser4.diff.gz | diffstat Makefile |2 arch/i386/kernel/entry.S |4 arch/i386/kernel/sys_i386.c |2 arch/um/Kconfig | 48 arch/um/Kconfig_block| 14 arch/um/Kconfig_net | 70 arch/um/Makefile | 49 arch/um/Makefile-i386| 20 arch/um/Makefile-skas|6 arch/um/config.release |1 arch/um/defconfig| 203 arch/um/drivers/Makefile |6 arch/um/drivers/chan_kern.c |1 arch/um/drivers/chan_user.c |4 etc yes, this patch taken from our bk repository, because UML is used in development, it contains uml fixes. previous snapshot was done more carefully, it is located in http://namesys.com/snapshots/2003.10.17/ you can see all changes in one patch as well as broken-out patches. changes for test9 are the same as for test7 with minor exceptions. // Gianni Tedesco (gianni at scaramanga dot co dot uk) lynx --source www.scaramanga.co.uk/scaramanga.asc | gpg --import 8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D -- Alex.
Re: new reiser4 snapshot is available
On Fri, Nov 14, 2003 at 02:20:28PM +0300, Alex Zarochentcev wrote: On Fri, Nov 14, 2003 at 12:04:25PM +0100, Gianni Tedesco wrote: On Fri, 2003-11-14 at 10:42, Alex Zarochentsev wrote: fetch it http://namesys.com/snapshots/2003.11.12/linux-2.6.0-test9-reiser4.diff.gz Seems to be combined with the UML patch... zcat linux-2.6.0-test9-reiser4.diff.gz | diffstat Makefile |2 arch/i386/kernel/entry.S |4 arch/i386/kernel/sys_i386.c |2 arch/um/Kconfig | 48 arch/um/Kconfig_block| 14 arch/um/Kconfig_net | 70 arch/um/Makefile | 49 arch/um/Makefile-i386| 20 arch/um/Makefile-skas|6 arch/um/config.release |1 arch/um/defconfig| 203 arch/um/drivers/Makefile |6 arch/um/drivers/chan_kern.c |1 arch/um/drivers/chan_user.c |4 etc yes, this patch taken from our bk repository, because UML is used in development, it contains uml fixes. previous snapshot was done more carefully, it is located in http://namesys.com/snapshots/2003.10.17/ you can see all changes in one patch as well as broken-out patches. changes for test9 are the same as for test7 with minor exceptions. I made a cleanup for reiser4 patches (by removing UML-specific changes), you can see result here: http://namesys.com/snapshots/2003.11.17/cleaned-up/ core.diff.gz - changes to the core kernel reiser4-only-diff.gz - reiser4 code as a patch all.diff.gz- all in one patch reiser4.tar.gz - reiser4 bk repository (SCCS data included) // Gianni Tedesco (gianni at scaramanga dot co dot uk) lynx --source www.scaramanga.co.uk/scaramanga.asc | gpg --import 8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D -- Alex. -- Alex.
Re: new reiser4 snapshot is available
On Fri, Nov 14, 2003 at 02:27:29PM +0100, Carl-Daniel Hailfinger wrote: Alex Zarochentsev wrote: I made a cleanup for reiser4 patches (by removing UML-specific changes), you can see result here: http://namesys.com/snapshots/2003.11.17/cleaned-up/ That directory doesn't exist. http://namesys.com/snapshots/2003.11.12/cleaned-up/ Carl-Daniel -- Alex.
Re: tail policy question
On Wed, Nov 12, 2003 at 06:23:01PM -0500, Zhihui Zhang wrote: Hi, I spent a little time on Reiser4 tail code and was surprised to find out that the default policy given in reiser4.h is ALWAYS_TAIL_ID not DEFAULT_TAIL_ID. /* default tail policy plugin */ #define REISER4_TAIL_PLUGIN (ALWAYS_TAIL_ID) Does this mean Reiser4 always use tails no matter how large a file is by default? no. tail plugin is specified at mkfs time. ALWAIYS_TAIL_ID is used if disk format plugin does not override it at mount time. The only one existing disk format (disk_format40) does override the default tail policy plugin (see fs/reiser4/plugin/disk_format/disk_format40.c:get_ready_format40). You can run debugfs.reiser4 -t on a reiser4 volume with some big files and see extents there. :-) I must be wrong somewhere. Anyway, when tails are in use, will they incur more or less performance penalty on files using them when compared to ReiserFS V3 (remember that -notail mount option is sometimes preferred)? Tail packing uses more CPU resources than pure extents but it saves I/O operations. At current state default tail policy (smart) is preffered for most cases (i just do not remember when pure extents win). But, we still expect that reiser extent handling code may be optimized a lot, it is possible that pure extents will be better is some case as notail option in reiser3 and even better because extents are better than indirect items). Also, does the offset part of a key for a tail item or an extent item refer to the byte offset of the first byte represented by the tail or extent item? In V3, I remember it is actually byte offset plus one for some reason. Please clarify this for yes, there is a byte offset in the reiser4 key for file body items. AFAIK no plus one byte there. me. Thanks -Zhihui -- Alex.
new reiser4 snapshot is available
Hi All, New snapshot arrived fetch it http://namesys.com/snapshots/2003.11.12/linux-2.6.0-test9-reiser4.diff.gz for description look at http://namesys.com/snapshots/2003.11.12/READ.ME reiser4progs and libaal packages should be taken from the previous snapshot dir http://namesys.com/snapshot/2003.10.17/. good luck -- Alex.
Re: Some more basic questions.
On Mon, Nov 10, 2003 at 05:15:20AM +0100, Alejandro Sanchez Acosta wrote: Hello, I don't understand so well how the dancing trees work. I've seen in the documentation that are faster than B+ trees, but I don't understand the reason. Somebody can explain me how does it work a dancing tree and where does reiserfs use it? Reiser4 tree has no strict invariant that each node (except root) should be filled by more than 50%. Instead it has a rule that ordinary tree modification deletes node only if it is empty. Modified nodes are not written to disk until jnode_flush() packs them more tighty. The idea is to make ordinary tree operations (insert, delete) cheaper and still have on-disk tree well packed, because tree packing saves i/o operations. Other thing that I don't understand is the cache design, where are used caches in the filesystem? ? Basically, reiser4 reads nodes from disk (into page cache), nodes remain in memory until system releases them and frees memory. It is pache cache functionality. And why is better to use extents than BLOBs? A lot of databases use BLOB's to storage the data and get good performance with. acessing BLOBs require one disk op than accessing meta data. In reiser4 you see an attempt to implement equal access cost for all data, including file bodies. What security features provide reiser4? IFAIK, currently only traditional unix security checks are implemented. I have seen that you can use crypto support and crypto compressing, does it support other security features? does it use the new CryptoAPI? no. And other thing, if I want to do a new plugin, what I have to do? Any documentation related? Write new plugins using existing ones as template. What is bad is that reiser4 has no external API to bind reiser4 object and plugins of different types. I think Hans will agree with me that should be fixed soon. Thanks in advance. -- Alejandro Sanchez Acosta [EMAIL PROTECTED] -- Alex.
Re: A few questions of ReiserFS
On Fri, Nov 07, 2003 at 03:14:12PM -0500, Zhihui Zhang wrote: Thanks again. I read more code and have a better understanding. (1) On bitmap handling: Due to the separation of working and commit bitmap, crash replay *only* needs to move wandered blocks to their real locations. These wandered records can be found through journal footer, which is always written at a fixed location. But Reiser4 never allocates space for the wandered records and blocks in the commit bitmap. Am I right? This is a cool solution - minimize the work done by replay. you right. but, IMHO, only replay optimisation is not enough to accept an overhead of having two bitmaps. (2) On dancing tree. Let me guess: Each squeeze can create more than one slum. the larger the slums, the better the performance. In our terminology squeeze is a part of slum processing, it is done together with node (re)allocation in flush.c::squalloc() routine, squalloc is squeeze and allocate. even modification of one file may create two slums because stat data item is located far of file body (items). The nodes in slums are arranged in parent-first order, and hopefully will be allocated contiguous space on the disk. Reiser4 favors relocation to overwrite. But it is possible that it will have to write nodes individually sometimes (fail to form a slum) and at least bitmap blocks are always overwritten. Each node in a slum could be written early somehow due to rapid flush or emergency write (what are these really?). rapid flush is not a key optimization, I think it is not compiled on now. emergency flush is a reuser4 feature for solving out of memory problems. all that slum processing is too heavy to satisfy emerency memory needs. there call path for jnode_flush() is the following: balance_dirty_pages()/reiser4_sync_inodes()/flush_some_atom/flush_current_atom/jnode_flush() It is called number of dirty pages in the system grows over the limit, and, hopefully, gives enough clean pages for memory allocations. But there are emergency cases when try_to_free_pages() scans invactive page list and finds dirty page on it. It calls fs specific (or address space specific) writepage method. We have to responce to it by submiting the page to disk to satisfy memory allocation request. That memory allocation may happen under some reiser4 and vfs locks held it is why calling jnode_flush() will lead to deadlock. The emergency_flush() (reiser4 implementation of writepage() method) routine works with individual pages rather than with slums, it is fast, it does not take long-term locks, it can write locked node to disk. rapid_flush() is a spacial mode for jnode_flush() to submit pages to disk more frequently in a situation close to OOM. After all the nodes of an atom are written, the atom commits by writing wandered records and blocks. Now suppose one leaf node is dirty and it is the first child of its parent, which is in turn the first child of its parent and so on. Does Reiser4 actually puts all these nodes into relocate set even if only one node is dirty initially? Current alloc_one_ancestor() stops if parent is clean, reverse_relocate_check_dirty_parent() is called only at next iteration. I am not sure that is right. I think some clean-up should be done there. I also notice that the default age of an atom is 600 seconds. The delay time is only 30 seconds in traditional Unix file systems. As a result, Reiser4 has a much larger window of vulnerability. Is it true? Ask Hans Reiser. He set that constant. However, you can set tmgr.atom_max_age option at mount time. -- Alex.
Re: Linux 2.4 - 2.6 migration
On Fri, Nov 07, 2003 at 02:39:06PM +0100, Sebastian Kaps wrote: Hi! Is there something concerning ReiserFS I should know when migrating from Linux 2.4 to Linux 2.6? I'm asking because a few days ago I downloaded and compiled 2.6.0-test9 just for curiosity. It booted fine and I went back to my standard kernel, which was 2.4.23-pre5 at that time. Right after booting the 2.4.x kernel, I got lots of the following messages in my logs: , | kernel: ide2(33,3):vs-4080: reiserfs_free_block: free_block (2103:463529)[dev:blocknr]: bit already cleared test-9/reiser3 works fine for us. Your problems could be due to a bug in updated IDE driver, for example. Do other filesystems (like ext2) work? Can you send a .config (from 2.6.0-test-9) and describe your hardware configuration to the [EMAIL PROTECTED] mailing list? ` The block number always differed. Gladly, reiserfsck --rebuild-tree helped to cure that, but there were lots of unusable files after that (e.g. parts of files overwritten with parts of other files). I think that reiserfsck --rebuild-tree trusts the bitmap content, which is not good for your case. Vitaly will answer better. Is this suppose to happen? What caused this error? Another thing: I had to hard reboot my system a few times in the last few months. I also experienced that sometimes parts of files were overwritten with 0x00s or parts of other files. Can someone explain to me how this can happen? -- Ciao, Sebastian -- Alex.
Re: New reiser4 snapshot (2003.09.12) is out
On Fri, Sep 12, 2003 at 01:20:59PM -0700, Mike Benoit wrote: Any ideas why I would get this error while trying to compile reiser4progs-0.4.14? The previous version of reiser4progs seemed to compile fine for me, as did compiling reiser4 in to the test5 kernel. gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -DENABLE_MONOLITHIC -D_REENTRANT -D_FILE_OFFSET_BITS=64 -DENABLE_COLLISIONS -DENABLE_PLUGINS_CHECK -DENABLE_SYMLINKS -DENABLE_R5_HASH -DENABLE_FNV1_HASH -DENABLE_RUPASOV_HASH -DENABLE_TEA_HASH -DENABLE_DEG_HASH -DENABLE_LARGE_KEYS -DENABLE_SHORT_KEYS -O0 -g -W -Wall -Wno-unused-parameter -Wredundant-decls -Werror -MT libmisc_la-exception.lo -MD -MP -MF .deps/libmisc_la-exception.Tpo -c exception.c -fPIC -DPIC -o .libs/libmisc_la-exception.lo exception.c: In function `misc_exception_handler': exception.c:133: warning: unused variable `i' exception.c:135: warning: unused variable `variant' make[2]: *** [libmisc_la-exception.lo] Error 1 make[2]: Leaving directory `/home/ipso/downloads/reiser4progs-0.4.14/libmisc' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/ipso/downloads/reiser4progs-0.4.14' make: *** [all] Error 2 It is because of paranoid -Werror flag. ./configure --disable-werror will help you. However, if your system will have readline (as on systems which are used by reiser4progs developers :-) headers that warning disappear. [...] -- Alex.
Re: IRC channel for reiser4 (and reiserfs)
On Mon, Sep 01, 2003 at 01:34:26PM +0400, Nikita Danilov wrote: Hello, we now have IRC channel for questions and discussion of reiser4 (and, occasionally, reiserfs): irc://irc.oftc.net:6667/#reiser4 A reference to it from namesys.com website would be good. -- Alex.
Re: reiser4 snapshot for August 26th.
On Tue, Aug 26, 2003 at 01:14:46PM -0600, Steven Cole wrote: On Tue, 2003-08-26 at 12:41, Alex Zarochentsev wrote: On Tue, Aug 26, 2003 at 10:41:45PM +0400, Hans Reiser wrote: Mr. Demidov, if you put code that does not compile into our tree you need to make the config option for it be invisible. There is such an option already, CONFIG_REISER4_FS_SYSCALL, seems it is off by default. Yes, but I the simple minded user that I am turned it on without reading the Kconfig help carefully. Now, it's off, and it compiles. But, now for more interesting stuff: [EMAIL PROTECTED] steven]# cd / [EMAIL PROTECTED] /]# mkdir share_r4 [EMAIL PROTECTED] /]# mount -t reiser4 /dev/hda11 /share_r4 [EMAIL PROTECTED] /]# df -T FilesystemType 1K-blocks Used Available Use% Mounted on /dev/hda1 ext3 241116 89449139219 40% / /dev/hda9 ext320556656 16526188 4030468 81% /home none tmpfs 126784 0126784 0% /dev/shm /dev/hda8 ext3 241116 4711223957 3% /tmp /dev/hda6 ext3 3012204 2507596351592 88% /usr /dev/hda7 ext3 489992 70721393971 16% /var df: `/share_r4': Value too large for defined data type I can't reproduce that. Do you see df errors each time you mount just created reiser4 fs? Can you provide additional information about your system: distro, libc which you used? My hypothesysis is that libc statfs or df itself want to convert free inodes result parameter which is __u64 to shorter data type. reiser4_statfs() sets kstatfs-f_ffree to a large value which is close to 2^64. I have recently run mkfs.reiser4 on /dev/hda11 with no options. The reiser4progs version is 0.4.12. I made a local clone of the 2.6-test bk tree on the new reiser4 file system and that worked OK. I then did a time bk -r check -acv, twice for both reiser4 and ext3. Here are the results for the second run for each (I neglected to preserve the results for the initial bk -r check -acv): Reiser4: real1m27.774s user0m33.685s sys 0m16.059s Ext3: real2m55.179s user0m32.752s sys 0m5.835s Nice work. I'll try to break Reiser4 now. Steven -- Alex.
Re: snapshots-2003.08.11 two files patch failed ?
On Sat, Aug 16, 2003 at 09:15:51AM +0400, Alex Zarochentcev wrote: On Fri, Aug 15, 2003 at 09:15:33PM +0800, Thomas Graham wrote: there have two file are failed to patch, I try to patch it against 2.5.70 and 2.5.75, does it matter ? use 2.6.0-test2 Sorry, it is against 2.6.0-test3, as it said in the READ.ME file. -- HK Celtic Orchestra leader and coordanator: Thomas Graham Lau Phone number: 852-93239670(24hours a day, 7days a week non-stop phone) Web site: http://sml.dyndns.org Email: [EMAIL PROTECTED] -- Alex. -- Alex.
Re: snapshots-2003.08.11 two files patch failed ?
On Fri, Aug 15, 2003 at 09:15:33PM +0800, Thomas Graham wrote: there have two file are failed to patch, I try to patch it against 2.5.70 and 2.5.75, does it matter ? use 2.6.0-test2 -- HK Celtic Orchestra leader and coordanator: Thomas Graham Lau Phone number: 852-93239670(24hours a day, 7days a week non-stop phone) Web site: http://sml.dyndns.org Email: [EMAIL PROTECTED] -- Alex.
