Chris Mason wrote:
Hans, decisions about proper compilers should not be made in each
individual part of the kernel. If unpatched gcc 2.96 is getting reiserfs
broke is broke. If you use reiserfs, DO NOT use 2.96. Period. Nobody gains
by letting a single user make this mistake.
wrong,
Alan Cox wrote:
So, did Linus say no? If not, let's ask him with a patch. Quite simply,
neither we nor the users should be burdened with this, and the patch removes
the burden.
Since egcs-1.1.2 and gcc 2.95 miscompile the kernel strstr code dont forget
to stop those being used as
Alan Cox wrote:
Users cannot use gcc 2.96 as shipped in RedHat 7.0 if they want to use
reiserfs. It is that simple. How can you even consider defending allowing the
use of it without requiring a positive affirmation by the user that they don't
know what they are doing and want to do
Alan Cox wrote:
As it stands, there is no way to determine programatically whether
gcc-2.96 is broken or now. The only way to do it is to check the RPM
version -- which, needless to say, is a bit difficult to do from the
C code about to be compiled. So I can't really blame Hans if he
Alan Cox wrote:
my convenience matters as much as that of the users. I don't want to use
#ifdefs, I want it to die explosively and verbosely informatively. make isn't
the most natural language for that, but I am sure Yura can find a way.
Run a small shell check and let it fail if the
Alan Cox wrote:
It makes sense to refuse to build a piece of the kernel if it break's
a machine - anything else is a timebomb waiting to explode.
The logical conclusion of that is to replace the entire kernel tree with
#error "compiler or program might have a bug. Aborting"
No, this
Alan Cox wrote:
their kernel, something putting #ifdefs all over it will mean they have to
mess around to fix too.
A moment of precision here. We won't test to see if the right compiler is used,
we will just test for the wrong one.
Ok that makes a lot more sense
Ok, so with
uot; wrote:
On 02.02 Hans Reiser wrote:
Alan Cox wrote:
Run a small shell check and let it fail if the shell stuff errors.
The fragment you want is
if [ -e /bin/rpm ]; then
X=`rpm -q gcc`
if [ "$X" = "gcc-2.96-54" ]; then
We'll test and get back to you.
Hans
Neil Brown wrote:
>
> There have been assorted reports of filesystem corruption on raid5 in
> 2.4.0, and I have finally got a patch - see below.
> I don't know if it addresses everybody's problems, but it fixed a very
> really problem that is very
We'll test and get back to you.
Hans
Neil Brown wrote:
There have been assorted reports of filesystem corruption on raid5 in
2.4.0, and I have finally got a patch - see below.
I don't know if it addresses everybody's problems, but it fixed a very
really problem that is very reproducable.
Edward wrote:
>
> Reiserfs in linux-2.4.1-pre8 does not properly with the RAID5 code that
> is in that kernel. It is easy to get corrupted filesystem on device in
> less than 1 minute. Please, do not use it (reiserfs) on RAID5 devices.
> We are trying to figure out what is wrong.
>
> Edward
Edward wrote:
Reiserfs in linux-2.4.1-pre8 does not properly with the RAID5 code that
is in that kernel. It is easy to get corrupted filesystem on device in
less than 1 minute. Please, do not use it (reiserfs) on RAID5 devices.
We are trying to figure out what is wrong.
Edward
There is
Chris Mason wrote:
>
> On Wednesday, January 10, 2001 02:32:09 AM +0100 Marc Lehmann <[EMAIL PROTECTED]> wrote:
> >>> EIP; c013f911<=
> > Trace; c013f706
> > Trace; c0136e01
> >
>
> Here is a patch against our 2.4 code (3.6.25) that does the
> same as the patch posted for 3.5.29:
>
>
Chris Mason wrote:
On Wednesday, January 10, 2001 02:32:09 AM +0100 Marc Lehmann [EMAIL PROTECTED] wrote:
EIP; c013f911 filldir+20b/221 =
Trace; c013f706 filldir+0/221
Trace; c0136e01 reiserfs_getblk+2a/16d
Here is a patch against our 2.4 code (3.6.25) that does the
same as
Thanks for the bug report, we'll investigate.
Hans
Tigran Aivazian wrote:
>
> Hi Hans,
>
> Simply starting the validation phase of SPEC SFS with NFS mounted reiserfs
> filesystem panics as shown in the log below. A quick look at the source
> suggests that _get_block_create_0() (and therefore,
Thanks for the bug report, we'll investigate.
Hans
Tigran Aivazian wrote:
Hi Hans,
Simply starting the validation phase of SPEC SFS with NFS mounted reiserfs
filesystem panics as shown in the log below. A quick look at the source
suggests that _get_block_create_0() (and therefore, more
We'll try to reproduce this when the guys get in for work this morning, thanks for the
bug report.
Elena, add symlink testing to mongo.sh so that it gets tested by our regression tests.
Hans
Andy Robinson wrote:
>
> Hi,
>
> I tried the linux-2.4.0-test9-resiserfs-3.6.18-patch on both
We'll try to reproduce this when the guys get in for work this morning, thanks for the
bug report.
Elena, add symlink testing to mongo.sh so that it gets tested by our regression tests.
Hans
Andy Robinson wrote:
Hi,
I tried the linux-2.4.0-test9-resiserfs-3.6.18-patch on both
Ragnar Kjørstad wrote:
>
> On Fri, Sep 22, 2000 at 03:23:26PM -0700, Hans Reiser wrote:
> > I think Xuan's algorithm is good, so I want to add to it.:-)
> >
> > Ragnar, I don't understand your objection to it. It is always the
> > case that if you spe
Ragnar Kjørstad wrote:
On Fri, Sep 22, 2000 at 03:23:26PM -0700, Hans Reiser wrote:
I think Xuan's algorithm is good, so I want to add to it.:-)
Ragnar, I don't understand your objection to it. It is always the
case that if you specify real
time constraints that are impossible
I think Xuan's algorithm is good, so I want to add to it.:-)
Ragnar, I don't understand your objection to it. It is always the case that if you
specify real
time constraints that are impossible then they aren't met.
If you want to get fancy you could sort all expired time limit requests by
I think Xuan's algorithm is good, so I want to add to it.:-)
Ragnar, I don't understand your objection to it. It is always the case that if you
specify real
time constraints that are impossible then they aren't met.
If you want to get fancy you could sort all expired time limit requests by
Ragnar Kjørstad wrote:
>
> On Wed, Sep 13, 2000 at 11:22:16AM -0400, Michael T. Babcock wrote:
> > If I may ask a potentially stupid question, how can request latency be
> > anything but a factor of time? Latency is how /long/ you (or the computer)
> > /waits/ for something. That defines it as
Ragnar Kjørstad wrote:
On Wed, Sep 13, 2000 at 11:22:16AM -0400, Michael T. Babcock wrote:
If I may ask a potentially stupid question, how can request latency be
anything but a factor of time? Latency is how /long/ you (or the computer)
/waits/ for something. That defines it as a
If I understand your elevator algorithm, you switch between two queues, filling one
queue while
removing from another queue.
If you modify this to only be invoked when starvation of is detected, that is, to only
prevent
filling the removing queue when the oldest unsatisfied request exceeds
"Jeff V. Merkey" wrote:
>
> One important point on remirroring I did not mention in my post. In
> NetWare, remirroring scans the disk BACKWARDS (n0) to prevent
> artificial starvation while remirring is going on. This was another
> optimization we learned the hard way by trying numerous
If I understand your elevator algorithm, you switch between two queues, filling one
queue while
removing from another queue.
If you modify this to only be invoked when starvation of is detected, that is, to only
prevent
filling the removing queue when the oldest unsatisfied request exceeds
"Jeff V. Merkey" wrote:
One important point on remirroring I did not mention in my post. In
NetWare, remirroring scans the disk BACKWARDS (n0) to prevent
artificial starvation while remirring is going on. This was another
optimization we learned the hard way by trying numerous
I really think Rik has it right here. In particular, an MP3 player needs to be able
to say, I have
X milliseconds of buffer so make my worst case latency X milliseconds. The number of
requests is
the wrong metric, because the time required per request depends on disk geometry, disk
caching,
I really think Rik has it right here. In particular, an MP3 player needs to be able
to say, I have
X milliseconds of buffer so make my worst case latency X milliseconds. The number of
requests is
the wrong metric, because the time required per request depends on disk geometry, disk
caching,
201 - 230 of 230 matches
Mail list logo
