All of lore.kernel.org
 help / color / mirror / Atom feed
* AMD64/Reiser4 testing and problems
@ 2004-12-02 23:13 Isaac Chanin
  2004-12-04 21:27 ` Alex Zarochentsev
  0 siblings, 1 reply; 6+ messages in thread
From: Isaac Chanin @ 2004-12-02 23:13 UTC (permalink / raw)
  To: reiserfs-list

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

The commands I tried were as follows:
(r4 was a 512mb file made by dd)
mount -o loop /root/r4 /root/r4dir (worked)
df -h (worked)
cd /root/r4 (worked)
ls (worked)
ls -la (worked)
mkdir linux (worked)
cp -r /usr/src/linux linux (worked, but the program hung at the end, 
kill -9 had no effect)
ls (worked, but the program hung at the end, kill -9 had no effect)
cd /root/r4 (no output, program crashed immediately)


Thanks for taking the time to read over the problems - and if there's 
anymore testing I could do or whatnot just ask; and, thanks for making 
what will (hopefully) soon be the fastest file system to work on my 
computer!

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: AMD64/Reiser4 testing and problems
@ 2004-12-08  8:04 Isaac Chanin
  0 siblings, 0 replies; 6+ messages in thread
From: Isaac Chanin @ 2004-12-08  8:04 UTC (permalink / raw)
  To: reiserfs-list

Hey Alex,

Thanks for the patch, I wish there was more I could say, but so far I 
haven't been able to produce any problems whatsoever with this new patch 
on reiser4/amd64.  The things I tried were Jake Maciejewski's kernel 
compiling command which I modified slightly to better suit my system. 
The following ran for at least 30 minutes and a couple of iterations of 
kernel compiling: for i in `seq 1 20` ; do make mrproper ; cat 
/boot/2.6.10-r4-mm-config > .config ; make ; echo $i ; done & for i in 
`seq 1 5` ; do dd; if=/dev/zero of=large_file bs=1M count=20k ; rm 
large_file ; echo $i ; done

I also tried filling the filesystem, and testing for data retention from 
forced umounts.  For fun I also tried running ext2 and a second resier4 
mounted on files inside the reiser4 filesystem.  Everything worked fine, 
I was unable to produce a single error in the logs.

The only thing that could possibly have been said to have gone wrong, 
was when I tried force umounting with open file handles, that didn't 
work out quite as well - however, for all sane usage resier4 seems 
rather stable on amd64 to me.

I will try running an entire linux system on it once I get the time, and 
perhaps then will be able to give you some more feedback.

So once again, thanks for the patch, and best of luck with resier4,

Isaac


Alex Zarochentsev wrote:

 > 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.c    Sun 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);
 >


^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: AMD64/Reiser4 testing and problems
@ 2004-12-21  5:46 Isaac Chanin
  2004-12-22  5:45 ` Isaac Chanin
  0 siblings, 1 reply; 6+ messages in thread
From: Isaac Chanin @ 2004-12-21  5:46 UTC (permalink / raw)
  To: reiserfs-list


Hello Alex et al,

After my last e-mail was so useless I figured I would follow it up with 
a more useful one, so what I've attempted to do is build and entire AMD64 
system on top of reiser4 (aside from boot, still ext2 there), and, in the
process I've run into two more bugs.


The first bug would give output (without resier4 debugging options 
enabled) like:

Dec 20 02:33:14 [kernel] reiser4[portageq(31681)]: traverse_tree 
(fs/reiser4/search.c:789)[nikita-373]:
Dec 20 02:33:14 [kernel] reiser4[portageq(31681)]: traverse_tree 
(fs/reiser4/search.c:755)[nikita-1481]:

over and over until the system was rebooted (whatever process - it has so 
far happened with portageeq, wget, and i think nano - becomes completely 
unresponsive to all kill signals and takes 100% cpu time.)

