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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
