Reiser4 performance a lot.
better solution for the fsync problem is a library like
http://ftp.die.net/pub/qmail-tools/libnosync.c , which can be used
only when needed.
--
Jindrich Makovicka
that the memory pressure causes the reiser4 writes to be flushed
immediately, which results in a huge slowdown. In my case the thumb
drive is able to write about 10MB/s, but after a while, when the RAM
fills up, the speed drops to 3MB/s, because the hard drive is busy
writing.
Regards,
--
Jindrich Makovicka
, and especially the WIN / 16-bit DOS stuff is
completely useless here.
Maybe just ask upstream?
I am not sure if Mr. Oberhumer still cares about LZO 1.x, AFAIK he now
develops a new compressor under a commercial license.
Regards,
--
Jindrich Makovicka
hard to figure out what files got actually
damaged - most of its messages are probably useful only to people
familiar with Reiser4 internals. If you are running tripwire or
something similar, I recommend rechecking the files as soon as you
repair the filesystem.
--
Jindrich Makovicka
and cannot catch up?
--
Jindrich Makovicka
i/o with reiser4. This problem does
not occur with ext3 or reiserfs...
This is a known issue. fsync() and sync() generate a lot of seeking,
and are painfully slow. I have the same problems with postgresql's
vacuum and db4 open/close here.
Regards,
--
Jindrich Makovicka
the problem).
Regards,
--
Jindrich Makovicka
Vitaly Fertman wrote:
On Friday 18 March 2005 21:59, Jindrich Makovicka wrote:
Vitaly Fertman wrote:
so 1.0.3 1.0.4 bail out. Using fsck.reiser4 --build-sb from
reiser4progs 1.0.3 rendered the filesystem created under 1.0.0 unusable,
fsck.reiser4 --build-sb is supposed to fix evth. what goes
Closing fs...done
NO REISER4 METADATA WERE FOUND. FS RECOVERY IS NOT POSSIBLE.
8--- snip
--
Jindrich Makovicka
, and subsequent fsck also
botched the filesystem. Were there any fixes in 1.0.4 regarding this?
Thanks,
--
Jindrich Makovicka
10 matches
Mail list logo
