Am Dienstag, 22. November 2005 01:52 schrieb Ryan Nordman:
Hi Hans,
Allow me to introduce myself, I'm one of Peter (aka pvh)'s colleagues here
at the University of Victoria. A while back we mentioned we'd write a
practical install guide for Reiser4 with Ubuntu 5.10. Well, here it is. Let
us
Am Donnerstag, 17. November 2005 14:47 schrieb Hesse, Christian:
Vladimir V. Saveliev wrote:
Please try whether the attached patch improves anything. It simplifies
fsync by avoid commiting of transactions which do not modify file being
fsync-ed.
Did you ever think about, that this is not a
Marcel Hilzinger wrote (ao):
Did you ever think about, that this is not a reiser4 problem, but a
kernel bug or a problem related to hal?
Suse 10 has big problems with external USB drives using sync as mount
option. They used sync already in 9.3 but with 2.6.11 there were no
such problems.
Am Dienstag, 22. November 2005 11:38 schrieb Sander:
Marcel Hilzinger wrote (ao):
Did you ever think about, that this is not a reiser4 problem, but a
kernel bug or a problem related to hal?
Suse 10 has big problems with external USB drives using sync as mount
option. They used sync
On 2005-11-22 11:23, Marcel Hilzinger wrote:
Did you ever think about, that this is not a reiser4 problem, but a kernel
bug
or a problem related to hal?
Just to mention again:
I do not see the problem on my Laptop. I use a the clean vanilla-2.6.14.2
kernel manually patched with
Ingo Bormuth wrote:
On 2005-11-22 11:23, Marcel Hilzinger wrote:
Did you ever think about, that this is not a reiser4 problem, but a kernel bug
or a problem related to hal?
Just to mention again:
I do not see the problem on my Laptop. I use a the clean vanilla-2.6.14.2
kernel manually
Marcel Hilzinger wrote:
Am Dienstag, 22. November 2005 11:38 schrieb Sander:
Marcel Hilzinger wrote (ao):
Did you ever think about, that this is not a reiser4 problem, but a
kernel bug or a problem related to hal?
Suse 10 has big problems with external USB drives using sync as mount
option.
Am Dienstag, 22. November 2005 15:29 schrieb David Masover:
Marcel Hilzinger wrote:
[...]
It's not about Debian or Suse. It's about kernel 2.6.13 or 2.6.14. At
least it seems, that the problem does not appear on older kernels
(right?)
Wrong.
You are talking about the fsync issue, right?
Marcel Hilzinger wrote (ao):
Am Dienstag, 22. November 2005 11:38 schrieb Sander:
Marcel Hilzinger wrote (ao):
Did you ever think about, that this is not a reiser4 problem, but a
kernel bug or a problem related to hal?
Suse 10 has big problems with external USB drives using sync as
Sander wrote:
E.Gryaznova wrote (ao):
Unfortunately we are not able to reproduce this slowdown. Would you
please provide more info?:
FWIW, I notice the same (I'm not the OP). My main workstation (Athlon)
runs 2.6.15-rc1-mm1. Vim needs 4 to 12 seconds to close any file, mutt
is very
Hello all,
I've recently received a bad block notice from SMARTD and I'm trying to
track down which files might be affected. I *think* I have the basic
process correct but I'm missing the final step -- how to get the inode
of the affected files. My skill with Google and man pages got me to
Hi!
Unfortunately I can't help you with the debugreiserfs output but maybe
with another approach for finding the correct blocknum of the bad
sector(s). Why don't you try
badblocks -b 4096 /dev/hda5
I'm not telling that your approach is wrong but this way (assuming your
reiserfs block is the
Marcel Hilzinger wrote:
Am Dienstag, 22. November 2005 15:29 schrieb David Masover:
Marcel Hilzinger wrote:
[...]
It's not about Debian or Suse. It's about kernel 2.6.13 or 2.6.14. At
least it seems, that the problem does not appear on older kernels
(right?)
Wrong.
You are talking about
On 11/22/05, E.Gryaznova [EMAIL PROTECTED] wrote:
Sander wrote:
E.Gryaznova wrote (ao):
Something like
for i in cfq noop anticipatory deadline
do
echo $i /sys/block/hda/queue/scheduler cat
/sys/block/hda/queue/scheduler echo foo /root/test time vim +s/
foo/bar/ +wq /root/test
done
michael chang wrote:
On 11/21/05, Hans Reiser [EMAIL PROTECTED] wrote:
Vitaly Fertman wrote:
On Monday 21 November 2005 10:09, Hans Reiser wrote:
Philippe GramoullИ wrote:
Hello,
On Sun, 20 Nov 2005 05:07:23 +0100
rvalles [EMAIL PROTECTED] wrote:
| When I run make install on
On Tue, 22 Nov 2005 13:33:44 -0600, David Masover [EMAIL PROTECTED] said:
michael chang wrote:
or to actually put package building scripts for package-handling
distros in the source package (or use something like checkinstall,
provided it doesn't conflict too bad). [You can also did what
Konstantin Münning wrote:
Hi!
Unfortunately I can't help you with the debugreiserfs output but maybe
with another approach for finding the correct blocknum of the bad
sector(s). Why don't you try
badblocks -b 4096 /dev/hda5
Interesting. When reading the badblocks man page I originally
Evolution may need tweaking also, but reiser4's fsync clearly needs work.
On 11/22/05, Jake Maciejewski [EMAIL PROTECTED] wrote:
On Mon, 2005-11-21 at 16:52 -0800, Ryan Nordman wrote:
Hi Hans,
Allow me to introduce myself, I'm one of Peter (aka pvh)'s colleagues
here at the University of Victoria. A while back we mentioned we'd
write a practical install
Hi,
The slow sync problems still exist with fresh vanilla kernel patched
with Reiser4 only (reiser4-for-2.6.14-1.patch). The slow sync occurs
regardless of which IO scheduler is in use.
[EMAIL PROTECTED]:~$ uname -a
Linux teratron.lan.etheus.net 2.6.14.2 #2 PREEMPT Tue Nov 22 23:48:39
GMT 2005
Here are the results after testing on 2.6.12.1 which is not affected by the
sync problem.
Notice how sync b1 and c1 are now hardly affected by the recursive ls.
sync a1
real0m0.072s
user0m0.001s
sys 0m0.002s
sync a2
real0m0.012s
user0m0.000s
sys 0m0.001s
sync a3
VVPAXCL
IArmaIe
ALobnAv
GIziaLi
RUaexIt
AMcnSra
3,351,203,70http://www.carbinelw.hejoinehe.com
E.Gryaznova wrote (ao):
Sander wrote:
# echo foo /boot/test
# time vim +s/foo/bar/ +wq /boot/test
real0m0.016s
user0m0.000s
sys 0m0.000s
# echo foo /root/test
# time vim +s/foo/bar/ +wq /root/test
real0m9.667s
user0m0.000s
sys 0m0.020s
/dev/hda2 on / type
23 matches
Mail list logo
