Re: reiser4: data recovery after mkfs.reiser4?
Hi, I already answered Vladimir's posting twice - one thanks, I'll try that and one success report. It just so happens that a LOT of mails I send to the list never gets through, no idea why. Could someone resend that info to the list? I'm sure others would be interested too. Michael
Re: reiserfsck (3.6.19) --rebuild-tree failed
Hi, I'm 100% happy. Now it did not stop. Either it would haven been nessesary to run it twice or the new version I've got from did the trick. Good to hear that! I thank you so much! Now I go any buy a new disk!!! Usually when a disk goes bad you should get a new disk FIRST, then make an image from the old disk with dd_rescue and then use fsck. It is much safer this way and you don't have to fiddle around with the badblock options at all. Useful links: [1] http://www.garloff.de/kurt/linux/ddrescue/ [2] http://www.knopper.net/knoppix/ [3] http://www.extremetech.com/article2/0,1697,1928206,00.asp kind regards, Michael
Re: Maximum number of subdirectories
hello, Vladimir V. Saveliev wrote: Hello On Wed, 2006-05-17 at 17:07 +0800, Sinang, Danny wrote: Hi Vladimir, By current limit, are you pertaining to ReiserFS (v3.x) or Reiser4 ? for both. I guess you mean reiserfs 3.6 and reiser4, or does it also apply to reiserfs 3.5? -- /\ | Michael Weissenbacher [EMAIL PROTECTED] | | http://www.dermichi.com/ | | Email users are divided into two classes;| | 1) Those who have effective spam-blocking| | 2) Those who wish they did | \/
Re: Reiser4 release date and status
Hello, I noticed the REISER4 RELEASED! statement in http://www.namesys.com/download.html and wonder when it did get released and what its status now. it is released but from my experience the latest changes that were necessary to prepare for inclusion into the vanilla kernel have destabilized the code somewhat. The web page seems to have last been updated August 5, 2004 and the warning still says but until a program has seen a few million real users you should not use it for a mission critical server. Does this warning still hold ? i'd say this warning still holds for mission-critical servers. it's ok for desktop use and for testing and development purposes. i may add that the warning is true for about any software that is released, for example you need not be the first one to adapt apache 2.2 on a mission-critical server either. kind regards, michael
Re: quicker mount
Hi, It takes so long to mount since ReiserFS reads all the bitmaps before mounting. The larger the file system, the longer it takes. I wonder why it has to read all of them. Are they stored in RAM after reading? Otherwise I cannot see why it should be done at all. with kind regards, -- /\ | Michael Weissenbacher [EMAIL PROTECTED] | | http://www.dermichi.com/ | | The trouble with computers is that they do what you tell | | them, not what you want. -- D. Cohen| \/
Re: reiser4 bug
Hi, it is known problem. Fixed in 2.6.17-rc1-mm2 (reiser4-have-get_exclusive_access-restart-transaction.patch). as i've been burned by this bug, too i would suggest making a new patch for 2.6.16 including reiser4-have-get_exclusive_access-restart-transaction.patch or at least put a warning there that the version is unstable. i'm sure most people go straight for the vanilla kernel patch and don't bother with mm-kernels. this puts reiser4 in a bad light imo. kind regards, Michael -- /\ | Michael Weissenbacher [EMAIL PROTECTED] | | http://www.dermichi.com/ | | Email users are divided into two classes;| | 1) Those who have effective spam-blocking| | 2) Those who wish they did | \/
Re: fsck.reiser4 segfaults
Hi, reiserfsprogs and libaal are both 1.0.5. I'll give you the dmesg output tommorow - I need to get a livecd with reiser4 patches - its more difficult than I initially thought ;) I'm using RIPLinux, which has reiser4 support. http://www.tux.org/pub/people/kent-robotti/looplinux/rip/ kind regards, Michael -- /\ | Michael Weissenbacher [EMAIL PROTECTED] | | http://www.dermichi.com/ | | In 2010, M$ Windows will be a quantum processing emulation | | layer for a 128-bit mod of a 64-bit hack of a 32-bit patch | | to a 16-bit GUI for an 8-bit operating system written for | | a 4-bit processor from a 2-bit company that can't stand 1 | | bit of competition.| \/
Re: IO randomly blocked for 1 minute while disk writes still in 2.6.16.1 + 2.6.16-reiser4-1
Hi, of the movie. Now, just to know the format, I played it again, and as it began, it blocked again... not even knoppix is downloading on the background. I just wanted to note that i observed that same bahavior. I tried various things, like changing the kernel from preemption to no preemtion, trying the various IO-Schedulers and trying 2.6.15, 2.6.16 and 2.6.16-mm1. In the end i found out that there was a MAJOR performance gain by adding the noatime mount option. Before i added that I had to wait up to 20 minutes sometimes and now it doesn't stall more than a few seconds, but it still does. Seems like reiser4 has very big performance problems with the writing of atimes. Another problem i had was specific to the reiser4-for-2.6.16-1.patch.gz patch. I got a kernel crash two times now, but wasn't yet able to log the error message anywhere because it would not let me write to the reiser4 partition after the error. It never corrupted any data though, fsck.reiser4 always reported a consistent fs. I'll try to trigger that problem again and make another post. -- /\ | Michael Weissenbacher [EMAIL PROTECTED] | | http://www.dermichi.com/ | \/
Re: IO randomly blocked for 1 minute while disk writes still in 2.6.16.1 + 2.6.16-reiser4-1
Hi, Sorry to quote myself here: Another problem i had was specific to the reiser4-for-2.6.16-1.patch.gz patch. I got a kernel crash two times now, but wasn't yet able to log the error message anywhere because it would not let me write to the reiser4 partition after the error. It never corrupted any data though, fsck.reiser4 always reported a consistent fs. I'll try to trigger that problem again and make another post. I've just noticed that this second problem i had is identical with the the thread Re: kernel BUG at /usr/src/sources/linux-2.6.16-rc5/fs/reiser4/plugin/file/tail_conversion.c:29 kind regards, -- /\ | Michael Weissenbacher [EMAIL PROTECTED] | | http://www.dermichi.com/ | \/
Re: reiser4 - Non-removable files in lost+found
in /lost+found. Should I run fsck with --build-fs then? Also, can this be short answer: yes, this renamed the files in lost+found (in my case) so that i could delete them. regards, michael
Re: reiser4 - Non-removable files in lost+found
rm /lost+found/lost_name_* gives: rm: cannot remove `/lost+found/lost_name_5447b:6b68746d6c6361:27e2e2r?\t v\310:H\327\377\257O\275\275: v\310:[EMAIL PROTECTED]:\200r?\t': No such file or directory had the same problem, it is related to fsck which computes hashes the wrong way if filenames are too long (and/or contain non-ascii characters). vladimir sent a patch to the mailing list that corrected this bug for me. not sure if this is already available in the pre-version of reiser4progs. regards, michael
Re: reiser4 - Non-removable files in lost+found
Michael Weissenbacher wrote:
rm /lost+found/lost_name_*
gives:
rm: cannot remove `/lost+found/lost_name_5447b:6b68746d6c6361:27e2e2r?\t
v\310:H\327\377\257O\275\275: v\310:[EMAIL PROTECTED]:\200r?\t': No such
file or directory
had the same problem, it is related to fsck which computes hashes the
wrong way if filenames are too long (and/or contain non-ascii
characters). vladimir sent a patch to the mailing list that corrected
this bug for me. not sure if this is already available in the
pre-version of reiser4progs.
regards,
michael
here's the patch...
--- reiser4progs-1.0.0/plugin/hash/r5_hash/r5_hash.c.orig 2004-08-31 18:48:01.749889832 +0400
+++ reiser4progs-1.0.0/plugin/hash/r5_hash/r5_hash.c 2004-08-31 18:46:08.864051088 +0400
@@ -9,10 +9,12 @@
uint64_t r5_hash_build(char *name, uint32_t len) {
uint32_t i;
uint64_t a = 0;
+ unsigned char *uname;
+ uname = (unsigned char *)name;
for (i = 0; i len; i++) {
- a += name[i] 4;
- a += name[i] 4;
+ a += uname[i] 4;
+ a += uname[i] 4;
a *= 11;
}
Re: EACCESS vs ENOENT for nonexistent files-within-files
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. i think the problem would be solved by mounting the partition with the nopseudos option. of course, this is not the long-term solution. regards, michael
wrong bytes with files =4GiB
I'm using kernel 2.6.9-rc1-mm1 (patched for the page-size bug) and reiser4progs1.0.0. I am able to reproduce a wrong bytes problem by doing the following: # dd if=/dev/urandom bs=4096 count=1048576 of=/mnt/tmp/testfile # umount /mnt/tmp # fsck.reiser4 /dev/sda1 ... FSCK: Node (45223670), item (3), [2a:7465737466696c:1000f] (stat40): wrong bytes(4294967296), Should be (0). ... 1 fixable corruptions were detected in the FileSystem. Run with --fix option to fix them. When doing a fsck.reiser4 with --fix parameter it says FSCK: Node (45223670), item (3), [2a:7465737466696c:1000f] (stat40): wrong bytes (4294967296), Fixed to (0). and after that it says that the fs is consistent. I cannot find any difference in the file on the filesystem though. Is this actually harmful or is it just statistic data? If i'm doing the same test with count=1048575 no corruption is reported and if i'm doing it for files 4GiB i always get the problem (with different numbers of course). I can sent the full fsck output if needed. BTW this problem also occurs with kernel 2.6.8.1-mm2. regards Michael
Re: fsck.reiser4 problem (was: reiser4 corruption problem)
Even though both file sets contain umlauts, or perhaps more accurately extended ASCII chartacters, there is something distinctive in the failure set: the umlauts/extended characters appear after the 15th character. If you are using REISER4_LARGE_KEYS, the first fifteen characters will be shifted into the second and third key elements with the final key el containing the hash of the remaining characters exactly! the problem occurs when using extended characters that appear after the 15th character! Code in fs/reiser4/kassign.c assembles the key and uses your chosen hash, R5 being the default. If you created the files without failure, could read/opened them okay but then FSCK reported problems, could this point to a difference in the hash code (w.r.t. extended ASCII)? I'm on holiday now, so cannot check to see if this suspicion holds any water. yes, create/read/open works ok, a diff shows no difference. after my first tests i panicked because fsck.reiser4 reported fatal corruptions and used --build-fs as suggested. fsck.reiser4 then moved these files to the lost+found directory. fsck.reiser4 didn't report corruoption after that, but there was no way of finding out where the files were before or what their names were. so with this bug fsck.reiser4 is unusable for my situation. would it do any good trying without the REISER4_LARGE_KEYS option? thanks for your time, Michael
Re: fsck.reiser4 problem
- 2.6.9-rc1-mm1 has a bug that affects all filesystems (pointed out earlier today). so don't use if you love your data ;) Can you tell us more about this bug? (I'm using 2.6.9-rc1-mm1 and would like to know, what will happen ;) ) See: http://marc.theaimsgroup.com/?l=linux-kernelm=109360433916523w=2 and the mail in the reiserfs-list by Christian Mairhuber, subject Re: reiserfs3 filesystem corruption? the bottom line is: there are problems with files that are exactly the size of a multiple of 4096, they are truncated by 4096 bytes... Michael
reiser4 corruption problem (maybe related to Broken reiser4 FS)
i've tested reiser4 on a spare partition to see how well it would work for me. unfortunately i hit some corruption problem. it seems perfectly reproducable, so hardware error is very unlikely. first some details on my system: AMD Athlon(tm) XP 2400+ 512 MB DDR-RAM (tested with memtest) MSI K7N2G board (nforce2 chipset) hard disk for testing: MAXTOR 6L080J4 (80GB), partitioned like: Device Boot Start End Blocks Id System /dev/hdb1 1486639086113+ 83 Linux /dev/hdb24867973239086145 83 Linux criminal mnt # uname -a Linux criminal 2.6.8.1-mm4 #4 Wed Aug 25 01:34:48 CEST 2004 i686 AMD Athlon(tm) XP 2400+ AuthenticAMD GNU/Linux the distro is gentoo and i use reiser4progs1.0.1 the test i did is rather simple: i have a 2.3GB .tar.bz2 file that cotains 66588 files and about 3.1GB of data. in the first test i formatted /dev/hdb1 as reiser4 and /dev/hdb2 as reiser3. i extracted the .tar.bz2 on both of them. after that i umounted both and ran a fsck on them. the reiser3 partition was ok, but the reiser4 partition was corrupted. ok, but what's really intersting now: i reformatted both partitions and switched hdb1 to reiser3 and hdb2 to reiser4. i extracted the same file on both and what happens? exaclty the same corrutions now on hdb2 (at least the count is the same and the errors look very similar)! and again reiser3 is ok! i put the output of both tests into a file that is available at http://www.dermichi.com/ablage/reiser4/reiser4_troubles.txt i've already had the exact same problems before, i mean errors like: FSCK: Directory [109e8:416c74:109ee] (dir40), node [216782], item [1], unit [22]: entry has wrong offset [109ee:0(NAME):142657765726275:6e6746fc72416e77:135160352fe624]. Should be [109ee:0(NAME):142657765726275:6e6746fc72416e77:13514d8cfe19f4]. while doing random other things on reiser4 partitions and fsck'ing afterwards. using --build-fs created lots of files under lost+found and i started over. i will leave the fs this time, maybe i can try some things to find the cause of the problem. anyone got an idea? thanks, michael weissenbacher
