Re: Possible interference between reiser4 and usb-storage?
Hi again, I would recommend to use on-the-fly conversion to unix-file plugin. It will reduce memory usage for incompressible files. You will need to reformat your root partition. Use mkfs.reiser4 -o create=ccreg40,compressMode=conv /dev/xxx to enable this. But first rebuild kernel with the attached patch. This feature is relatively new, so it would be better to have a backup of your root partition and update it from time to time. Thanks a lot ... I'll give it a try soon when I'll get my new laptop. Congratulations to reiser4's stability - I ever encountered a single stability or data corruption problem. However lately I deleted about 8 700mb files (mpg) and my laptop was busy for about 5min. I deleted it using konqueror - do you have an idea why deleting such large files is that slow? Thank you in advnace, lg Clemens
Re: Possible interference between reiser4 and usb-storage?
Thanks a lot for the detailed explanation. Current conversion policy (convert to extent, if first 64K are incompressible) allows to properly handle ~50% of all mpegs. I hope it can be increased up to 70-80% using only cosmetic changes. However, other problems you described (a lot of HD seeks, slow directory listing) should disappear with the _current_ conversion stuff. 1.) Ok, you convinced me ... I'll try it out very soon. Is the patch you mentioned against my patched 2.6.19rc4-mm1 kernel which has already been patched by a patch you posted on the list about 1 month ago when I asked about compression? I'll do some timings before and let you know how well it does. 2.) Is there a way to find out how much a file / files have/has been compression. If I ask konqueror how large all sub-stuff of a directory is, is this the compressed size or the size the uncompressed files have? Thanks a lot for all your patience, lg Clemens
Re: Possible interference between reiser4 and usb-storage?
Hi again, ...after some time, so right after mkfs df(1) is telling the truth? Does it drop to 52MB all of a sudden or does it decrease slowly? does it happen with other/former kernels too? Well the cable was bad - it worked well on another computer but on mine it lead to usb read failures. It never drops to 52mb, it gros to a 55GB disk, this happened as soon as I got messages about invalid fat read operations on syslog. (caused by the usb problems) Does it happen without the tweak? Why are you using -O3 anyway, does it really make a difference? Don't know since it works now. Well under normal circumstances I guess -O3 does not make much difference (since kernel is much more generic code instead of numbercrunching stuff) but since I use cryptocompress at least reiser4 is crunching numbers ;) lg Clemens PS: I am really impressed about the stability of reiser4 - I never ever had a single problem. However performance is terrible with cryptocompress enabled: - Drive does way too much seeks - Directory listing is slow - a directory listing using konqueror takes about 10s the first time I open konqueror (with 148files/folders in it), the second time its as fast as it should. - Writes block sometimes the system, nerving while watching video or playing games. - Delete operations sometimes take a lot of time (deleting a e.g. 500mb video file). lg Clemens
Re: Possible interference between reiser4 and usb-storage?
Hi again, Sorry but I wonder why you worry about my setup... The kernel is also something that should arguably take up less RAM. For one thing, it can't be swapped out... Well I am completly happy with my kernel build - the executable is about 1.5mb which I don't care at all. The ~0.2mb I would save with O2 don't matter at all. Another more dramatic effect which needs to be analyzed are L1/L2 cache misses which are more likely to occur with larger code - but since the LZO-code of Reiser4 is very small it fits into L1 anyway. biggest optimization you do when compiling your own kernel is selecting a CPU. Well but at least for kernel 2.6.19 it does not make any difference if you select p-pro, p2, p3 or p4 - the emitted code will alway be i686 compatible, only instruction sceduling is tuned for the given CPU. Thats why I altered my Makefile.cpu to : cflags-$(CONFIG_MPENTIUM4) += -march=pentium4 -mno-sse -mno-sse2 -mtune=pentium4 lg Clemens
Re: Possible interference between reiser4 and usb-storage?
On Sun, 19 Nov 2006, Clemens Eisserer wrote: am using cryptocompress with the 2.6.19rc4 kernel and after some time df reports something like: ...after some time, so right after mkfs df(1) is telling the truth? Does it drop to 52MB all of a sudden or does it decrease slowly? does it happen with other/former kernels too? /dev/sda1 55068032 32996604 22071428 60% /mnt (1GB flash storage) however sda1 is a 1gb usb storage device!! What does fdisk say? Could that be because I compiled the kernel with -O3? Does it happen without the tweak? Why are you using -O3 anyway, does it really make a difference? Christian. -- BOFH excuse #400: We are Microsoft. What you are experiencing is not a problem; it is an undocumented feature.
Possible interference between reiser4 and usb-storage?
Hello, I know this is a strange question, but could it be that because of reiser4 or the development I experience problems with usb-storage? I am using cryptocompress with the 2.6.19rc4 kernel and after some time df reports something like: /dev/hda3 55068032 32996604 22071428 60% / (my reiser4 / partition) /dev/hda1 147764 14579125556 11% /boot (ext3, boot) tmpfs 256988 0256988 0% /dev/shm /dev/sda1 55068032 32996604 22071428 60% /mnt (1GB flash storage) however sda1 is a 1gb usb storage device!! Could that be because I compiled the kernel with -O3? (any experiences about compiling the kernel with this switch?). Thank you in advance, lg Clemens
