Re: Reiser4 Install Guide for Ubuntu 5.10
Am Dienstag, 22. November 2005 01:52 schrieb Ryan Nordman: Hi Hans, Allow me to introduce myself, I'm one of Peter (aka pvh)'s colleagues here at the University of Victoria. A while back we mentioned we'd write a practical install guide for Reiser4 with Ubuntu 5.10. Well, here it is. Let us know if you want us to make any changes to the format or add/remove any steps. [...] 8. Reboot with the new kernel, create a Reiser partition and mount it and you're good to go! Did you also try to make / with reiser4? -- Üdvözlettel -- Mit freundlichen Grüssen, Marcel Hilzinger
Re: More Slowdown
Am Donnerstag, 17. November 2005 14:47 schrieb Hesse, Christian: Vladimir V. Saveliev wrote: Please try whether the attached patch improves anything. It simplifies fsync by avoid commiting of transactions which do not modify file being fsync-ed. Did you ever think about, that this is not a reiser4 problem, but a kernel bug or a problem related to hal? Suse 10 has big problems with external USB drives using sync as mount option. They used sync already in 9.3 but with 2.6.11 there were no such problems. There has been some changes in kernel 2.6.13 and 2.6.14 concering the sync behavior, perhaps it can help investigating there first, bevor fixing reiser4 for nothing... -- Üdvözlettel -- Mit freundlichen Grüssen, Marcel Hilzinger
Re: More Slowdown
Marcel Hilzinger wrote (ao): Did you ever think about, that this is not a reiser4 problem, but a kernel bug or a problem related to hal? Suse 10 has big problems with external USB drives using sync as mount option. They used sync already in 9.3 but with 2.6.11 there were no such problems. There has been some changes in kernel 2.6.13 and 2.6.14 concering the sync behavior, perhaps it can help investigating there first, bevor fixing reiser4 for nothing... Running Debian here, and all the reports have been on Reiser4 filesystems. Also, the same system has no such problems with other filesystems. -- Humilis IT Services and Solutions http://www.humilis.net
Re: More Slowdown
Am Dienstag, 22. November 2005 11:38 schrieb Sander: Marcel Hilzinger wrote (ao): Did you ever think about, that this is not a reiser4 problem, but a kernel bug or a problem related to hal? Suse 10 has big problems with external USB drives using sync as mount option. They used sync already in 9.3 but with 2.6.11 there were no such problems. There has been some changes in kernel 2.6.13 and 2.6.14 concering the sync behavior, perhaps it can help investigating there first, bevor fixing reiser4 for nothing... Running Debian here, and all the reports have been on Reiser4 filesystems. Also, the same system has no such problems with other filesystems. It's not about Debian or Suse. It's about kernel 2.6.13 or 2.6.14. At least it seems, that the problem does not appear on older kernels (right?) -- Üdvözlettel -- Mit freundlichen Grüssen, Marcel Hilzinger
Re: More Slowdown
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 ? -- Ingo Bormuth, voicebox telefax: +49-12125-10226517 public key 86326EC9, http://ibormuth.efil.de/contact
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
Marcel Hilzinger wrote: Am Dienstag, 22. November 2005 11:38 schrieb Sander: Marcel Hilzinger wrote (ao): Did you ever think about, that this is not a reiser4 problem, but a kernel bug or a problem related to hal? Suse 10 has big problems with external USB drives using sync as mount option. They used sync already in 9.3 but with 2.6.11 there were no such problems. There has been some changes in kernel 2.6.13 and 2.6.14 concering the sync behavior, perhaps it can help investigating there first, bevor fixing reiser4 for nothing... Running Debian here, and all the reports have been on Reiser4 filesystems. Also, the same system has no such problems with other filesystems. It's not about Debian or Suse. It's about kernel 2.6.13 or 2.6.14. At least it seems, that the problem does not appear on older kernels (right?) Wrong. You are talking about the fsync issue, right? As far as I know, while there has been progress lately, fsync has always been slow on Reiser4, because until recently, it was basically a call to sync, and reiser4 syncs can be huge due to lazy writes -- stuff only ever hits disk when there's nowhere else to put it in RAM. Actual calls to sync are rare enough (shutdown/reboot) that lazy writes are a good thing, but fsync apparently needs to be faster. I disabled fsync before the FS was even stable, because I was sick of waiting 30 seconds or so for vim to save and quit. It may help to have fsync only sync the file in question (as it always has, except on Reiser4). This has been done with lazy writes, in XFS, so I see no reason it can't be done here -- there might have even been a patch recently. Personally, I'd like to see it stay as slow as it is for awhile, so we can find the people doing stupid things (evolution) and flame them into crispy obediance. fsync means flush to disk. This is something you're supposed to do with a file when the file is so important you want to guarentee you'll have the most recent, uncorrupted version after a crash. If evolution is calling fsync while resizing, this is an evolution bug, made more obvious by reiser4 -- if a computer crashes, does the user really care if their Evolution columns are still lined up _exactly_ the way they were (maybe mid-click'n'drag) when the crash occurred? If there is a user who cares that much about column widths, can we flame them to crispiness also?
Re: More Slowdown
Am Dienstag, 22. November 2005 15:29 schrieb David Masover: Marcel Hilzinger wrote: [...] It's not about Debian or Suse. It's about kernel 2.6.13 or 2.6.14. At least it seems, that the problem does not appear on older kernels (right?) Wrong. You are talking about the fsync issue, right? As far as I know, while there has been progress lately, fsync has always been slow on Reiser4, because until recently, it was basically a call to sync, and reiser4 syncs can be huge due to lazy writes -- stuff only ever hits disk when there's nowhere else to put it in RAM. Actual calls to sync are rare enough (shutdown/reboot) that lazy writes are a good thing, but fsync apparently needs to be faster. I disabled fsync before the FS was even stable, because I was sick of waiting 30 seconds or so for vim to save and quit. It may help to have fsync only sync the file in question (as it always has, except on Reiser4). This has been done with lazy writes, in XFS, so I see no reason it can't be done here -- there might have even been a patch recently. Personally, I'd like to see it stay as slow as it is for awhile, so we can find the people doing stupid things (evolution) and flame them into crispy obediance. fsync means flush to disk. This is something you're supposed to do with a file when the file is so important you want to guarentee you'll have the most recent, uncorrupted version after a crash. If evolution is calling fsync while resizing, this is an evolution bug, made more obvious by reiser4 -- if a computer crashes, does the user really care if their Evolution columns are still lined up _exactly_ the way they were (maybe mid-click'n'drag) when the crash occurred? Thanks a lot. I understand now. But is there any bug to hunt within reiser4 then? -- Üdvözlettel -- Mit freundlichen Grüssen, Marcel Hilzinger
Re: More Slowdown
Marcel Hilzinger wrote (ao): Am Dienstag, 22. November 2005 11:38 schrieb Sander: Marcel Hilzinger wrote (ao): Did you ever think about, that this is not a reiser4 problem, but a kernel bug or a problem related to hal? Suse 10 has big problems with external USB drives using sync as mount option. They used sync already in 9.3 but with 2.6.11 there were no such problems. There has been some changes in kernel 2.6.13 and 2.6.14 concering the sync behavior, perhaps it can help investigating there first, bevor fixing reiser4 for nothing... Running Debian here, and all the reports have been on Reiser4 filesystems. Also, the same system has no such problems with other filesystems. It's not about Debian or Suse. It's about kernel 2.6.13 or 2.6.14. At least it seems, that the problem does not appear on older kernels (right?) That is correct, but in your previous mail you suggested this might not be a Reiser4 problem, and that is incorrect :-) -- Humilis IT Services and Solutions http://www.humilis.net
Re: More Slowdown or reiser4 update for 2.6.14-mm2
Sander wrote: E.Gryaznova wrote (ao): Unfortunately we are not able to reproduce this slowdown. Would you please provide more info?: FWIW, I notice the same (I'm not the OP). My main workstation (Athlon) runs 2.6.15-rc1-mm1. Vim needs 4 to 12 seconds to close any file, mutt is very slow on sending email, backups take several hours and in general anything done on the filesystem seems slow. This system has one IDE disk. Scrips are locked when vim closes and bash/perl complain when they try to read/execute the script. The strange thing is that another system running 2.6.15-rc1-mm2 does not have this slowdown. There are no Reiser4 updates in -mm2 AFAICS. This system is a Via Epia with Reiser4 on lvm2 on 4xSATA. Is this 2.6.14-mm2 bad sync/fsync performance reproducible on fresh created reiser4 too? I'll try. Are these values stable reproducible? If you run this test several time -- do you have the same results? Vim is always very slow on close (:wq) for me. Would you please send df -T output # df -T / FilesystemType 1K-blocks Used Available Use% Mounted on /dev/hda2 reiser4 232423180 166976448 65446732 72% / and 2.6.14-mm2 config file? 2.5.16-rc1-mm1 below. 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? If I open and edit a file on /boot, which is ext2 on hda1, vim reacts as expected. Quick and without a single delay. # echo foo /boot/test # time vim +s/foo/bar/ +wq /boot/test real0m0.016s user0m0.000s sys 0m0.000s # echo foo /root/test # time vim +s/foo/bar/ +wq /root/test real0m9.667s user0m0.000s sys 0m0.020s /dev/hda2 on / type reiser4 (rw) /dev/hda1 on /boot type ext2 (rw) Anything I can do to help? Yes, thank you. Which iosched do you use? Would you please repeat the vim/reiser4 test for each iosched and send us the time values? Something like for i in cfq noop anticipatory deadline do echo $i /sys/block/hda/queue/scheduler cat /sys/block/hda/queue/scheduler echo foo /root/test time vim +s/ foo/bar/ +wq /root/test done Thanks, Lena # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set CONFIG_DEFAULT_DEADLINE=y # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=deadline
Help tracking down files on a bad block: understanding the output of debugreiserfs
Hello all,
I've recently received a bad block notice from SMARTD and I'm trying to
track down which files might be affected. I *think* I have the basic
process correct but I'm missing the final step -- how to get the inode
of the affected files. My skill with Google and man pages got me to
where I am but seems unequal to my remaining task.
My question is: is the inode of the file in question found in the
output of debugreiserfs -1 blocknum or is there some other way to get
the inode?
Attached is a console log documenting the process I'm using so far. How
should I interpret this output from debugreiserfs?
Many thanks,
--
Dewey Sasser
straits messages # grep LBAsect messages.1 | tail -n 1
Nov 9 09:45:34 straits hda: dma_intr: error=0x40 {
UncorrectableError }, LBAsect=32378944, sector=28250176
straits messages # fdisk -ul /dev/hda
Disk /dev/hda: 122.9 GB, 122942324736 bytes
255 heads, 63 sectors/track, 14946 cylinders, total 240121728 sectors
Units = sectors of 1 * 512 = 512 bytes
Device Boot Start End Blocks Id System
/dev/hda1 * 63 128519 64228+ 83 Linux
/dev/hda2 128520 4128704 292+ 83 Linux
/dev/hda3 4128705 240107489 117989392+ 5 Extended
/dev/hda5 41287684319878419535008+ 83 Linux
/dev/hda643198848 24010748998454321 83 Linux
straits messages # dc
32378944 /# LBA Sector/
4128768 /# Starting sector for hda5/
-
p
28250176 /# result: this is the sector within hda5/
8 /# convert 512 byte sectors to 4096 byte
ReiserFS blocks
/
/p
3531272 # /result: this is the ReiserFS block containing the
bad sector/
q
straits messages # debugreiserfs -1 3531272 /dev/hda5
debugreiserfs 3.6.19 (2003 www.namesys.com)
3531272 is used in ondisk bitmap
===
LEAF NODE (3531272) contains level=1, nr_items=12, free_space=632
rdkey (real items 12)
---
|###|type|ilen|f/sp| loc|fmt|fsck|
key |
| |||e/cn||
|need||
---
| 0|3065513 2078685 0x0 SD (0), len 44, location 4052 entry count
65535, fsck need 0, format new|
(NEW SD), mode -rw-rw-r--, size 0, nlink 1, mtime 24/2005 04:17:29
blocks 0, uid 0
---
| 1|3065513 2078685 0x1 DRCT (2), len 456, location 3596 entry
count 65535, fsck need 0, format new|
---
| 2|3065513 2269255 0x0 SD (0), len 44, location 3552 entry count
65535, fsck need 0, format new|
(NEW SD), mode -rw-rw-r--, size 610, nlink 1, mtime 02/2005 04:05:49
blocks 8, uid 0
---
| 3|3065513 2269255 0x1 DRCT (2), len 616, location 2936 entry
count 65535, fsck need 0, format new|
---
| 4|3065513 2269421 0x0 SD (0), len 44, location 2892 entry count
65535, fsck need 0, format new|
(NEW SD), mode -rw-rw-r--, size 505, nlink 1, mtime 01/2005 14:35:40
blocks 8, uid 0
---
| 5|3065513 2269421 0x1 DRCT (2), len 512, location 2380 entry
count 65535, fsck need 0, format new|
---
| 6|3065513 2269440 0x0 SD (0), len 44, location 2336 entry count
65535, fsck need 0, format new|
(NEW SD), mode -rw-rw-r--, size 371, nlink 1, mtime 21/2005 14:35:50
blocks 8, uid 0
---
| 7|3065513 2269440 0x1 DRCT (2), len 376, location 1960 entry
count 65535, fsck need 0, format new|
---
| 8|3065513 2269513 0x0 SD (0), len 44, location 1916 entry count
65535, fsck need 0, format new|
(NEW SD), mode -rw-rw-r--, size 873, nlink 1, mtime 17/2005 16:06:08
blocks 8, uid 0
---
| 9|3065513 2269513 0x1 DRCT (2), len 880, location 1036 entry
count 65535, fsck need 0, format new|
---
| 10|3065513 2288540 0x0 SD (0), len 44, location 992 entry count
65535, fsck need 0, format new|
(NEW SD), mode -rw-rw-r--, size 643, nlink 1, mtime 09/2005 15:35:43
blocks 8, uid 0
Re: Help tracking down files on a bad block: understanding the output of debugreiserfs
Hi!
Unfortunately I can't help you with the debugreiserfs output but maybe
with another approach for finding the correct blocknum of the bad
sector(s). Why don't you try
badblocks -b 4096 /dev/hda5
I'm not telling that your approach is wrong but this way (assuming your
reiserfs block is the default 4k) you'll be sure to have all bad blocks.
But it takes some time. On the other hand you may try this:
dd of=/dev/null if=/dev/hda5 bs=4k count=1 skip=xxx
with xxx the block number(s) of your calculation or output from
badblocks. Just to check if the block you've found is really unreadable.
How to identify the inode number corresponding to that block I can't
tell but finding the file etc. to the inode may be done with
find /mount-point-of-fs -inum xxx
where xxx is the inode number in question. See man find.
Hope that helps.
Konstantin
Dewey Sasser wrote:
Hello all,
I've recently received a bad block notice from SMARTD and I'm trying to
track down which files might be affected. I *think* I have the basic
process correct but I'm missing the final step -- how to get the inode
of the affected files. My skill with Google and man pages got me to
where I am but seems unequal to my remaining task.
My question is: is the inode of the file in question found in the
output of debugreiserfs -1 blocknum or is there some other way to get
the inode?
Attached is a console log documenting the process I'm using so far. How
should I interpret this output from debugreiserfs?
Many thanks,
--
Dewey Sasser
straits messages # grep LBAsect messages.1 | tail -n 1
Nov 9 09:45:34 straits hda: dma_intr: error=0x40 {
UncorrectableError }, LBAsect=32378944, sector=28250176
straits messages # fdisk -ul /dev/hda
Disk /dev/hda: 122.9 GB, 122942324736 bytes
255 heads, 63 sectors/track, 14946 cylinders, total 240121728 sectors
Units = sectors of 1 * 512 = 512 bytes
Device Boot Start End Blocks Id System
/dev/hda1 * 63 128519 64228+ 83 Linux
/dev/hda2 128520 4128704 292+ 83 Linux
/dev/hda3 4128705 240107489 117989392+ 5 Extended
/dev/hda5 41287684319878419535008+ 83 Linux
/dev/hda643198848 24010748998454321 83 Linux
straits messages # dc
32378944 /# LBA Sector/
4128768 /# Starting sector for hda5/
-
p
28250176 /# result: this is the sector within hda5/
8 /# convert 512 byte sectors to 4096 byte
ReiserFS blocks
/
/p
3531272 # /result: this is the ReiserFS block containing the
bad sector/
q
straits messages # debugreiserfs -1 3531272 /dev/hda5
debugreiserfs 3.6.19 (2003 www.namesys.com)
3531272 is used in ondisk bitmap
===
LEAF NODE (3531272) contains level=1, nr_items=12, free_space=632
rdkey (real items 12)
---
|###|type|ilen|f/sp| loc|fmt|fsck|
key |
| |||e/cn||
|need||
---
| 0|3065513 2078685 0x0 SD (0), len 44, location 4052 entry count
65535, fsck need 0, format new|
(NEW SD), mode -rw-rw-r--, size 0, nlink 1, mtime 24/2005 04:17:29
blocks 0, uid 0
---
| 1|3065513 2078685 0x1 DRCT (2), len 456, location 3596 entry
count 65535, fsck need 0, format new|
---
| 2|3065513 2269255 0x0 SD (0), len 44, location 3552 entry count
65535, fsck need 0, format new|
(NEW SD), mode -rw-rw-r--, size 610, nlink 1, mtime 02/2005 04:05:49
blocks 8, uid 0
---
| 3|3065513 2269255 0x1 DRCT (2), len 616, location 2936 entry
count 65535, fsck need 0, format new|
---
| 4|3065513 2269421 0x0 SD (0), len 44, location 2892 entry count
65535, fsck need 0, format new|
(NEW SD), mode -rw-rw-r--, size 505, nlink 1, mtime 01/2005 14:35:40
blocks 8, uid 0
---
| 5|3065513 2269421 0x1 DRCT (2), len 512, location 2380 entry
count 65535, fsck need 0, format new|
---
| 6|3065513 2269440 0x0 SD (0), len 44, location 2336 entry count
65535, fsck need 0, format new|
(NEW SD), mode -rw-rw-r--, size 371, nlink 1, mtime 21/2005 14:35:50
Re: More Slowdown
Marcel Hilzinger wrote: Am Dienstag, 22. November 2005 15:29 schrieb David Masover: Marcel Hilzinger wrote: [...] It's not about Debian or Suse. It's about kernel 2.6.13 or 2.6.14. At least it seems, that the problem does not appear on older kernels (right?) Wrong. You are talking about the fsync issue, right? As far as I know, while there has been progress lately, fsync has always been slow on Reiser4, because until recently, it was basically a call to sync, and reiser4 Thanks a lot. I understand now. But is there any bug to hunt within reiser4 then? You could call it that. Last I checked, Reiser4's fsync just called 'sync'. The way it should work is to only flush the file being fsynced, not the whole FS. If this were fixed, Reiser4 fsync performance should approach that of, say, XFS, which also has lazy writes. But, I haven't been keeping up with this discussion, so maybe someone did fix that, and it's still slow. But, even if fsync is as fast as it can possibly be, Evolution should also be fixed.
Re: More Slowdown or reiser4 update for 2.6.14-mm2
On 11/22/05, E.Gryaznova [EMAIL PROTECTED] wrote: Sander wrote: E.Gryaznova wrote (ao): Something like for i in cfq noop anticipatory deadline do echo $i /sys/block/hda/queue/scheduler cat /sys/block/hda/queue/scheduler echo foo /root/test time vim +s/ foo/bar/ +wq /root/test done Done, I had to output to vim's output to /dev/null due to it clearing the term. for i in cfq noop anticipatory deadline do echo $i /sys/block/hda/queue/scheduler cat /sys/block/hda/queue/scheduler echo foo /root/test; time vim +s/foo/bar/ +wq /root/test/dev/null done Results: noop anticipatory deadline [cfq] Vim: Warning: Output is not to a terminal real0m2.464s user0m0.046s sys 0m0.022s [noop] anticipatory deadline cfq Vim: Warning: Output is not to a terminal real0m2.188s user0m0.045s sys 0m0.018s noop [anticipatory] deadline cfq Vim: Warning: Output is not to a terminal real0m2.213s user0m0.044s sys 0m0.021s noop anticipatory [deadline] cfq Vim: Warning: Output is not to a terminal real0m2.422s user0m0.046s sys 0m0.018s Linux rocket 2.6.15-rc1-mm2 #6 SMP PREEMPT Tue Nov 22 11:02:59 PST 2005 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ AuthenticAMD GNU/Linux -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
Re: need opinions from sysadmins on where reiser4progs should install
michael chang wrote: On 11/21/05, Hans Reiser [EMAIL PROTECTED] wrote: Vitaly Fertman wrote: On Monday 21 November 2005 10:09, Hans Reiser wrote: Philippe GramoullИ wrote: Hello, On Sun, 20 Nov 2005 05:07:23 +0100 rvalles [EMAIL PROTECTED] wrote: | When I run make install on something and haven't specified a prefix on | configure, I expect /usr/local to be used. If I wanted /, I'd have | specified that on configure time. If it installed in / by default, it | would, often, hit the sacred package-system managed area of the VFS | tree annoying people like me to a very great extend, so please don't. While i totally agree with you for standard packages, well i based my choice on actual experience of the last past six years of use with reiserfs V3. I can't remember how many times i heard Namesys team say Install the latest greatest reiserfsck, how many times distro thought they knew reiserfsprogs internals better than Namesys and customized it to the point where it would eventually break. Of course, i can live with a manual install of reiser(fs|4)progs, so i don't really mind, but talking of support, it can make quite a difference to Namesys in terms of support, and annoyance with bug reports that could have been easily avoided. Ok, I propose the following: search the standard locations for where it is currently, tell the user, ask the user if they want to rename those the proper service is already done in package managers. if one needs it, he can use one of them. versions to *.old if the install of the new one succeeds, and then this breaks the installed software consistency and may screw the package manager up... Sigh, good point, ok, well then at least warn the user about them. prompt for the install location with /sbin as the suggested default. I think that unlike other user installed programs, fsck does not belong in /usr/local. I think Philippe's point that old versions are dangerous is quite valid. install to the system default through a system package manager; install to the local default from source to not break the system installed software consistency; So the reason for not installing to /sbin is to avoid messing up the package manager? I regret to say it makes sense. If that is the reason, then warn the user please about old versions left intact, and suggest they be removed, and prompt the user for the path to install to and remind them to update their $PATH. The problem is that some package managers might make reiser4progs a base package, which removing will emit a loud warning that it might break your system. That said, anyone installing a custom reiser4progs may or may not be supposed to have the knowledge to work around it. Replace reiser4progs with e2fsprogs and see if it still makes sense. On my Gentoo system, e2fsprogs is depended on by util-linux, but reiser4progs isn't depended on by anything, despite the fact that my root fs is reiser4. I actually need both -- my /boot is ext3 and my initrd is ext2. I see little reason for any of this to change, except maybe to be more consistent -- either require all FS tools, or force the user to install the package they need. Which wouldn't be so bad -- after all, Gentoo already makes me install the system logger manually, because there are three possible sysloggers available, so I get a choice at install time. It might be easier to make a pseudo-package representing the program Portage has had this for awhile. I just add the package name to /etc/portage/profile/package.provided and Portage will never install that package as a dependency. This used to be called injecting, which actually inserted an empty package, but now exists in that config file. or to actually put package building scripts for package-handling distros in the source package (or use something like checkinstall, provided it doesn't conflict too bad). [You can also did what Debian did with it's 'kernel-package' system; it provides a package specially designed for converting a custom kernel into a package, I think that's overkill, unless Debian really has no way to provide or inject a particular package. Someone who knows how to use kernel-package can probably also handle package.provide. The main thing that's nice about kernel-package isn't the dependency-handling, it's the way it simplifies the process of installing and managing multiple custom kernels. For one thing, Debian manages bootloader config files, generating menu entries and such, and installing an actual kernel package (custom or otherwise) automatically copies the kernel image to /boot and updates grub.conf (or whatever) with an entry named for that kernel version. I don't see anything that makes a packaged reiser4progs better than an unpackaged one, except for the two things you're defeating with any custom version: dependencies and automatic updates.
Re: need opinions from sysadmins on where reiser4progs should install
On Tue, 22 Nov 2005 13:33:44 -0600, David Masover [EMAIL PROTECTED] said: michael chang wrote: or to actually put package building scripts for package-handling distros in the source package (or use something like checkinstall, provided it doesn't conflict too bad). [You can also did what Debian did with it's 'kernel-package' system; it provides a package specially designed for converting a custom kernel into a package, I think that's overkill, unless Debian really has no way to provide or inject a particular package. Debian has a package called equivs that allows you to create dummy packages. But it is generally better to just include a debian/ directory in the sources, and let the Debian package management just handle everything for you (e.g. upgrading to a new version when Debian includes a newer version). Debian generally frowns upon including a debian/ directory in the upstream sources without any good reason. But I think that in this case, there is a good reason. Just make sure to work with the Debian maintainer of reiser4progs (Ed Boraas) if you want to do that. -- Hubert Chan [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA Key available at wwwkeys.pgp.net. Encrypted e-mail preferred.
Re: Help tracking down files on a bad block: understanding the output of debugreiserfs
Konstantin Münning wrote: Hi! Unfortunately I can't help you with the debugreiserfs output but maybe with another approach for finding the correct blocknum of the bad sector(s). Why don't you try badblocks -b 4096 /dev/hda5 Interesting. When reading the badblocks man page I originally interpreted something it said to mean that it wouldn't run against a mounted partition. I see now that that is not the case. It will only refuse to run doing tests which write the partition, which is as it should be. The partition affected is the root partition of a machine 700 miles from my chair and there is no one near the box that had any kind of Linux knowledge. I am therefore trying to do this as much on-line as possible. I will run badblocks at some point but I'll still need a way of mapping the bad block or sector to the affected files. (Yes, I do have backups :) dd of=/dev/null if=/dev/hda5 bs=4k count=1 skip=xxx with xxx the block number(s) of your calculation or output from badblocks. Just to check if the block you've found is really unreadable. That is indeed one of my additional questions -- does the fact that debugreiserfs prints data mean the block (sector, really) is readable? Or does it mean my math is incorrect. badblocks should help me answer that question. How to identify the inode number corresponding to that block I can't tell but finding the file etc. to the inode may be done with find /mount-point-of-fs -inum xxx Yep. That part I can handle. It's that middle link I'm missing :) Thanks for your response, -- Dewey
Re: More Slowdown
Evolution may need tweaking also, but reiser4's fsync clearly needs work.
Re: Reiser4 Install Guide for Ubuntu 5.10
On 11/22/05, Jake Maciejewski [EMAIL PROTECTED] wrote: On Mon, 2005-11-21 at 16:52 -0800, Ryan Nordman wrote: Hi Hans, Allow me to introduce myself, I'm one of Peter (aka pvh)'s colleagues here at the University of Victoria. A while back we mentioned we'd write a practical install guide for Reiser4 with Ubuntu 5.10. Well, here it is. Let us know if you want us to make any changes to the format or add/remove any steps. All version references in this document are up to date for Ubuntu 5.10 (Breezy Badger). Prerequisites: Add the universe repository to your sources 1. Install all the software needed to compile the kernel # apt-get build-dep linux-source-2.6.12 # apt-get install linux-source-2.6.12 checkinstall libncurses-dev 2. Use the following commands to download the latest Reiser4 kernel patch, the Reiser4 utility programs, and required libraries. # wget ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.12/reiser4-for-2.6.12-3.patch.gz # wget ftp://ftp.namesys.com/pub/reiser4progs/reiser4progs-1.0.5.tar.gz # wget ftp://ftp.namesys.com/pub/reiser4progs/libaal-1.0.5.tar.gz 3. Install libaal # tar zxf libaal-1.0.5.tar.gz # cd libaal-1.0.5 # ./configure; make # checkinstall At the prompt: Should I create a default set of package docs? [y]: type y and press enter. You will then be prompted to input a description of the package. Enter something like locally built libaal then press enter three times. # cd .. 4. Install reiser4progs # tar zxf reiser4progs-1.0.5.tar.gz # cd reiser4progs-1.0.5 # ./configure; make # checkinstall At the prompt: Should I create a default set of package docs? [y]: type y and press enter. At the prompt: Do you want me to list them? [n]: type n and press enter. At the prompt: Should I exclude them from the package? (Saying yes is a good idea) [y]: type y and press enter. You will then be prompted to input a description of the package. Type something like locally built libaal then press enter three times. 5. Unzip and add the reiser4 code to the linux source # cd /usr/src # tar xvf linux-source-2.6.12.tar.bz2 # cd linux-source-2.6.12/ # gunzip -c ~/reiser4-for-2.6.12-3.patch.gz | patch -p1 6. Compile the kernel # make menuconfig Select File systems --- from the menu and press enter. Select Reiser4 (EXPERIMENTAL) (NEW) and type M. Press the esc key twice. Select yes at the prompt. Must the rest of the kernel options be configured here as well, or does apt-get install the sources with a .config? Most users who know how to configure a kernel will probably know the other steps. If the kernel has to be configured, is the default Ubuntu .config easily available? Also, the kernel that Ubuntu ships with is now patched with usplash, and the initrd is dynamically-configured when linux-kernel-2.6.12-2-i386 or similar is configured if the usplash-artwork (or ?ubuntu-artwork package, where ? is either k or x) package is installed (provided on base install with 5.10 and newer). And then the initrd itself is another issue in and of itself -- IIRC, a large majority of Ubuntu components are built modules, IIRC, even fs support for most root fses... -- ~Mike - Just my two cents - No man is an island, and no man is unable.
Re: More Slowdown - testscript
Hi, The slow sync problems still exist with fresh vanilla kernel patched with Reiser4 only (reiser4-for-2.6.14-1.patch). The slow sync occurs regardless of which IO scheduler is in use. [EMAIL PROTECTED]:~$ uname -a Linux teratron.lan.etheus.net 2.6.14.2 #2 PREEMPT Tue Nov 22 23:48:39 GMT 2005 i686 GNU/Linux See the attached testscript.sh These are the results from the script: sync a1 real0m1.301s user0m0.000s sys 0m0.000s sync a2 real0m0.341s user0m0.004s sys 0m0.000s sync a3 real0m0.341s user0m0.004s sys 0m0.004s sync a4 real0m0.307s user0m0.000s sys 0m0.000s Performing recursive ls real0m0.307s user0m0.080s sys 0m0.220s sync b1 real0m9.716s user0m0.000s sys 0m0.024s sync b2 real0m0.391s user0m0.004s sys 0m0.000s sync b3 real0m0.316s user0m0.000s sys 0m0.000s sync b4 real0m0.341s user0m0.000s sys 0m0.000s Performing recursive ls real0m0.734s user0m0.216s sys 0m0.516s sync c1 real0m53.698s user0m0.000s sys 0m0.108s sync c2 real0m0.665s user0m0.000s sys 0m0.004s sync c3 real0m0.125s user0m0.000s sys 0m0.008s sync c4 real0m0.125s user0m0.000s sys 0m0.000s Sync a1-a4 execute relatively quickly The recursive ls happen very quickly because the data is already cached. Syncs immediately after the recursive ls take ages. This is really strange since the recursive ls does not touch the disk because the data is cached. My guess is that when sync is called, the cache of ALL recently accessed data is either being committed back to disk, or being re-read. -- Craig Shelley EMail: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] testscript.sh Description: application/shellscript signature.asc Description: This is a digitally signed message part
Re: More Slowdown - testscript [Part 2]
Here are the results after testing on 2.6.12.1 which is not affected by the sync problem. Notice how sync b1 and c1 are now hardly affected by the recursive ls. sync a1 real0m0.072s user0m0.001s sys 0m0.002s sync a2 real0m0.012s user0m0.000s sys 0m0.001s sync a3 real0m0.012s user0m0.001s sys 0m0.001s sync a4 real0m0.011s user0m0.002s sys 0m0.000s Performing recursive ls real0m0.307s user0m0.090s sys 0m0.210s sync b1 real0m0.013s user0m0.000s sys 0m0.003s sync b2 real0m0.011s user0m0.001s sys 0m0.000s sync b3 real0m0.011s user0m0.000s sys 0m0.002s sync b4 real0m0.011s user0m0.000s sys 0m0.002s Performing recursive ls real0m0.704s user0m0.209s sys 0m0.480s sync c1 real0m0.018s user0m0.000s sys 0m0.006s sync c2 real0m0.011s user0m0.000s sys 0m0.002s sync c3 real0m0.011s user0m0.001s sys 0m0.001s sync c4 real0m0.011s user0m0.000s sys 0m0.001s -- Craig Shelley EMail: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Rodney Very Good News
VVPAXCL IArmaIe ALobnAv GIziaLi RUaexIt AMcnSra 3,351,203,70http://www.carbinelw.hejoinehe.com
Collect data? (was: Re: More Slowdown or reiser4 update for 2.6.14-mm2)
E.Gryaznova wrote (ao): Sander wrote: # echo foo /boot/test # time vim +s/foo/bar/ +wq /boot/test real0m0.016s user0m0.000s sys 0m0.000s # echo foo /root/test # time vim +s/foo/bar/ +wq /root/test real0m9.667s user0m0.000s sys 0m0.020s /dev/hda2 on / type reiser4 (rw) /dev/hda1 on /boot type ext2 (rw) Yes, thank you. Which iosched do you use? 'deadline': $ cat /sys/block/hda/queue/scheduler noop anticipatory [deadline] cfq Would you please repeat the vim/reiser4 test for each iosched and send us the time values? As others already reacted with data regarding this test I assume you don't need my data anymore. I understand this problem must be quite annoying for the Reiserfs team as you can't reproduce it. In my case it also only happens on one system, and not on another. Maybe we can collect data? I'm happy to set up a page with 'good' and 'bad' configurations. Any suggestions as to what you need? My 'good' system: kernel: 2.6.15-rc1-mm2 OS: Debian Sid disks: 4x sata on Promise raid/lvm/etc: lmv stripe My 'bad' system: kernel: 2.6.15-rc1-mm1 OS: Debian Sid disks: ata on nForce2 raid/lvm/etc: none, single disk -- Humilis IT Services and Solutions http://www.humilis.net
