thanks for removing super.c:read_bitmaps
Hi! Thanks for removing super.c:read_bitmaps (2.6.19) - it really speeds up mounting and is more fair. -- ciao - Stefan
Re: Reiser4 und LZO compression
On Tue, Aug 29, 2006 at 03:45:59PM +0200, PFC wrote: Anyone has a bench for lzf ? It's easy, try something like: wget http://www.goof.com/pcg/marc/data/liblzf-1.6.tar.gz tar zxvpf liblzf-1.6.tar.gz cd liblzf-1.6 configure make Now you have a small lzf binary that you can use for testing: cat bigfile|./lzf bigfile.lzf use ./lzf -d for decompression tests -- ciao - Stefan
Re: Reiser4 und LZO compression
On Mon, Aug 28, 2006 at 10:06:46AM -0700, Hans Reiser wrote: Hmm. LZO is the best compression algorithm for the task as measured by the objectives of good compression effectiveness while still having very low CPU usage (the best of those written and GPL'd, there is a slightly better one which is proprietary and uses more CPU, LZRW if I remember right. The gzip code base uses too much CPU, though I think Edward made I don't think that LZO beats LZF in both speed and compression ratio. LZF is also available under GPL (dual-licensed BSD) and was choosen in favor of LZO for the next generation suspend-to-disk code of the Linux kernel. see: http://www.goof.com/pcg/marc/liblzf.html -- ciao - Stefan
Re: reiser4 plugins
On Mon, Jul 11, 2005 at 10:33:24PM -0400, Horst von Brand wrote: Hans Reiser [EMAIL PROTECTED] wrote: I chose '' (four dots) because it clashes with less, not three dots. Is this some kind of My dots are more than yours contest?! /None/ of them is safe. .meta, ..., , .this.has.five.dots. are all perfectly legal file (or directory) names, POSIXly. If any one of them won't do, none will. Correct. I suggest lost+found. It's also a legal name but was always somewhat special. [not sure if I should place a smiley here] -- ciao - Stefan
Re: [PATCH] reiserfs: on-demand bitmap loading (testing only)
On Fri, Jul 08, 2005 at 09:35:28AM +0400, Alexander Zarochentsev wrote: Lena, may you check how the bitmap on-demand loading patch affects, say, mongo results for reiserfs? Alex, it seems that to share Jeff's view - for me it's a question of correctness. You can't test correctness with benchmarks - well except your name is Yury - http://oesiman.de/last-words-1.html :) -- ciao - Stefan
Re: [PATCH] reiserfs: on-demand bitmap loading (testing only)
On Fri, Jul 08, 2005 at 12:52:52AM -0400, Jeffrey Mahoney wrote: It's possible to read the bitmaps in a delayed fashion, but the problem of completely wasted resources is still not addressed. I feel the correct solution is to let the buffer cache do its job and not assume that any particular filesystem takes priority over other resources. I feel 100% with you. Getting rid of super.c:read_bitmaps is nothing but a bug-fix. -- ciao - Stefan
Re: Congratulations! we have got hash function screwed up
On Thu, Dec 30, 2004 at 09:57:29PM +0100, Adrian Ulrich wrote: A flaw in the filesystem, in my opinion, is equivalent to the space ship crashing and all crew members die. No, it isn't.. A dying filesystem is a bad thing.. But it's just a filesystem.. ... that causes the space ship to crash. Please think before you post. -- ciao - Stefan GNU's Not Unix --IIS Isn't Secure
Re: Congratulations! we have got hash function screwed up
On Tue, Dec 28, 2004 at 11:12:18PM +0100, Marc A. Lehmann wrote: ReiserFS: hdg2: warning: reiserfs_add_entry: Congratulations! we have got hash function screwed up Sure sounds like a filesystem bug to me. Is this 2.6.10-rc3-specific or a generic bug in handling hash collisions? I can confirm that with 2.6.10. It is independent of hash function (r5, rupasov, tea) used. Here a script that works independent of hash (feel free to forward it to bugtraq - it's a showstopper bug): #! /bin/sh # reiserfs v3 denial of creation attack (hash collisions) # insider: EHASHCOLLISION EAGAIN! # ATTACK= R5= 03435823 22067556 40799289 47672563 79051844 97783577 000119162858 000125037032 000137894590 000156516313 000169273871 000175148046 000193879879 000209384885 000228006608 000246738340 000252611615 000259495899 000278117621 000296849354 000305480087 000311354361 000318228635 000342833642 000361465375 000374212923 000392944656 000401576389 000414323937 000439929944 000445803118 000464434950 000470309125 000483066683 000504545964 000523177697 000560530152 000567404427 000573288700 000598893708 000600641166 000607515440 000626147173 000632020447 000657626454 000676258187 000689005735 000729116749 000747848481 000753721756 000779227762 000797959495 000806590218 000819338776 000843943783 000862575506 000888080512 000921308252 000934065800 000946913259 000952797533 000971419266 000984176814 001008625581 001027257304 001033130588 001051862310 001058736595 001070494043 001077368318 001117479331 001136100064 001148958612 001154831897 001160706070 001186211078 001213574633 001226322091 001257801372 001263685647 001289190653 001295064928 001303796660 001316544109 001322418393 001335175941 001366655122 001385286955 001406766136 001425397969 001431271143 001462750424 001481382157 001502861438 001509735712 001521493170 001528367445 001534240719 001552972451 001559846726 001578478459 001611705198 001618589472 001661816201 001687321209 001714684774 00172743 001758911503 001764795788 001777543236 001783417510 001823528524 001849033530 001867765263 001873639538 001892270270 001907876277 001932381284 001945129832 001951003007 001963860565 001976609013 001982492298 002012815329 002019699603 002031447061 002038320336 002050078894 002062926342 002081558075 RUPASOV= 16777216 33554432 50331648 67108864 83886080 000100663296 000117440512 000134217728 000150994944 000167772160 000184549376 000201326592 000218103808 000234881024 000251658240 000268435456 000285212672 000301989888 000318767104 000335544320 000352321536 000369098752 000385875968 000402653184 000419430400 000436207616 000452984832 000469762048 000486539264 000503316480 000520093696 000536870912 000553648128 000570425344 000587202560 000603979776 000620756992 000637534208 000654311424 000671088640 000687865856 000704643072 000721420288 000738197504 000754974720 000771751936 000788529152 000805306368 000822083584 000838860800 000855638016 000872415232 000889192448 000905969664 000922746880 000939524096 000956301312 000973078528 000989855744 001006632960 001023410176 001040187392 001056964608 001073741824 001090519040 001107296256 001124073472 001140850688 001157627904 001174405120 001191182336 001207959552 001224736768 001241513984 001258291200 001275068416 001291845632 001308622848 001325400064 001342177280 001358954496 001375731712 001392508928 001409286144 001426063360 001442840576 001459617792 001476395008 001493172224 001509949440 001526726656 001543503872 001560281088 001577058304 001593835520 001610612736 001627389952 001644167168 001660944384 001677721600 001694498816 001711276032 001728053248 001744830464 001761607680 001778384896 001795162112 001811939328 001828716544 001845493760 001862270976 001879048192 001895825408 001912602624 001929379840 001946157056 001962934272 001979711488 001996488704 002013265920 002030043136 002046820352 002063597568 002080374784 002097152000 002113929216 002130706432 002147483648 002164260864 TEA= 04464160 41804440 80240100 91329029 000104181015 000113725885 000126527488 000140392446 000158910938 000228997445 000230956744 000265118409 000278488948 000294393023 000295253722 000300066283 000302103786 000330187358 000345002932 000351581026 000363320013 000366148241 000398298703 000411084407 000430270876 000450889104 000457353842 000459620112 000464658163 000465039241 000472966466 000479773493 000485638992 000490029225 000519300138 000523222490 000543871739 000550161091 000614863063 000628859470 000658101403 000705881242 000707428465 000709541412 000710835913 000712765852 000747815906 000751391777 000758206682 000759473821 000761493018 000807141251 000819925766 000822342439 000844968698 000846939644 000856679997 000862332598 000897273990 000903164600 000959685453 000966591643 000975714799 001026819859 001030872126 001052008464 001101513177 00878931 001114914486 001126417564
Re: reiser4 non-free?
On Thu, May 06, 2004 at 11:41:02AM -0700, Hans Reiser wrote: I don't think my clarifications of what is a derivative work conflicted with the GPL, they merely make it less vague as to what is a derivative clearifications are modifications to the license and thereof not relevant and incompatible to GPL. -- ciao - Stefan
Re: Fwd: reiser4 non-free?
On Sun, May 02, 2004 at 12:12:04PM -0700, Hans Reiser wrote: the main killer for 8 of the 9 reviewers, at least one of whom seemed to think that it would make the project unlikely to get anywhere in the Linux community ) I spent weeks on that proposal ooops. Hans, don't get me wrong now. I really think that you have great visions and that you discovered the golden rule: visions are useless if you can't transform them into reality. I do not know if there any discussions about getting reiser4 into the standard kernel but I guess some people are at least not amused to see a random syscall that has a version number in it's name to go into the standard kernel. I didn't care - until you declared reiserfs3 obsoleted by reiser4 in public. syscalls tend to have a longer expectation of life than filesystems - I'm very sure that fork(2) is older than ext2 - so please at least consider the removal of the version number and think about active long-term support. If the syntax of the reiser[4]()-syscall is really as desribed on http://namesys.com (reiser4() System Call Description) I do not expect that stuff will make it into the mainstream kernel. Please really don't get me wrong - I just remember EHASHCOLLISION which was simply unacceptable for the mainstream kernel - IIRC Chris patched it out not many seconds before Linus accepted reiserfs - after many discussions. -- ciao - Stefan
Re: [reiserfs-list] OT: Exabytes (was: reiser4 key layout.)
On Wed, Oct 31, 2001 at 05:09:31PM +0100, Klaus Ridder wrote: According to http://www.ccsf.caltech.edu/~roy/dataquan/ , 5 Exabytes are the equivalent to all words ever spoken by human beings. So Don't forget to add an additional exabyte for my girlfriend. thanks. -- ciao - Stefan
Re: [reiserfs-list] OT: Exabytes (was: reiser4 key layout.)
On Wed, Oct 31, 2001 at 06:58:56PM +0100, Xuân Baldauf wrote: Stefan Traby wrote: On Wed, Oct 31, 2001 at 05:09:31PM +0100, Klaus Ridder wrote: According to http://www.ccsf.caltech.edu/~roy/dataquan/ , 5 Exabytes are the equivalent to all words ever spoken by human beings. So Don't forget to add an additional exabyte for my girlfriend. thanks. That is... insulting, I think. If your girlfriend talked 100 years without interruption, that speech would only need 48 TeraBytes if it was recorded in standard stereo mp3 format. So you are exaggerating at least by 210%. Why wasting CPU cycles in mp3 encoding ? Target is /dev/null anyway. It really makes no sense to store it, it's just an exabyte for the entropy pool of /dev/random. Please read drivers/char/random.c: * Sources of randomness from the environment include inter-keyboard * timings, inter-interrupt timings from some interrupts, and other * events which are both (a) non-deterministic and (b) hard for an * outside observer to measure. Randomness from these sources are So if I would patch the driver, I could remove the hash transformation because her speak is (a) perfect non-deterministic and (b) extremely hard for an outside observer to measure. -- ciao - Stefan
Re: [reiserfs-list] I've screwed something up
On Sun, Sep 16, 2001 at 04:36:43AM -0400, Elliott Potter wrote: dd if=/dev/sda4 of=/dev/sdb1 conv=noerror bs=4M use bs=512 conv=noerror,sync Without sync target blocks may have different offsets (after error block) and if you use bs=4M you may loose much more data. Really, all reiserfs errors you've noted are maybe just caused by your funny dd arguments. -- ciao - Stefan
Re: [reiserfs-list] [patch] ignore forcefsck
On Sat, May 19, 2001 at 11:31:29AM -0700, Hans Reiser wrote: There are two sides of this. fsck is only now getting strong enough that I would start to recommend that kind of thing. As fsck matures, we should at least have the option of ext2 style automatic runs after X number of mounts/crashes. No, this is an absolutely hideous feature of ext2, if you want to have it print a reminder to the user that they have not run fsck recently, fine, but in the eyes of a suser trying to get their laptop to turn on for their presentation, or their server to not leave the whole company hanging, this feature of ext2 fsck is a bug. Sorry. It's never a bug. You can control the behavior quite easily by tune2fs. Mount count: 3 Maximum mount count: 20 Last checked: Thu May 3 04:16:07 2001 Check interval: 15552000 (6 months) So it's clearly a feature that makes sense at least in some environments. -- ciao - Stefan Man gebe jedem Niedersachsen - seinen eigenen Castor-Kasten. Stefan TrabyLinux/ia32 fax: +43-3133-6107-9 Mitterlasznitzstr. 13 Linux/alphaphone: +43-699-10157505 8302 Nestelbach Linux/sparc http://www.hello-penguin.com Austria mailto:[EMAIL PROTECTED] Europe mailto:[EMAIL PROTECTED]
