Re: Which version will be merged into mainline kernel?
On 11/8/06, Clemens Eisserer [EMAIL PROTECTED] wrote: Hello again, Thanks a lot for all the help, well ... I now use reiser4 as root-partition :-) Everything works ok and I haven't seen any crashes or compatibility problems, simply wonderful :-). If something bad happens I'll let you know ;) However performance is so-and-so, the system was faster with ext3, although I compiled the kernel with -O3 -march=pentium4 -mtune=pentium4 -mno-sse -mno-sse3. Booting the system into KDE takes about twice the time, although I have to admit I was using another harddrive - I now use a 60GB/4200RPM instead an 40GB/4200RPM which both show quite the same hdparm-results, I use the lzo1 plugin (default ccreg40). Are there some settings (or ext3 optimizations) in FC6, or could it be that some of my kernel-settings slow things down for FC6 (the same compiled kernel-binary was already used for ext3). The reiser4-partition is mounted with noatime. These are some features I could imagine causing problems: * Inotify * Adaptive file readahead + hit feedback + fine grained readahead aging * Timer with 1kHz * Readahead-script of the distribution noatime and nodiratime mount options can also improve Reiser4 performance a lot. better solution for the fsync problem is a library like http://ftp.die.net/pub/qmail-tools/libnosync.c , which can be used only when needed. -- Jindrich Makovicka
reiser4 - slow copying to USB drive
Hello, I encountered another problem which seems to be related to flushing: When there runs an application which does very little but contiguous writes (like bittorrent client), copying from disk to a thumb drive fills the memory with the data to be written to fat32 fs, and it seems that the memory pressure causes the reiser4 writes to be flushed immediately, which results in a huge slowdown. In my case the thumb drive is able to write about 10MB/s, but after a while, when the RAM fills up, the speed drops to 3MB/s, because the hard drive is busy writing. Regards, -- Jindrich Makovicka
Re: Reiser4 und LZO compression
On Sun, 27 Aug 2006 04:42:59 -0500 David Masover [EMAIL PROTECTED] wrote: Andrew Morton wrote: On Sun, 27 Aug 2006 04:34:26 +0400 Alexey Dobriyan [EMAIL PROTECTED] wrote: The patch below is so-called reiser4 LZO compression plugin as extracted from 2.6.18-rc4-mm3. I think it is an unauditable piece of shit and thus should not enter mainline. Like lib/inflate.c (and this new code should arguably be in lib/). The problem is that if we clean this up, we've diverged very much from the upstream implementation. So taking in fixes and features from upstream becomes harder and more error-prone. Well, what kinds of changes have to happen? I doubt upstream would care about moving some of it to lib/ -- and anyway, reiserfs-list is on the CC. We are speaking of upstream in the third party in the presence of upstream, so... The ifdef jungle is ugly, and especially the WIN / 16-bit DOS stuff is completely useless here. Maybe just ask upstream? I am not sure if Mr. Oberhumer still cares about LZO 1.x, AFAIK he now develops a new compressor under a commercial license. Regards, -- Jindrich Makovicka
Re: rephrase..
On Sat, 22 Jul 2006 12:48:48 +0200 Dirk [EMAIL PROTECTED] wrote: will fsck.reiser4 --build-fs repair the partition by formatting it?? No, you should get your data back, unless you hit a bug in fsck (I am not aware of any such report recently). The only problem with fsck.reiser4 is that it's hard to figure out what files got actually damaged - most of its messages are probably useful only to people familiar with Reiser4 internals. If you are running tripwire or something similar, I recommend rechecking the files as soon as you repair the filesystem. -- Jindrich Makovicka
Re: short term task list for Reiser4
On Fri, 14 Jul 2006 00:01:49 -0700 Hans Reiser [EMAIL PROTECTED] wrote: rvalles wrote: I believe those two are related. I'm having the pauses (of many minutes at times!) when writing to reiser4. It seems it is triggered mostly by the use of fsync(); NFS in sync mode manages to trigger it way often: I mount my old desktop's home from my new computer via synced NFS. The pauses consist in the application being frozen and the other applications being slowed down on their IO operations, while the disks writes data continously during an interval that usually last a minute or so, but may last many times that. It often happens with small files (like, when sending a mail, as it passes through the MTA), so I believe it probably (re)writes to disk lots of stuff that doesn't need to be written to disk at all. It only happens on reiser4 patches against 2.6.13 or newer, 2.6.12.x is fine. So the pauses are experienced by a process waiting on fsync to finish? If yes, then the problem is a very different issue from what I thought I am pretty sure I triggered the same a couple of times with aMule, which was downloading and uploading about 20-30kB per second in each direction, and randomly accessing larger files. Doing a sync then suddenly caused the disk seek like crazy and write about 500kB per second constantly. I waited about a minute, and then better killed aMule. Could it be possible that sync tries to sync the writes which arrive during the operation and cannot catch up? -- Jindrich Makovicka
Re: kernel BUG at fs/reiser4/plugin/file/tail_conversion.c:80?
On Sun, 21 May 2006 12:39:05 +0200 Maximilian Mehnert [EMAIL PROTECTED] wrote: Kernel-Patch: reiser4-for-2.6.16-2.patch.gz kernel BUG at fs/reiser4/plugin/file/tail_conversion.c:80! invalid opcode: [#1] [...] I thought that maybe someone with greater insight than I might be interested in the attached kernel dump. I don't know how to reproduce this - the only thing I can say is, that I had several reiser4 partitions under heavy load. (Now I changed to reiserfs... Too many problems with reiser4 during the last days.. :-( ) This was a really frequent matter during the last two weeks. Please look for the patches that were posted. I noticed another thing: using reiser4 for some days on my laptop rendered kopete (instant messaging application) nearly unresponsive. Looking at the output of strace it seems that the frequent use of fsync() (in sqlite) causes heavy i/o with reiser4. This problem does not occur with ext3 or reiserfs... This is a known issue. fsync() and sync() generate a lot of seeking, and are painfully slow. I have the same problems with postgresql's vacuum and db4 open/close here. Regards, -- Jindrich Makovicka
Re: 2.6.16-rc6-mm2: slow writes on reiser4.
Hans Reiser wrote: Instead of using sync, could you increase the size of the files you write so that they are 10x ram size? I have a suspicion we are slow at sync I am not sure why, but I have seen other data where sync was slow for us, and maybe we need to optimize that code path. My impression is rather that the bottleneck is the amount of seeking the sync causes - would it be possible to reorder the write operations somehow, still preserving atomicity? Also, a comparison of Reiser4 performance on NCQ vs. non-NCQ drive could be interesting (I don't have NCQ, maybe that's the problem). Regards, -- Jindrich Makovicka
Re: reiser4progs 1.0.4
Vitaly Fertman wrote: On Friday 18 March 2005 21:59, Jindrich Makovicka wrote: Vitaly Fertman wrote: so 1.0.3 1.0.4 bail out. Using fsck.reiser4 --build-sb from reiser4progs 1.0.3 rendered the filesystem created under 1.0.0 unusable, fsck.reiser4 --build-sb is supposed to fix evth. what goes wrong? sorry I didn't replied earlier, but I didn't have a spare disk available. here it goes. 40GB partition was mkfs'ed with 1.0.0, populated somehow (about 32k files, 400MB), then fsck --build-sb from 1.0.4 was run: I think I didn't run mkfs 1.0.4. I once tried debugfs.reiser4 -C on the test partition before fsck, as I had run it on one of my live partitions previously, because I originally thought it does the migration (the partition seems to have survived). Can this be the cause too? Is it still possible to migrate such partition to 1.0.4 or I should do full backup dd if=/dev/zero /dev/hdXX mkfs restore? -- Jindrich Makovicka
Re: reiser4progs 1.0.4
metadata were found. Semantic pass is skipped. * fsck.reiser4 finished at Fri Mar 18 19:49:10 2005 Closing fs...done NO REISER4 METADATA WERE FOUND. FS RECOVERY IS NOT POSSIBLE. 8--- snip -- Jindrich Makovicka
Re: reiser4progs 1.0.4
Ookhoi wrote: Fatal: Failed to open the reiser4 backup. Fatal: Cannot open the FileSystem on (/dev/hda1). 1 fatal corruptions were detected in SuperBlock. Run with --build-sb option to fix them. Anyway, what is the preferred way to convert reiser4 to this new backup layout? I have all reiser4 partitions created with reiserfsprogs 1.0.0, so 1.0.3 1.0.4 bail out. Using fsck.reiser4 --build-sb from reiser4progs 1.0.3 rendered the filesystem created under 1.0.0 unusable, I still didn't try fsck 1.0.4. I also found the -C option of debugfs.reiser4, but it didn't help either, and subsequent fsck also botched the filesystem. Were there any fixes in 1.0.4 regarding this? Thanks, -- Jindrich Makovicka
