Hello!
On Wed, Jan 29, 2003 at 07:32:31PM +0100, Jochen Haemmerle wrote:
> So, here it comes again!
> Don't care about the warning this is the machine the errror occures!
> I hope someone understands that sh*** because I don't!!!
Ok, looks like __make_request tries to call get_request, and there
Hello!
On Wed, Jan 29, 2003 at 08:38:16PM +0300, Hans Reiser wrote:
> Well, that certainly looks like a bug in mount options parsing code.
> Edward and Oleg, please review and fix.
There is another decoded output that makes much more sence to me.
And it suggest something gone wrong within bloc
Where does process hang this time? (press SysRQ-T, decode the output and
send it to me) >
could you please tell me what is SysRQ-T? btw its a remote machine...
cheers,
greg
ps: well you say that its maybe a crypto-loop side problem, what I dont
understand why it only came after 2.4.20-preX i
On Wednesday 29 January 2003 22:31, Francois-Rene Rideau wrote:
> OK. So I built the latest reiserfsck as a static binary,
> and ran it with --rebuild-tree, and I got an infinite loop
> just like previously. In case anyone cares, I have kept the logfile for it.
> Is there anything that interests yo
Am Mittwoch, 29. Januar 2003 21:09 schrieb [EMAIL PROTECTED]:
> On Wed, 29 Jan 2003 20:43:38 +0100, Dieter =?iso-8859-1?q?N=FCtzel?= said:
> > All low latency and pre-emption tests have showed _improved_ throughput
> > (Yes)
> >
> > and much better "multi media" (video/audio) "experience" ;-)
> > N
On Wed, 29 Jan 2003 20:43:38 +0100, Dieter =?iso-8859-1?q?N=FCtzel?= said:
> All low latency and pre-emption tests have showed _improved_ throughput (Yes)
> and much better "multi media" (video/audio) "experience" ;-)
> No measurable overhead an single and SMP systems (both Athlon).
> That's why
Am Mittwoch, 29. Januar 2003 19:16 schrieb [EMAIL PROTECTED]:
> On Wed, 29 Jan 2003 15:20:26 EST, James Thompson
<[EMAIL PROTECTED]> said:
> > ... I have done much research in the field of computer /hardware/
> > suitable for commercial Digital Content Creation (P4 Xeon; Wildcat
> > graphics; ART
Am Mittwoch, 29. Januar 2003 16:58 schrieb Sam Vilain:
> Reiserfs is probably not what you want for doing lots of high volume data.
> Reiserfs is good with many small files and general purpose use. It is
> actually the slowest filesystem for bulk data.
To general ;-)
> I'm sure some smartass wil
OK. So I built the latest reiserfsck as a static binary,
and ran it with --rebuild-tree, and I got an infinite loop
just like previously. In case anyone cares, I have kept the logfile for it.
Is there anything that interests you about that failure,
or should I promptly reformat the disk?
Also, doe
Tue, Jan 28, 2003 at 10:14:11AM +0100, Szabolcs Szasz wrote:
> > You're using Ximian Evolution:
> > View -> MessageDisplay -> ShowFullHeaders
>
> Few people ever see those headers. Having
> full headers on is not a realistic assumption,
> ESPECIALLY NOT for those (mostly beginners),
> who have
Am Mittwoch, 29. Januar 2003 16:28 schrieb Ross Vandegrift:
> On Wed, Jan 29, 2003 at 03:20:26PM -0500, James Thompson wrote:
> > I am a visual artist and musician.
>
> Check out the document at
> http://myweb.cableone.net/eviltwin69/ALSA_JACK_ARDOUR.html. There a
> section that benchmarks various
So, here it comes again!
Don't care about the warning this is the machine the errror occures!
I hope someone understands that sh*** because I don't!!!
Yesterday I've patched my Kernel to 2.4.21-pre3. The "bug" does not appear!
It seems to be only a "bug" of the 2.4.20 (on 2.4.19 it works too...as
On Wed, 29 Jan 2003 15:20:26 EST, James Thompson <[EMAIL PROTECTED]>
said:
> ... I have done much research in the field of computer /hardware/
> suitable for commercial Digital Content Creation (P4 Xeon; Wildcat
> graphics; ART's "PURE" raytracing PCI render board, etc. ...) and now
Hmm.. so
Well, that certainly looks like a bug in mount options parsing code.
Edward and Oleg, please review and fix.
Hans
Manuel Krause wrote:
Hi!
Just forwarding... the ksymoopsed version. Please, send any hints and
solutions or other comments to Jochens address <[EMAIL PROTECTED]> .
Manuel
Reiserfs is probably not what you want for doing lots of high volume data.
Reiserfs is good with many small files and general purpose use. It is
actually the slowest filesystem for bulk data.
I'm sure some smartass will probably post some benchmark to prove me wrong,
but SGI have a long herit
> On Wed, Jan 29, 2003 at 03:20:26PM -0500, James Thompson wrote:
>> I am a visual artist and musician.
> Check out the document at
> http://myweb.cableone.net/eviltwin69/ALSA_JACK_ARDOUR.html. There a
> section that benchmarks various filesystems for their latency. The
> short story is that Rei
On Wed, Jan 29, 2003 at 03:20:26PM -0500, James Thompson wrote:
> I am a visual artist and musician.
Check out the document at
http://myweb.cableone.net/eviltwin69/ALSA_JACK_ARDOUR.html. There a
section that benchmarks various filesystems for their latency. The
short story is that Reiserfs wins
Dear Sirs,
I am a visual artist and musician. As well as a range of traditional
media I use Linux Mandrake 8.0 on an old Athlon-based PC. I wrote to
Mr. Hans Reiser, after following a mailto link on the Namesys website,
with a slightly lengthier version of the question written below, and was
Oleg Drokin wrote:
Hello!
On Mon, Jan 27, 2003 at 02:20:47AM -0500, Scott R. Every wrote:
this URL works better:
ftp://ftp.suse.com/pub/people/mason/patches/data-logging
Oleg, thanks so much for this info(and Chris, thanks for the patches).
This is much needed for embedded filesystems of 128
Zygo Blaxell wrote:
In article <[EMAIL PROTECTED]>,
Niek <[EMAIL PROTECTED]> wrote:
Title: IBM DTLA 307045 Hard disk crash
I bought this disk (46 GB) about two years ago. One of the best they
claimed.
[...]
What is the fucking MBTF of these drives?? Is it close to one year like I
expe
20 matches
Mail list logo
