Only a fool argues against a fool ;)
Hi there,
First of all this discussion is about ... well isn't it of topic here at all?
journaling support has been late on Linux. Everything seems to be late
on Linux. Real-time support, preemptive support...
Yes Linux is late on everything because things are done when there is
_real_ demand
So, you have to have a way to insure data integrity beyond flushing it
to disk. Flushing it to disk is just a bit of unneeded integrity, that
costs a little bit of performance, and would probably save your ass in
one or two edge cases, but those cases shouldn't normally happen, and if
you're
David Masover wrote:
Christopher Chan wrote:
Anyway I guess you are smarter than Hans then since you obviously
feel that his use of fsync is a bit of unneeded integrity.
I'm not going to respond to this until you phrase it in a way which
doesn't gossip about Hans. Unless something has
David Masover wrote:
Christopher Chan wrote:
Danny Milosavljevic wrote:
The only possibility one could still lose mail when having proper
hardware failsafes would be if the kernel had a bug and crashed (and
that's
so bad, it doesn't really warrant any working around it).
Ever used DOS with
Hi,
On Mon, 13 Nov 2006 17:34:59 +0800, Christopher Chan wrote:
David Masover wrote:
Christopher Chan wrote:
[...smartdrv...]
Yeah, smartdrv was nice :)
[...]
Try arguing why you lost thousands of mails when the box crashed and
justifying it.
Oh. Good point.
So the bad case is:
1.
Hi,
On Sat, 11 Nov 2006 14:28:42 -0500, Valdis.Kletnieks wrote:
[...]
I've never understood this kind of attitude some filesystems have. Usually
the hardware would make sure that stuff doesn't disappear, and not some
weird software workarounds like journalling or write barriers that
While we are at it:
I take it that this is the reason journalling support is only picking up
now: the disks are so big that even in the unlikely event that some of the
hardware failsafes fail, one just cannot fsck all the disks completely
anymore, ever.
Only picking up now??
reiserfs was
So the bad case is:
1. mails are tiny
2. RAM cache is big
3. cache doesn't get flushed to disk for 1000s of mails
4. crash happens seldomly, but severely :)
- 1000s of mail lost by the crash
Now I see :)
:). So fsync/fsyncdata takes care of those rare crashes which is why
mail servers
Which is why data important software use fsync/fsyncdata to minimize
data loss from crashes.
If (and only if) you actually read and accepted the paragraph you're
quoting there, the point is that using fsync and fdatasync on these is
kind of like doing bad block relocation in software, when
Danny Milosavljevic wrote:
Hi,
On Wed, 08 Nov 2006 03:21:36 -0700, Andreas Dilger wrote:
On Nov 08, 2006 10:15 +0100, Francesco Biscani wrote:
I think the slow performance you're experiencing are caused by the fsync()
call not being well-optimized in reiser4. I've commented out the function
Hi,
On Wed, 08 Nov 2006 03:21:36 -0700, Andreas Dilger wrote:
On Nov 08, 2006 10:15 +0100, Francesco Biscani wrote:
I think the slow performance you're experiencing are caused by the fsync()
call not being well-optimized in reiser4. I've commented out the function in
fs/buffer.c, and I'm
On Sat, 11 Nov 2006 15:14:18 GMT, Danny Milosavljevic said:
I've never understood this kind of attitude some MTAs have. Usually the
hardware would make sure that stuff doesn't disappear (UPS, powered RAM,
harddisk condenser) and not some weird software workaround that complicates
and slows
Hi again,
Don't know what its worth:
I disabled readahead completly and now KDE starts almost as fast as on EXT3.
lg Clemens
sorry, my last message was not really clear:
I didn't change the kernel, I just disable the preload-scripts
executed by fedora.
I first tried to inlucde the whole KDE stuff but found it to be even
slower so I disabled them completly and now everything works fine :-)
I guess this could be maybe
On Wednesday 08 November 2006 08:21, Clemens Eisserer 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
On Nov 08, 2006 10:15 +0100, Francesco Biscani wrote:
I think the slow performance you're experiencing are caused by the fsync()
call not being well-optimized in reiser4. I've commented out the function in
fs/buffer.c, and I'm having much better performance on my / partition.
I don't think
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 ;)
Hi again,
I think the slow performance you're experiencing are caused by the fsync()
call not being well-optimized in reiser4. I've commented out the function in
fs/buffer.c, and I'm having much better performance on my / partition.
I don't think this can be advocated as a real solution to
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
Hello,
ok, a bit later
No need to hurry ;)
both compressed and decompressed data are cached, it means that
cryptcompress file requires *(2-R) more memory then usual file
(R - compression ratio)
Oh ... thats a drawback. It means the performance advantage
compression will do will be
Hi again,
How much RAM?
512mb, DDR1 PC2700
Thanks, but the status of this account seems to be unclear
Ok, then I'll wait till there are other ways to donate.
Thanks a lot, Clemens
Hi,
If you want to try out in the latest -mm kernel,
then we will send you the setup.
I'll setup my laptop within the next days and will compile the latest
-mm kernel.
Could you send me the setup, please? (Do you mean the kernel-setup,
or a howto?)
Thanks a lot in advance, lg Clemens
Btw. a
Hi again and thanks for the response,
Will reiser-4.0 or reiser-4.1 be merged into mainline kernel, I ask
I don't know, why it should be merged partially.
I.e. all or nothing.
I thought that compression belongs exclusivly to reiser4-4.1, and
maybe because of stability issues only reiser4-4.0
Hello Clemens,
Tuesday, October 17, 2006, 11:14:33 PM, you wrote:
somewhere that first 2.6.19 was the goal but now it is 20 or 21. Is it
now more or less a predictable thing, only when exactly is still open
or can kernel devs still change their opinion?
It is largely up to Andrew Morton. I
Hello,
Will reiser-4.0 or reiser-4.1 be merged into mainline kernel, I ask
because I am quite interrested in trying out the compression plugin.
Sorry about what happend in the last few days :-/
lg Clemens
26 matches
Mail list logo
