lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 09 Apr 2007 00:58:53 +0200
From:	Richard Knutsson <>
CC:	Christer Weinigel <>,,,
Subject: Re: Reiser4. BEST FILESYSTEM EVER - Christer Weinigel

Wow, I'm impressed. Think you got the record on how many mails you 
referenced to in a reply... But dude, please calm down, the caps-lock is 
not the answer. You have got some rude answers and you have called them 
back on it + you have repeated the same statement several times, that is 
not the best way of convincing people.

I believe you picked up the "anti-Reiser religion"-phrase from previous 
rant-wars (otherwise, why does that "religion"-phrase always come up, 
and (almost) only when dealing with Reiser-fs), and yes, there has been 
some clashes caused by both sides, so please be careful when dealing 
with this matter.

Would you be willing to benchmark Reiser4 with some compressed 
binary-blob and show the time as well as the CPU-usage? And document how 
it is set up so it can be reproduced. After all, Windows is suppose to 
be more stable, maintained and cost-efficient then Linux, but they don't 
tell us how ;)

>> since it can't benefit as much from similarity between
>> files. So if that is the case and you really want to save diskspace you
>> almost have to look at read-only compressed filesystems such as cramfs,
>> squashfs, zisofs, cloop and various other variants in combination with
>> a unionfs overlay to get read/write functionality.
>> But in the end everything is a tradeoff. You can save diskspace, but
>> increase the cost of corruption. 
> You deliberately ignored the fact that bad blocks are NOT dealt with by
> the filesystem,... but by the operating system. Like I said: If your
> filesystem is writing to bad blocks, then throw away your operating
> system.
I may have missed something, but if my room-mate took my harddrive, 
screwed it open, wrote a love-letter on the disk with a pencil and then 
returned it (ok, there may be some more plausible reasons for 
corruption), is the OS really suppose to handle it? Yes, it should not 
assign any new data to those blocks but should it not also fall into the 
file-systems domain to be able to restore some/all data?

Just my 2c to the pond
Richard Knutsson

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists