why hang-up on sync?
Whats up with sync ? this is what happens when i run hdparm -t /dev/hda
( i tested /dev/hda with testdisk tool, and everything seems fine)
# df -h
FilesystemSize Used Avail Use% Mounted on
/dev/hda1 3.0G 2.5G 326M 89% /
/dev/hda2 139G 72G 68G 52% /home
tmpfs 443M 0 443M 0% /dev/shm
# mount
/dev/hda1 on / type ext3 (rw,errors=remount-ro)
/dev/hda2 on /home type reiser4 (rw,noatime,nodiratime)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
Linux 2.6.14.3 with latest reiser4 patch.
I'm attaching strace from hdparm -t /dev/hda
execve(/sbin/hdparm, [hdparm, -t, /dev/hda], [/* 20 vars */]) = 0
uname({sys=Linux, node=werewolf.cba.pl, ...}) = 0
brk(0) = 0x8056000
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or directory)
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7fb
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=34708, ...}) = 0
old_mmap(NULL, 34708, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fa7000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/lib/tls/libc.so.6, O_RDONLY)= 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320O\1..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1266800, ...}) = 0
old_mmap(NULL, 1272764, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb7e7
old_mmap(0xb7f9d000, 32768, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12d000) = 0xb7f9d000
old_mmap(0xb7fa5000, 7100, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7fa5000
close(3)= 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7e6f000
mprotect(0xb7f9d000, 20480, PROT_READ) = 0
set_thread_area({entry_number:-1 - 6, base_addr:0xb7e6f6c0, limit:1048575,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0,
useable:1}) = 0
munmap(0xb7fa7000, 34708) = 0
open(/dev/hda, O_RDONLY|O_NONBLOCK) = 3
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7faf000
write(1, \n, 1) = 1
write(1, /dev/hda:\n, 10) = 10
ioctl(3, BLKGETSIZE64, 0xbfbc3600) = 0
shmget(IPC_PRIVATE, 2097152, 0600) = 0
shmctl(0, IPC_64|SHM_LOCK, 0) = 0
shmat(0, 0, 0) = 0xb7c6f000
shmctl(0, IPC_64|IPC_RMID, 0) = 0
sync(
reiser4, crashing
Hello, i've been experiencing crashes for more than 2 months, and i'm trying to figure out what is causing it. I sent to this list few description of my problem, but you said it is not fault of reiser4. I still have to hard proofs, but my apt-get is still very slow, and vim is also not very fast (even when my reiser4 partition is mounted with noatime and nodiratime) last thing im noticing just before crash is this process: 965 root 10 -5 000 D 0.8 0.0 0:02.35 ent:hda2! when everything works fine, its also in memory but like this: root 965 0.0 0.0 0 0 ?S 17:41 0:00 [ent:hda2.] maybe its normal, but after i tried to get help on many forums, and from many people, nobody really knows whats going on on my server. its kernel 2.6.14.3 with latest reiser4 patch for this kernel, and i have these problems for more than 2 months, i've been stracing/gdbimg all process on my server, especially apache as it is taking the most resources, but i cant figure out anything strange. besides IOWait is huge, like 30% on procinfo. i heard in some situations it is possible for reiser4 developer to log in on server and see everything. Since i've been trying to debug it for so long, is it possible to do it in this situation? There is nothing in any logs, so i can't do anything, i could turn on reiser4.debug but my machine is busy and i dont know how this will affect the performance
Re: Problem with Reiser4
Tobi Kunze wrote: Hi, i have a strange problem with my system and i think it might be caused by reiser4. If i write a file with vim, even if it is just a word, my harddisk starts to write like mad for a few seconds and vim is not responding. The problem does not exist with nano or emacs. One might now guess it is a vim problem, but it behaves totally normal if i write the file on a fat32 partition on the same disk. Vim just quits and i even cannot hear my harddisk write. Another reason why i think it is a reiser problem is that dpkg got really slow with the last few kernels. It takes very long to extract and install the deb packages. At the moment i am using Debian and 2.6.14.1 vanilla with reiser4 patch. The problem also exists on 2.6.14-mm2. With kind regards Tobias Kunze try to remount your reiser4 partition with noatime,nodiratime options, it should help. (it will still be a little slower that what it used to be, but much better anyways)
Re: reiser4: fd -1 problem ?
Vladimir V. Saveliev wrote: Hello Artur Makówka wrote: Hello, i've been investigating this problem for few weeks, and it seems reiser4 can be reason for this. My apache process is from no clear reason suddenly peaking to 95% CPU usage and it stays that way until i kill it and start again. It happens 6-7 times a day, i have hosting services on my server. I thought it was apache fault, but it strings shows this: [pid 31610] munmap(0xb6f29000, 729088) = 0 [pid 31610] mmap2(NULL, 729088, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6f29000 [pid 31610] munmap(0xb6f29000, 729088) = 0 [pid 31610] mmap2(NULL, 729088, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6f29000 in endless loop, when this strange 'lock' happens. is it a problem of fd -1 ? -1 is fine because MAP_ANONYMOUS is set. of course that could be also apache bug, that it can't handle wrong fd number, but why there is wrong fd number? they are using MAP_ANONYMOUS, fd is ignored in that case. i ran reiser4.fsck and it didnt help. what did reiser4.fsck report? No corruptions found? i use kernel 2.6.12.6 with latest 2.6.12 reiser4 patch, as it seemed the most stable from recent releases. What could be the problem here, and how can i repair it ? should i keep running fsck.reiser4 until it finds it ? it doesnt happen very often, but like i said 6-7 times a day, but it varies, sometimes it more often sometimes almost 0. thanks in advance for response. (this is probably not Apache issue, i already asked for this many many times) so far it does not look as reiser4 problem either. Flex, can we have apache server running on reiser4 for test purposes? this happens only sometimes, and changing to latest 2.6.14 kernel and reiser4 patch didnt help. i suppose it would be hard to simulate this, i get only few such errors per day and its pretty busy server (and i never get these at night which means the fact that its busy is important i guess) no idea if its reiser4, but that was my thought... maybe not, i don't know any suggestions to what i should do next , when changing to never kernel/fs didn't help? i will run fsck.reiser4 --build-fs tonight, but if this wont help i have no idea
reiser4: fd -1 problem ?
Hello, i've been investigating this problem for few weeks, and it seems reiser4 can be reason for this. My apache process is from no clear reason suddenly peaking to 95% CPU usage and it stays that way until i kill it and start again. It happens 6-7 times a day, i have hosting services on my server. I thought it was apache fault, but it strings shows this: [pid 31610] munmap(0xb6f29000, 729088) = 0 [pid 31610] mmap2(NULL, 729088, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6f29000 [pid 31610] munmap(0xb6f29000, 729088) = 0 [pid 31610] mmap2(NULL, 729088, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6f29000 in endless loop, when this strange 'lock' happens. is it a problem of fd -1 ? of course that could be also apache bug, that it can't handle wrong fd number, but why there is wrong fd number? i ran reiser4.fsck and it didnt help. i use kernel 2.6.12.6 with latest 2.6.12 reiser4 patch, as it seemed the most stable from recent releases. What could be the problem here, and how can i repair it ? should i keep running fsck.reiser4 until it finds it ? it doesnt happen very often, but like i said 6-7 times a day, but it varies, sometimes it more often sometimes almost 0. thanks in advance for response. (this is probably not Apache issue, i already asked for this many many times)
Re: More Slowdown - testscript [noatime,nodiratime]
Avuton Olrich wrote: On 11/23/05, Sander [EMAIL PROTECTED] wrote: Please don't forget that the behavior without 'noatime' is new. I never had my disk mounted 'noatime', and until recently did not experience the huge slowdown. I assume the other people who reported this agree. So whether or not fsync needs to be optimized, something changed in Reiser4 or -mm that causes the huge slowdown. Agreed, I have mounted with noatime nodiratime and still get time when interactivity is extremely poor. Mostly with the vim test. I'm not sure the problem is /fixed/ but it does seem much better. I also agree, i see improvement, but there was a time when noatime nodiratime wasn't needed to not cause slowdowns. But i'm sure i will leave noatime/nodiratime set to off anyways, as this is mot much useful for me.
Re: More Slowdown
Ingo Bormuth wrote: On 2005-11-22 11:23, Marcel Hilzinger wrote: Did you ever think about, that this is not a reiser4 problem, but a kernel bug or a problem related to hal? Just to mention again: I do not see the problem on my Laptop. I use a the clean vanilla-2.6.14.2 kernel manually patched with reiser-for-2.6.14-1. It's a slow laptop with broken DMA so I should realize if there was something wrong. Afaik every poster complaining so far had mm-kernels, larger patchsets or additional stuff as swsusp2. So: Do jou see the slowdown/crashes in vanilla ? yes, like i said several times (and as others also said) this bug is on vanilla 2.6.14.2 or 2.6.13.x. The fact that this bug is not on every computer doesn't mean it don't exists. I have big slowdowns on 2.6.13 or 2.6.14 sometimes causing crash - and one time it caused database loss. (the bug itself doesnt cause crash i suppose,but the traffic i get on this server + this bug can cause crash) its stable at 2.6.12.6
Re: More Slowdown or reiser4 update for 2.6.14-mm2
E.Gryaznova wrote: Unfortunately we are not able to reproduce this slowdown. Would you please provide more info?: Is this 2.6.14-mm2 bad sync/fsync performance reproducible on fresh created reiser4 too? Are these values stable reproducible? If you run this test several time -- do you have the same results? Would you please send df -T output and 2.6.14-mm2 config file? Did you try this test on ext2? If no -- would you please try it on ext2 for the same kernels and send us the results? Thanks, Lena I created reiser4 3 months ago, on 2.6.11 kernel. at the beggining i copied to it around 26GB of data. now its 50GB but the data wasn't copied like the first 26GB, because its free hosting server and users just uploaded their usually small files. The easiest way to reproduce this bug was creating/saving a file with vim. (could be helpful to start few I/O operations in the background) i had only /var and /home as reiser4, and this bug was crashing my server quite often - LA jumped up suddenly very high. another way to cause slowdown was using apt-get or lilo. i can't switch to 2.6.14-mm2, im using 2.6.12 because this bug is almost not here. (hard to say, i get very short slowdowns, but that could be caused by anything, so no complains here) my output of df -T /dev/hda1 ext3 3099260 2592512349316 89% / /dev/hda2 reiser4 145016436 51498136 93518300 36% /home tmpfstmpfs 452704 0452704 0% /dev/shm (/var is symlink to /home/var) I can add 2.6.14.2 config, but i tested many many configuration options, and nothing helped. 2.6.14.2 also had this bug of course (using 2.6.14-1 reiser4 patch) and 2.6.13 and 2.6.13mm also had this bug. I personally cant do test like switching to 2.6.14-mm2, as this machine is being used by many users. Also, i think i have fragmentation around 0.16, but the output caused errors, and im not sure. i tried to do fsck.reiser4 -build-fs today at night, but that was working for 12 hours and didnt do much. (it repaired few lost inodes, but was starting another test when it was already 11 a.m. so i had to stop it) i will run masurefs in couple of days,after i have next occasion to first fix it, but i think my reiser4 is very higly fragmented. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.14.2 # Mon Nov 14 22:20:41 2005 # CONFIG_X86=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION=juice-1 CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y # CONFIG_IKCONFIG is not set CONFIG_INITRAMFS_SOURCE= # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set CONFIG_MPENTIUM4=y # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set CONFIG_X86_GENERIC=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_HPET_TIMER is not set # CONFIG_SMP is not set CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set # CONFIG_X86_UP_APIC is not set CONFIG_X86_TSC=y CONFIG_X86_MCE=y # CONFIG_X86_MCE_NONFATAL is not set #
Re: More Slowdown
Artur Makówka wrote: My slowdown problems are on my web server, so its concerning different things than Evolution. but this slowdown was very easy to notice when writing something with vim. Anyways, i remembered that i was using stable kernel without this happening some time ago. So i tested 2.6.14.x , 2.6.13.x mm and 2.6.13.x , and i still had system crashes. so i downgraded to 2.6.12.6 and the system is stable for more than 24 hours (first time in this month or even longer!) probably some processes were doing fsync often (or something similar) and the effect was raising LA and lock-up at the end. anyways, 2.6.12.6 (but other than .6 probably too) is, i think, bug free. maybe this will help. ok, now im 100% sure that 2.6.12.6 kernel + 2.6.12-3 reiser4 patch doesnt have this fsync bug, or at least its not causing any big slowdowns. The difference is really noticable. I don't know if i can do anything more to help you fix this bug. But do you know is it going to be fixed soon ? Thanks in advance
Re: More Slowdown
Thorsten Hirsch wrote: Hi, I've seen the mails in the mail archive concerning a slow-down problem with reiser4. Seems like I've got the same problem. My kernel is 2.6.14-mm2 (gentoo) and my default disk scheduler is anticipatory, but I've also tried cqf and I'd say that it depends on the application for which scheduler might be a bis faster. But they're both very slow and my load is very high. I've found out, that resizing the columns in evolution is also for me a good proof of this problem as it really creates a lot of hard disk activity. So I've done the same strace call as Craig Shelley: [cut] My slowdown problems are on my web server, so its concerning different things than Evolution. but this slowdown was very easy to notice when writing something with vim. Anyways, i remembered that i was using stable kernel without this happening some time ago. So i tested 2.6.14.x , 2.6.13.x mm and 2.6.13.x , and i still had system crashes. so i downgraded to 2.6.12.6 and the system is stable for more than 24 hours (first time in this month or even longer!) probably some processes were doing fsync often (or something similar) and the effect was raising LA and lock-up at the end. anyways, 2.6.12.6 (but other than .6 probably too) is, i think, bug free. maybe this will help.
Re: More Slowdown
Avuton Olrich wrote: It's funny that you mention vim. vim seems to be what _really_ makes my reiser4 do the 'slowdown'. I call it harddrive thrashing cause that's what my wife calls it when she hears it from 5 yards away :) Right before saving or saving/exiting it really does this thrashing, Thank god you said this because I didn't think this 'slowdown' was the same thing I was experiencing. avuton i've mentioned vim becouse someone else already mention it too :) But i remember that with vim i had very long pauses. also apt-get was slow. i don't even see the pattern, joe was also slowed, but not as much as vim. It's strange. does vim save its files in /tmp maybe ? or is there anything specific about vim that, for example, joe doesnt do? (and therefore much shorter slowdowns).
Re: Slowdown is gone apt-get works with updated reiser4. So nevermind...
Pat Double wrote: On Sunday 13 November 2005 08:05, Artur Makówka wrote: Thomas Kuther wrote: i was using anticipatory I/O as default in debian. i just did echo cfq /sys/block/hda/queue/scheduler. Hope its enough to change it. no noticed effects yet, i will give report, if anything changes. I tried changing the scheduler like this and it worked the first time with low load and my X session was not started. I tried it again and it locked up the filesystem I had to reboot and rebuild the filesystem. I was changing from cfq to anticipatory. Be careful! its ok, i changed from anticipatory to cfq also with append option in lilo (elevator=). but i'm afraid it didn't help. I got another crash today. as always - completely nothing in syslog or anywhere. i can't turn on reiser4 debugging - it will lower performance too much. i'm not sure what to do now. Is there any tool that will convert reiser4 to another fs ? (a stable one i mean...)
Re: Slowdown is gone apt-get works with updated reiser4. So nevermind...
Laurent Riffard wrote: Le 13.11.2005 01:55, Artur Makówka a écrit : [snip] one more thing im pretty sure of - the 2.6.13mm3 without any reiser4 additional patches (just clean 2.6.13mm3 as it has reiser4 already built) is working fine. i mean, im not sure if this bug still exists here, but im 100% sure i can write vim files easy without any downtime, so this is big difference. so for everyone with this bug - try clean 2.6.13mm3 from kernel.org. It worked for me. i will wait with this kernel for a patch to stable line. Also - i will test it a little more tomorrow to be sure that this version is bug free. Hello, It seems that fsync could be really slow when there is a lot of activity on the FS. I've done the following test : - on a reiser4 FS, unpack a fresh kernel tarball and start a compilation - open a new terminal, wait 1 minute and start editing a file on the same FS with vi. - hit :w and wait... $ strace -T vi foo 2strace_vi.log $ grep fsync strace_vi.log fsync(3)= 0 30.923808 $ My computer is a desktop with an Athlon XP 1600 and 512 Mb RAM. Write cache is disabled on the disk (hdparm -W0 /dev/hda). ~~ laurent it crashed today morning, so 2.6.13mm is not much better than 2.6.14. My fs is heavly used (but not overloaded) by many apache process or ftp process or postfix process. I have free hosting server and i think i will have to close this thing becouse for over a month its often downtime everyday. Could you please tell us if there is any idea of how to fix it? i would move to another more stable fs but its too much data...
Re: Slowdown is gone apt-get works with updated reiser4. So nevermind...
Thomas Kuther wrote: On Sun, 13 Nov 2005 13:29:25 +0100 Artur Makówka [EMAIL PROTECTED] wrote: it crashed today morning, so 2.6.13mm is not much better than 2.6.14. My fs is heavly used (but not overloaded) by many apache process or ftp process or postfix process. I have free hosting server and i think i will have to close this thing becouse for over a month its often downtime everyday. Could you please tell us if there is any idea of how to fix it? i would move to another more stable fs but its too much data.. hmm, wondering which I/O scheduler you guys are using. I had the same slowdowns and soft lockups till 10 minutes ago, when i switched from cfq to anticipatory I/O. I'm currently usig 2.6.15-rc1 + reiser4 from 2.6.14-mm2 I was in the middle of a big gentoo'ish emerge, desktop almost unusable. but now with anticipatory all seems fine so far. the compile seems a lot faster. no soft lockup trying to use vim or locate... hmmm regards tom i was using anticipatory I/O as default in debian. i just did echo cfq /sys/block/hda/queue/scheduler. Hope its enough to change it. no noticed effects yet, i will give report, if anything changes.
Re: reiser4 in 2.6.14 - lockups with mmapped files
rvalles napisał(a): Still having the same problem, with 2.6.14.2 patched with 2.6.14-1 reiser4 patch. It's easy to trigger it while editing a file with vim, and it does take a hell of a long wait (while it hits the disk for a minute or so, sometimes) for it to unlock. or if you try to run lilo... or dpkg/apt-get its also very easy to trigger it this way. it hangs my server from time to time ... is there any progress in fixing that?
Re: Slowdown is gone apt-get works with updated reiser4. So nevermind...
On Saturday 12 November 2005 06:38, Hans Reiser wrote: Being seamless, cleanly implemented, and requiring little or no admin work, matters a lot to end users. Amen, Brother! Yes, users can do what you said with rsync, but it is important that it be no more work than specifying a --use-versioning mount option, and even that is beyond most users (but that is where defaults come in to help them). The namespace for the past versions should be as cleanly done as WAFL does them. Whether space gets freed automatically when space gets 10% is another mount option. Where we might do better than WAFL is in allowing touching filename//checkin to cause a version to get recorded, rather than doing it at particular times. Hans Of particular concern is that the name space should (somehow) allow me to easily grab version by date, even if the file hadn't changed for the two weeks before that, and in fact still hasn't changed... Make it really easy to grab all or some files by wildcard and with a specific revision, even when not every file changed with that revision. Oh, BTW. The slowdown as I called it is still there. I guess I spoke to soon. The specific symptom is that the effected process locks for a time, usually just a second or two, but sometimes a minute or two and and at least once for many many minutes. I think that the crash (soft lockup) that I reported earlier is related as well. And it sounds like the comment that rvalles had about lockups with mmaped files, except that it doesn't lock up permanently. Just for a second or three usually. . yes, its exactly the same with my case. it locks up just for few seconds, sometimes one/two minutes when using for example vim... but sometimes it locks up completly, machine is responding to ping but i cannot login, dns is not working and all services seems down. (but it is replying to ping) it can happen up to 2-3 times per day. (usually only once per day or once per 2 days) there is completly no info about anything in any log files. i already installed latest kernel 2.6.14.2 and lates 2.6.14-1 reiser4 patch and its the same. My users are getting angry becouse of the downtimes... is this bug noticed by dev team ? This seems really serious, as it is causing sporadic crashesh and often short lock-ups. Any quick-fix please? It is happening for quite some time now so this is not new bug. thats why i keep asking... is it worked on or not? thanks in advance
Re: Slowdown is gone apt-get works with updated reiser4. So nevermind...
Hans Reiser wrote: John Gilmore wrote: On Saturday 12 November 2005 06:38, Hans Reiser wrote: Being seamless, cleanly implemented, and requiring little or no admin work, matters a lot to end users. Amen, Brother! Yes, users can do what you said with rsync, but it is important that it be no more work than specifying a --use-versioning mount option, and even that is beyond most users (but that is where defaults come in to help them). The namespace for the past versions should be as cleanly done as WAFL does them. Whether space gets freed automatically when space gets 10% is another mount option. Where we might do better than WAFL is in allowing touching filename//checkin to cause a version to get recorded, rather than doing it at particular times. Hans Of particular concern is that the name space should (somehow) somehow = filename/versions/version_number and ls -l filename/versions ? allow me to easily grab version by date, even if the file hadn't changed for the two weeks before that, and in fact still hasn't changed... Make it really easy to grab all or some files by wildcard and with a specific revision, even when not every file changed with that revision. Oh, BTW. The slowdown as I called it is still there. I guess I spoke to soon. The specific symptom is that the effected process locks for a time, usually just a second or two, but sometimes a minute or two and and at least once for many many minutes. I think that the crash (soft lockup) that I reported earlier is related as well. And it sounds like the comment that rvalles had about lockups with mmaped files, except that it doesn't lock up permanently. Just for a second or three usually. zam, please comment. one more thing im pretty sure of - the 2.6.13mm3 without any reiser4 additional patches (just clean 2.6.13mm3 as it has reiser4 already built) is working fine. i mean, im not sure if this bug still exists here, but im 100% sure i can write vim files easy without any downtime, so this is big difference. so for everyone with this bug - try clean 2.6.13mm3 from kernel.org. It worked for me. i will wait with this kernel for a patch to stable line. Also - i will test it a little more tomorrow to be sure that this version is bug free.
how to apply lates reiser4 broken-out patch ?
hi, how can i apply all patches that are inside broken-out package (for reiser4 2.6.13) ? also, what does it mean in practice this broken-out ? ( i know its not reiser questoin, the second one, but i maybe someone will answer anyways) sorry for such basic questions, but there is no description on reiser website how to deal with many patches, in what order should i patch them , or why there is no 1 release with all patched already applied ) thanks in advance -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.12.4/142 - Release Date: 2005-10-18
Re: latest 2.6.13 reiser4 patch
Will it work also with 2.6.13.2 kernel ? or is it only for 2.6.13 ( or 2.6.13.1 ) i couldnt find any information about this on page, and i want to be sure... I used it fine with 2.6.13.2... but my wireless card isn't supported there. (it's been included in 2.6.14x, so it was never patches against 2.6.13.. I tried backporting my wireless driver but there were a lot of changes in both directions). The patch also applies cleanly against 2.6.14-rc1/2 but 2.6.14-rc1/2 panic on initrd uncompress for me, and I can't troubleshoot it because the backtrace scrolls my screen and I can't do a serial console on my laptop. :( In any case I tested reiser4 out some on 13.2, and the only bug I hit was a panic on unmount. but is there some official statment about using 2.6.x reiser4 patches with 2.6.x.x kernels? i mean, does patch called reiser 4 2.6.13 patch is also intended to work with 2.6.13.2 for example or only with 2.6.13 ?
Re: latest 2.6.13 reiser4 patch
Will it work also with 2.6.13.2 kernel ? or is it only for 2.6.13 ( or 2.6.13.1 ) i couldnt find any information about this on page, and i want to be sure... sorry for resending, but no answer has been given
Re: reiser4 crashes
Hello Artur Makówka wrote: Hello, my server crashed few times latetly, and the only strange thing i found in logs, are reiser4 entries just before every crash: #1 crash: kern.log:Sep 27 21:09:06 werewolf kernel: reiser4[pure-ftpd-mysql(18871)]: parse_node40 (fs/reiser4/plugin/node/node40.c:746)[nikita-494]: kern.log:Sep 27 21:09:06 werewolf kernel: reiser4[pure-ftpd-mysql(18871)]: extent2tail .. Sep 28 13:59:06 werewolf kernel: reiser4[pure-ftpd-mysql(30231)]: parse_node40 (fs/reiser4/plugin/node/node40.c:746)[nikita-494]: Sep 28 13:59:06 werewolf kernel: WARNING: Wrong level found in node: 1 != 227 Sep 28 13:59:06 werewolf kernel: reiser4[pure-ftpd-mysql(30231)]: extent2tail (fs/reiser4/plugin/file/tail_conversion.c:666)[nikita-2282]: Sep 28 13:59:06 werewolf kernel: WARNING: Partial conversion of 4773593: 0 of 1: -5 Sep 28 13:59:06 werewolf kernel: reiser4[pure-ftpd-mysql(30231)]: release_unix_file (fs/reiser4/plugin/file/file.c:2297)[nikita-3233]: Sep 28 13:59:06 werewolf kernel: WARNING: Failed to convert in release_unix_file (4773593) this is quite traffic-heavy server (free hosting with lots of accounts) im using reiser4 , kernel 2.6.12.3 with 2.6.12 latest reiser4 patches, reiser4progs 1.0.5, and its Debian. those entries i pasted logged like few minutes (or even less) before every crash, and they happen other than these 'crashing' situations.. can you help me? I guess that your reiser4 filesystem is corrupted. You should fsck.reiser4 it. i'm doing it right now (with --build-fs option ) , but why it happend? i really dont think its hardware bug. is it reiser4 bug?
latest 2.6.13 reiser4 patch
Will it work also with 2.6.13.2 kernel ? or is it only for 2.6.13 ( or 2.6.13.1 ) i couldnt find any information about this on page, and i want to be sure...
reiser4 crashes
Hello, my server crashed few times latetly, and the only strange thing i found in logs, are reiser4 entries just before every crash: #1 crash: kern.log:Sep 27 21:09:06 werewolf kernel: reiser4[pure-ftpd-mysql(18871)]: parse_node40 (fs/reiser4/plugin/node/node40.c:746)[nikita-494]: kern.log:Sep 27 21:09:06 werewolf kernel: reiser4[pure-ftpd-mysql(18871)]: extent2tail (fs/reiser4/plugin/file/tail_conversion.c:666)[nikita-2282]: kern.log:Sep 27 21:09:06 werewolf kernel: reiser4[pure-ftpd-mysql(18871)]: release_unix_file (fs/reiser4/plugin/file/file.c:2297)[nikita-3233]: kern.log:Sep 27 21:09:08 werewolf kernel: reiser4[pure-ftpd-mysql(15867)]: parse_node40 (fs/reiser4/plugin/node/node40.c:746)[nikita-494]: kern.log:Sep 27 21:09:08 werewolf kernel: reiser4[pure-ftpd-mysql(15867)]: cut_tree_object (fs/reiser4/tree.c:1723)[nikita-2861]: kern.log:Sep 27 21:09:08 werewolf kernel: reiser4[pure-ftpd-mysql(18812)]: parse_node40 (fs/reiser4/plugin/node/node40.c:746)[nikita-494]: kern.log:Sep 27 21:09:08 werewolf kernel: reiser4[pure-ftpd-mysql(18812)]: extent2tail (fs/reiser4/plugin/file/tail_conversion.c:666)[nikita-2282]: kern.log:Sep 27 21:09:08 werewolf kernel: reiser4[pure-ftpd-mysql(18812)]: release_unix_file (fs/reiser4/plugin/file/file.c:2297)[nikita-3233]: kern.log:Sep 27 21:09:08 werewolf kernel: reiser4[pure-ftpd-mysql(18883)]: parse_node40 (fs/reiser4/plugin/node/node40.c:746)[nikita-494]: kern.log:Sep 27 21:09:08 werewolf kernel: reiser4[pure-ftpd-mysql(18883)]: cut_tree_object (fs/reiser4/tree.c:1723)[nikita-2861]: kern.log:Sep 27 21:09:08 werewolf kernel: reiser4[pure-ftpd-mysql(18883)]: extent2tail (fs/reiser4/plugin/file/tail_conversion.c:666)[nikita-2282]: kern.log:Sep 27 21:09:08 werewolf kernel: reiser4[pure-ftpd-mysql(18883)]: release_unix_file (fs/reiser4/plugin/file/file.c:2297)[nikita-3233]: kern.log:Sep 27 21:09:08 werewolf kernel: reiser4[pure-ftpd-mysql(15867)]: parse_node40 (fs/reiser4/plugin/node/node40.c:746)[nikita-494]: kern.log:Sep 27 21:09:08 werewolf kernel: reiser4[pure-ftpd-mysql(15867)]: cut_tree_object (fs/reiser4/tree.c:1723)[nikita-2861]: kern.log:Sep 27 21:15:31 werewolf kernel: reiser4[pure-ftpd-mysql(18809)]: parse_node40 (fs/reiser4/plugin/node/node40.c:746)[nikita-494]: kern.log:Sep 27 21:15:31 werewolf kernel: reiser4[pure-ftpd-mysql(18809)]: extent2tail (fs/reiser4/plugin/file/tail_conversion.c:666)[nikita-2282]: kern.log:Sep 27 21:15:31 werewolf kernel: reiser4[pure-ftpd-mysql(18809)]: release_unix_file (fs/reiser4/plugin/file/file.c:2297)[nikita-3233]: kern.log:Sep 27 21:26:48 werewolf kernel: reiser4[pure-ftpd-mysql(18685)]: parse_node40 (fs/reiser4/plugin/node/node40.c:746)[nikita-494]: kern.log:Sep 27 21:26:48 werewolf kernel: reiser4[pure-ftpd-mysql(18685)]: extent2tail (fs/reiser4/plugin/file/tail_conversion.c:666)[nikita-2282]: kern.log:Sep 27 21:26:48 werewolf kernel: reiser4[pure-ftpd-mysql(18685)]: release_unix_file (fs/reiser4/plugin/file/file.c:2297)[nikita-3233]: kern.log:Sep 27 21:33:16 werewolf kernel: reiser4[pure-ftpd-mysql(18548)]: parse_node40 (fs/reiser4/plugin/node/node40.c:746)[nikita-494]: kern.log:Sep 27 21:33:16 werewolf kernel: reiser4[pure-ftpd-mysql(18548)]: extent2tail (fs/reiser4/plugin/file/tail_conversion.c:666)[nikita-2282]: kern.log:Sep 27 21:33:16 werewolf kernel: reiser4[pure-ftpd-mysql(18548)]: release_unix_file (fs/reiser4/plugin/file/file.c:2297)[nikita-3233]: #2 crash: Sep 28 13:55:42 werewolf kernel: reiser4[pure-ftpd-mysql(31716)]: parse_node40 (fs/reiser4/plugin/node/node40.c:746)[nikita-494]: Sep 28 13:55:42 werewolf kernel: WARNING: Wrong level found in node: 1 != 227 Sep 28 13:55:42 werewolf kernel: reiser4[pure-ftpd-mysql(31716)]: extent2tail (fs/reiser4/plugin/file/tail_conversion.c:666)[nikita-2282]: Sep 28 13:55:42 werewolf kernel: WARNING: Partial conversion of 4774068: 0 of 1: -5 Sep 28 13:55:42 werewolf kernel: reiser4[pure-ftpd-mysql(31716)]: release_unix_file (fs/reiser4/plugin/file/file.c:2297)[nikita-3233]: Sep 28 13:55:42 werewolf kernel: WARNING: Failed to convert in release_unix_file (4774068) Sep 28 13:55:42 werewolf kernel: reiser4[pure-ftpd-mysql(1826)]: parse_node40 (fs/reiser4/plugin/node/node40.c:746)[nikita-494]: Sep 28 13:55:42 werewolf kernel: WARNING: Wrong level found in node: 1 != 227 Sep 28 13:55:42 werewolf kernel: reiser4[pure-ftpd-mysql(1826)]: cut_tree_object (fs/reiser4/tree.c:1723)[nikita-2861]: Sep 28 13:55:42 werewolf kernel: WARNING: failure: -5 Sep 28 13:56:04 werewolf kernel: reiser4[pure-ftpd-mysql(31745)]: parse_node40 (fs/reiser4/plugin/node/node40.c:746)[nikita-494]: Sep 28 13:56:04 werewolf kernel: WARNING: Wrong level found in node: 1 != 227 Sep 28 13:56:04 werewolf kernel: reiser4[pure-ftpd-mysql(31745)]: cut_tree_object (fs/reiser4/tree.c:1723)[nikita-2861]: Sep 28 13:56:04 werewolf kernel: WARNING: failure: -5 Sep 28 13:56:04 werewolf kernel: reiser4[pure-ftpd-mysql(31745)]: extent2tail
Re: reiser4 crashes
now it is crashing even more often, i will paste more logs, as it seems to changed a little: Sep 28 19:28:52 werewolf kernel: reiser4[pure-ftpd-mysql(7092)]: parse_node40 (fs/reiser4/plugin/node/node40.c:746)[nikita-494]: Sep 28 19:28:52 werewolf kernel: WARNING: Wrong level found in node: 1 != 111 Sep 28 19:28:52 werewolf kernel: reiser4[pure-ftpd-mysql(7092)]: make_space (fs/reiser4/carry_ops.c:497)[nikita-1065]: Sep 28 19:28:52 werewolf kernel: WARNING: Error accessing right neighbor: -5 Sep 28 19:28:52 werewolf kernel: Unable to handle kernel NULL pointer dereference at virtual address 0078 Sep 28 19:28:52 werewolf kernel: printing eip: Sep 28 19:28:52 werewolf kernel: c01b02bd Sep 28 19:28:52 werewolf kernel: *pde = Sep 28 19:28:52 werewolf kernel: Oops: [#1] Sep 28 19:28:52 werewolf kernel: Modules linked in: Sep 28 19:28:52 werewolf kernel: CPU:0 Sep 28 19:28:52 werewolf kernel: EIP:0060:[carry_on_level+169/188] Not tainted VLI Sep 28 19:28:52 werewolf kernel: EFLAGS: 00010246 (2.6.12.3juice-1) Sep 28 19:28:52 werewolf kernel: EIP is at carry_on_level+0xa9/0xbc Sep 28 19:28:52 werewolf kernel: eax: d5d53bbc ebx: d5d53c70 ecx: e2f9e180 edx: Sep 28 19:28:52 werewolf kernel: esi: edi: d5d53c74 ebp: d5d53c78 esp: d5d53bb0 Sep 28 19:28:52 werewolf kernel: ds: 007b es: 007b ss: 0068 Sep 28 19:28:52 werewolf kernel: Process pure-ftpd-mysql (pid: 7092, threadinfo=d5d52000 task=eb970a80) Sep 28 19:28:52 werewolf kernel: Stack: e2f9e180 d5d53bbc d5d53bf4 d5d53c74 d5d53bf4 d5d53c74 d5d53bf4 Sep 28 19:28:52 werewolf kernel:d5d53c20 c01b00ea d5d53c74 d5d53bf4 d5d53d28 d5d53c88 0002 Sep 28 19:28:52 werewolf kernel:0001 e9c89dc8 e9c89e48 e9a0543c e9a054a4 e9a05400 0003 Sep 28 19:28:52 werewolf kernel: Call Trace: Sep 28 19:28:52 werewolf kernel: [carry+147/445] carry+0x93/0x1bd Sep 28 19:28:52 werewolf kernel: [insert_with_carry_by_coord+184/242] insert_with_carry_by_coord+0xb8/0xf2 Sep 28 19:28:52 werewolf kernel: [insert_by_coord+173/287] insert_by_coord+0xad/0x11f Sep 28 19:28:52 werewolf kernel: [insert_new_sd+260/563] insert_new_sd+0x104/0x233 Sep 28 19:28:52 werewolf kernel: [write_sd_by_inode_common+41/182] write_sd_by_inode_common+0x29/0xb6 Sep 28 19:28:52 werewolf kernel: [create_common+36/63] create_common+0x24/0x3f Sep 28 19:28:52 werewolf kernel: [create_child_common+679/1763] create_child_common+0x2a7/0x6e3 Sep 28 19:28:52 werewolf kernel: [invoke_create_method+152/248] invoke_create_method+0x98/0xf8 Sep 28 19:28:52 werewolf kernel: [reiser4_create+72/78] reiser4_create+0x48/0x4e Sep 28 19:28:52 werewolf kernel: [vfs_create+189/233] vfs_create+0xbd/0xe9 Sep 28 19:28:52 werewolf kernel: [open_namei+1310/1476] open_namei+0x51e/0x5c4 Sep 28 19:28:52 werewolf kernel: [filp_open+59/97] filp_open+0x3b/0x61 Sep 28 19:28:52 werewolf kernel: [get_unused_fd+78/174] get_unused_fd+0x4e/0xae Sep 28 19:28:52 werewolf kernel: [sys_open+64/110] sys_open+0x40/0x6e Sep 28 19:28:52 werewolf kernel: [syscall_call+7/11] syscall_call+0x7/0xb Sep 28 19:28:52 werewolf kernel: Code: 39 e8 74 30 89 cb 89 14 24 e8 6e 03 00 00 89 c1 66 83 b8 d2 00 00 00 00 75 db 8b 90 80 00 00 00 8d 44 24 0c 89 44 24 04 89 0c 24 ff 52 78 89 c6 85 c0 74 c1 89 f0 83 c4 14 5b 5e 5f 5d c3 55 57 i have crash every 1 hour, and i already lost some databases and other random files can you please help me? is there any undelete tool for reiser4 ? (dont think its possible, but i will ask anyways) Hello, my server crashed few times latetly, and the only strange thing i found in logs, are reiser4 entries just before every crash: #1 crash: kern.log:Sep 27 21:09:06 werewolf kernel: reiser4[pure-ftpd-mysql(18871)]: parse_node40 (fs/reiser4/plugin/node/node40.c:746)[nikita-494]: kern.log:Sep 27 21:09:06 werewolf kernel: reiser4[pure-ftpd-mysql(18871)]: extent2tail (fs/reiser4/plugin/file/tail_conversion.c:666)[nikita-2282]: kern.log:Sep 27 21:09:06 werewolf kernel: reiser4[pure-ftpd-mysql(18871)]: release_unix_file (fs/reiser4/plugin/file/file.c:2297)[nikita-3233]: kern.log:Sep 27 21:09:08 werewolf kernel: reiser4[pure-ftpd-mysql(15867)]: parse_node40 (fs/reiser4/plugin/node/node40.c:746)[nikita-494]: kern.log:Sep 27 21:09:08 werewolf kernel: reiser4[pure-ftpd-mysql(15867)]: cut_tree_object (fs/reiser4/tree.c:1723)[nikita-2861]: kern.log:Sep 27 21:09:08 werewolf kernel: reiser4[pure-ftpd-mysql(18812)]: parse_node40 (fs/reiser4/plugin/node/node40.c:746)[nikita-494]: kern.log:Sep 27 21:09:08 werewolf kernel: reiser4[pure-ftpd-mysql(18812)]: extent2tail (fs/reiser4/plugin/file/tail_conversion.c:666)[nikita-2282]: kern.log:Sep 27 21:09:08 werewolf kernel: reiser4[pure-ftpd-mysql(18812)]: release_unix_file (fs/reiser4/plugin/file/file.c:2297)[nikita-3233]: kern.log:Sep 27 21:09:08 werewolf kernel: reiser4[pure-ftpd-mysql(18883)]: parse_node40 (fs/reiser4/plugin/node/node40.c:746)[nikita-494]: kern.log:Sep 27 21:09:08
