Only a fool argues against a fool ;)
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 changed,
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
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
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 t
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 shoul
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 the
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
> compli
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.
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 s
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
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,
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, an
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 b
Hi again,
Don't know what its worth:
I disabled readahead completly and now KDE starts almost as fast as on EXT3.
lg Clemens
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 t
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 ;)
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 thin
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 l
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
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
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 destroyed
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.
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 t
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.
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