So far I have absolutely no clue when this bug occurs, as it seems to pop 
up completely randomly (copying a large file from one reiser4 logical 
partition to another, wget'ing a tiny file to a reiser4 partition.)  About 
the only connection I could find was with writing to the filesystem.

I could only produce this bug on 2.6.10-rc2-mm4; linux-2.6.10-rc3-mm1 
(both with Alex's patch) would boot (onto reiser3) but wouldn't do much
else.


This leads nicely into the other bug, which is that it does not seem 
possible to boot into a resier4 system (ext2 for boot, resier4 for /, et 
cetera) on an AMD64.  I don't have any log output as the system hangs 
before it can load the logger, and no screen output because my laptop (no
matter what framebuffer configuration I use) has a completely black boot-up
screen until after the initial kernel loading is complete.  Neither 
2.6.10-rc2-mm4 nor linux-2.6.10-rc3-mm1 can get any farther in the booting 
process either.

It occured to me that this could simply be happeneing because of all of 
the failures the partitions had while getting the system installed on them 
(though fsck.resier4 seemed to handle them all nicely, at the time.)  So 
perhaps this bug is not really a bug, and more of a misconfiguration on my 
part - just a thought.


I'll put some full (with reiser4 debug options enabled in the kernel - 
still can't believe I forgot those) logs up at 
http://users.wpi.edu/~chanin/newr4log.txt once I can get the first bug to 
occur again (or if I can somehow get some output from the second.)  I 
should be able to get them up later tonight and if not then, probably 
sometime tomorrow.


Thanks,

Isaac


^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: Recursive modfied-timestamp?
@ 2005-01-01 21:49 Hans Reiser
  2005-01-02  4:22 ` AMD64/Reiser4 testing and problems Isaac Chanin
  0 siblings, 1 reply; 6+ messages in thread
From: Hans Reiser @ 2005-01-01 21:49 UTC (permalink / raw)
  To: Fred Schaettgen; +Cc: reiserfs-list

Fred Schaettgen wrote:

>Hi,
>
>Does reiser4 support something like recursive last-modified-timestamps? What I 
>mean is an attribute which contains the latest modification date of all 
>subdirectories and files below a given directory.
>
>Actually I am also curios if there are any other linux file system which 
>support that. The reason I'm asking on the reiserfs mailinglist is that 
>reiser4 seems to be the filesystem which is most open for new features.
>Could this be implemented as some sort of plugin for reiser4? Or does/will 
>reiser4 support any other concepts which can be used for that purpose?
>
>The purpose btw. is to find all modified files in a tree as fast as possible. 
>There are quite a lot of application which would benefit from it: desktop 
>search engines, locate, build systems, tools which visualize contents of a 
>file system (like fsview in KDE), backup tools etc.
>
>I know that modifying an attibute recursively on every update of the stat data 
>would have a huge perfomance impact, but there are many things that could be 
>done to keep the extra load low for most of the time.
>It seem very likely that this is an idea which was discussed over and over 
>again already, but I really didn't find much about it. As a KDE developer, 
>I'm not much involved in filesystems, so maybe I'm just looking for the wrong 
>keywords?
>
>Fred
>
>  
>
We intend to implement inheritance of metadata, which could  be made to 
accomplish what you are asking for I think.  Nobody is coding that at 
the moment though....

We are indeed open to semantic enhancements.

^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2005-01-02  4:22 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-12-02 23:13 AMD64/Reiser4 testing and problems Isaac Chanin
2004-12-04 21:27 ` Alex Zarochentsev
  -- strict thread matches above, loose matches on Subject: below --
2004-12-08  8:04 Isaac Chanin
2004-12-21  5:46 Isaac Chanin
2004-12-22  5:45 ` Isaac Chanin
2005-01-01 21:49 Recursive modfied-timestamp? Hans Reiser
2005-01-02  4:22 ` AMD64/Reiser4 testing and problems Isaac Chanin

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.