* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-18 17:22 ` michael chang
@ 2005-09-18 19:16 ` Valdis.Kletnieks
2005-09-18 20:04 ` Horst von Brand
` (2 subsequent siblings)
3 siblings, 0 replies; 143+ messages in thread
From: Valdis.Kletnieks @ 2005-09-18 19:16 UTC (permalink / raw)
To: thenewme91
Cc: Christoph Hellwig, Denis Vlasenko, chriswhite, Hans Reiser, LKML,
ReiserFS List
[-- Attachment #1: Type: text/plain, Size: 896 bytes --]
On Sun, 18 Sep 2005 13:22:27 EDT, michael chang said:
> Give Hans a chance; and please try to understand, even if he's hard to
> work with. Discriminate him because he's not a developer you can talk
> with, and I believe that's like discriminating a guy in a wheelchair
> because he can't run with you when you jog in the morning.
There's nothing wrong with discriminating against the guy in the wheelchair
under some circumstances - for instance, when your track team needs a new
high jumper.
Similarly, when the goal is to build a set of developers that can actually
get work accomplished, poor interpersonal communication skills can be a
major problem.
If the problem is that Hans and the rest of the kernel developers don't get
along, perhaps the most expedient thing would be for Hans to step out of the
way and have somebody else from Namesys (or elsewhere even) act as the interface.
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-18 17:22 ` michael chang
2005-09-18 19:16 ` Valdis.Kletnieks
@ 2005-09-18 20:04 ` Horst von Brand
2005-09-18 20:29 ` David Masover
` (2 more replies)
2005-09-18 20:52 ` Kyle Moffett
2005-09-18 21:38 ` Alan Cox
3 siblings, 3 replies; 143+ messages in thread
From: Horst von Brand @ 2005-09-18 20:04 UTC (permalink / raw)
To: thenewme91
Cc: Christoph Hellwig, Denis Vlasenko, chriswhite, Hans Reiser, LKML,
ReiserFS List
michael chang <thenewme91@gmail.com> wrote:
> On 9/18/05, Christoph Hellwig <hch@infradead.org> wrote:
> > On Sun, Sep 18, 2005 at 01:21:23PM +0300, Denis Vlasenko wrote:
> > > This is it. I do not say "accept reiser4 NOW", I am saying "give Hans
> > > good code review".
> > After he did his basic homework. Note that reviewing hans code is probably
> > at the very end of everyones todo list because every critizm of his code
> > starts a huge flamewar where hans tries to attack everyone not on his
> > party line personally.
> > I've said I'm gonna do a proper review after he has done the basic
> > homework, which he seems to have half-done now at least. Right now he
> > hasn't finished
> Explain to us all what is this "basic homework" of which you speak.
The required cleanups have been posted (in outline at least), several
times, by unrelated people.
> > that and there's much more exciting filesystems like ocfs2 around that
> This is exciting to... whom?
To Cristoph, obviously. You should thank him for doing the (hard, boring,
thankless) work of reviewing code for free. Even if it isn't yours. As he
is doing it as community service, I wouldn't dare blame him for picking
whatever he likes most, for whatever reasons.
> The only thing that appears remotely
> interesting about it is that it's made by Oracle and apparently is
> supposed to be geared toward parallel server whatsits. This might be
> helpful to corporations, but seems senseless toward many consumers.
Cristoph finds it interesting, that should be enough for everybody not
paying him for doing the work.
> (I'm assuming there's still at least one consumer left who still uses
> Linux.)
Count me in. That doesn't mean I agree with ReiserFS' goals...
> > are much easier to read and actually have developers that you can have
> > a reasonable conversation with. (and that unlike hans actually try to
> Is that Hans' fault, or the fault of your lot? Why can't we all just get
> along?
Hans is one person, and he has managed to alienate a most of the LKML
bunch. Sure, there are very abrasive people here, but there are plenty that
are extremely helpful to newbies that /really/ want to learn how to do
things right.
> Give Hans a chance; and please try to understand, even if he's hard to
> work with. Discriminate him because he's not a developer you can talk
> with, and I believe that's like discriminating a guy in a wheelchair
> because he can't run with you when you jog in the morning.
Please consider that most people here are volunteers, they owe nobody
nothing. Quite the contrary: if somebody wants to unload their code (and
its future maintenance) on the kernel crew, they are in /great/ debt if it
gets accepted.
> > improve core code where it makes sense for them)
> Not everyone has the same "common sense" that you do. Explain, fully,
> with reasoning, and reproducable back-up statistics on common hardware,
> what code is wrong, and what must be written instead. We'd like to be
> efficient, and it's not being efficient to play a guessing game with us.
> If you don't have the time to review, then please hold off on replying
> until you have a through review of at least part of the code.
Can't do. It is mostly an artistic sense of taste.
> Unless you object fully to one particular, fixable thing that isn't the
> core of Reiser4, it'd be nice for you to wait on replying -- vagueness is
> not helpful to development in any way. Are we supposed to be the million
> monkeys randomly typing on a million typewriters waiting for someone to
> give you code that you like, one in a million years?
You are the ones that want to benefit from having your code in the kernel.
You evaluate if the (standard!) cycle of "Code, propose, get rejected, fix,
repropose, ... until finally accepted" works for you or just isn't worth
the bother.
> Also, let's say that Reiser4 doesn't get into the kernel, as maybe XFS
> or ext2 or ext3 had never gotten into the kernel. How would their
> development be now as opposed to how we see it, when they have gotten
> into the kernel? I don't see anything wrong with the idea of letting
> what seems a mostly mature FS into the kernel; that is how most bugs
> are found in the first place. Of course, there is nothing wrong with
> putting huge warnings on the FS; I'd recommend them, considering that
> some people are having funky problems with the patch.
Just unloading some untested code on unsuspecting, innocent users is not
very nice, is it?
> I'm willing to go compare Reiser4 to ext2/3 as like H.264 to Mpeg-2.
> Indeed, H.264 crashes some computers, similar to Reiser4 might crash
> some machines, but this is merely because Reiser4 explores new
> concepts, meaning it may require hardyier hardware than ext2/3, as
> H.264 requries hardier hardware than Mpeg-2.
Either one crashing the machine is unacceptable (in principle at least). A
filesystem is so central to "everything is a file" that filesystem problems
are doubly unacceptable. There are lots of reports of ReiserFS 3
filesystems completely destroyed by minor hardware flakiness. And that has
/never/ been fixed, as the developers just went off to do the "next cool
thing". That history weighs against ReiserFS, heavily.
> I believe that the
> concept is the same. (And all the same, media companies are embracing
> H.264 - why can't you guys embrace this new idea also?) Change is
> hard. Besides, if Reiser4 is truely that flawed, we will see in a few
> releases, and then afterwards if it's proven to everyone that Reiser4
> is completely unrepairable and hopeless, it can then be ditched and
> thrown into the trash.
It is cheaper for everybody involved to throw it in the thrash /before/
lots of people are dependent on it, and throw it out then. Just consider
the pain caused by including (and now ditching) devfs.
> My apologies for my rudeness, but I am rather fond of the developments
> in Reiser4, and would love to see it in the kernel. I am fond of
> Linux too, and the work that you guys do, and it would dissapoint me
> sorrily if Reiser4 never makes it into the Linux kernel. Feel free to
> say I'm a tad biased; I will say now that I probably have much less
> merit in the field than you guys do.
All this has been discussed in BIGNUM flamewars already, neither your nor
my post helps a bit in either way (except in fanning the flames), so please
let's drop this.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-18 20:04 ` Horst von Brand
@ 2005-09-18 20:29 ` David Masover
2005-09-18 21:43 ` Dan Oglesby
2005-09-18 20:33 ` Marc Perkel
2005-09-19 5:44 ` Hans Reiser
2 siblings, 1 reply; 143+ messages in thread
From: David Masover @ 2005-09-18 20:29 UTC (permalink / raw)
To: Horst von Brand
Cc: thenewme91, Christoph Hellwig, Denis Vlasenko, chriswhite,
Hans Reiser, LKML, ReiserFS List
Horst von Brand wrote:
> There are lots of reports of ReiserFS 3
> filesystems completely destroyed by minor hardware flakiness.
Honestly, this is one of the things I like about Linux. If I have
memory errors, Windows will just keep running, occasionally something
will crash, you restart it, never suspecting just how corrupt things are
getting under the hood. On Linux, I generally get kernel panics pretty
quickly, so I run memtest86 and replace the RAM.
If my hardware is flaky, I consider it my job to replace it, not the job
of all my software to magically compensate for it. If I lose data, oh
well, I have backups. If I didn't, I was asking for trouble anyway.
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-18 20:29 ` David Masover
@ 2005-09-18 21:43 ` Dan Oglesby
2005-09-19 1:37 ` PFC
0 siblings, 1 reply; 143+ messages in thread
From: Dan Oglesby @ 2005-09-18 21:43 UTC (permalink / raw)
To: David Masover
Cc: Horst von Brand, thenewme91, Christoph Hellwig, Denis Vlasenko,
chriswhite, Hans Reiser, LKML, ReiserFS List
David Masover wrote:
> Horst von Brand wrote:
>
>> There are lots of reports of ReiserFS 3
>> filesystems completely destroyed by minor hardware flakiness.
>
>
> Honestly, this is one of the things I like about Linux. If I have
> memory errors, Windows will just keep running, occasionally something
> will crash, you restart it, never suspecting just how corrupt things
> are getting under the hood. On Linux, I generally get kernel panics
> pretty quickly, so I run memtest86 and replace the RAM.
>
> If my hardware is flaky, I consider it my job to replace it, not the
> job of all my software to magically compensate for it. If I lose
> data, oh well, I have backups. If I didn't, I was asking for trouble
> anyway.
I'm of the same opinion. If I have hardware that has a problem, and
causes downtime, it gets replaced or repaired. I don't switch to a
different piece of software to compensate for broken hardware.
With that said, I have seen ReiserFS expose hardware that had problems.
Hardware was repaired, and ReiserFS rides again.
--Dan
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-18 21:43 ` Dan Oglesby
@ 2005-09-19 1:37 ` PFC
2005-09-19 1:53 ` Kyle Moffett
2005-09-19 4:37 ` Marc Perkel
0 siblings, 2 replies; 143+ messages in thread
From: PFC @ 2005-09-19 1:37 UTC (permalink / raw)
To: Dan Oglesby, David Masover
Cc: Horst von Brand, thenewme91, Christoph Hellwig, Denis Vlasenko,
chriswhite, Hans Reiser, LKML, ReiserFS List
> I'm of the same opinion. If I have hardware that has a problem, and
> causes downtime, it gets replaced or repaired. I don't switch to a
> different piece of software to compensate for broken hardware.
>
> With that said, I have seen ReiserFS expose hardware that had problems.
> Hardware was repaired, and ReiserFS rides again.
This summer :
Coming back from vacation, looking at the logs, I saw that the cupboard
router-server had kernel-panicked almost daily and rebooted itself
automatically. I also had a lot of corrupted BitTorrent downloads. I could
have blamed reiserfs, or bittorrent. But instead, I opened the case and
found the CPU was overheating due to the fan being clogged by an
unbelievable amount of accumulated dust and crap.
reiserfs was still happy, I ran a fsck just to be sure, no errors. fhew.
I wonder how it's possible. Given the state of the CPU fan, everything
should have been wiped out.
I have an all-reiser4 laptop (except /boot) and it's great. No problems
whatsoever, it flies. Pentium-M kicks ass.
My jukebox PC is half reiser3 and (since a few months) half reiser4,
running fine, on the cheapest possible motherboard, and the no-name RAM,
with an underclocked Duron. The hardware is so bad I had to underclock the
PC133 to PC100. It has never crashed in 4 years, or got any data
corruption. Crap hardware is actually sometimes pretty good if you
underclock it (just have to get lucky). With windows, it used to
bluescreen just by plugging a cable in the ethernet port.
My server is all reiser3 too.
I could have used other filesystems but reiserfs Just Works. No horror
stories to tell, sorry. I like reiserfs.
I don't care it there were very old versions that crashed. I don't care
about Linux 2.0 or 1 either. Or Netscape 2. That's the past now.
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-19 1:37 ` PFC
@ 2005-09-19 1:53 ` Kyle Moffett
2005-09-19 2:48 ` Dr.Dre
2005-09-19 4:37 ` Marc Perkel
1 sibling, 1 reply; 143+ messages in thread
From: Kyle Moffett @ 2005-09-19 1:53 UTC (permalink / raw)
To: PFC
Cc: Dan Oglesby, David Masover, Horst von Brand, thenewme91,
Christoph Hellwig, Denis Vlasenko, chriswhite, Hans Reiser, LKML,
ReiserFS List
Enough with the "It works for me" arguments!!! Seriously!!! Yes, we
know, it works for some people, but not for others. There are a
billion factors. If you have a technical argument, technical point,
useful detailed bug report, patch, etc to make, do so, but otherwise
SHUT UP!!!
I'm interested in doing productive code-review so we can get the
sucker into the kernel at some point (yes, it will almost certainly
happen eventually), but with all the bitching and non-technical
rhetoric going on, some of you people are really wasting a lot of our
time when we're trying to converse usefully with Hans about code-
related issues. If you don't have something _productive_ to say on
the thread, don't post!
Can we keep the Reiser4 S/N ratio at a manageable level, please?
Cheers,
Kyle Moffett
--
I lost interest in "blade servers" when I found they didn't throw
knives at people who weren't supposed to be in your machine room.
-- Anthony de Boer
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-19 1:53 ` Kyle Moffett
@ 2005-09-19 2:48 ` Dr.Dre
0 siblings, 0 replies; 143+ messages in thread
From: Dr.Dre @ 2005-09-19 2:48 UTC (permalink / raw)
To: Kyle Moffett
Cc: PFC, Dan Oglesby, David Masover, Horst von Brand, thenewme91,
Christoph Hellwig, Denis Vlasenko, chriswhite, Hans Reiser, LKML,
ReiserFS List
I have a bug report for the first time about reiser4 in 2.6.14-rc1-mm1
with 4k stacks,
preempt and smp. It is the first time I face a bug after using reiser4
for about a year. Well I had to with 4k stacks right ?
firefox has triggerred the bug twice and I had to fsck the filesystem
with --fix --build-fs which fixed the error. After fixing it any
attempt to access the drive resulted in a 'Bus error' message. A sync
and reboot using the sysreq mechanism returned me to a working system.
Sorry if this is not the place to report the bug, or if doesn't get
attatched to the reiser4 thread, I am new to LKML. Thanks in advance.
------------[ cut here ]------------
kernel BUG at <bad filename>:59883!
invalid operand: 0000 [#1]
PREEMPT SMP
last sysfs file: /class/sound/seq/dev
Modules linked in: snd_seq_instr snd_seq_midi_emul snd_seq_midi
snd_seq_midi_event snd_seq firmware_class nls_utf8 nls_cp864 vfat fat
nls_base af_packet joydev tsdev ohci_hcd ehci_hcd yealink usbhid
mousedev nvidia snd_pcm_oss snd_mixer_oss video via_rhine uhci_hcd
usbcore tpm_nsc tpm_infineon tpm_atmel tpm thermal speedstep_lib
snd_cmipci gameport snd_pcm snd_page_alloc snd_opl3_lib snd_timer
snd_hwdep snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore
shpchp pci_hotplug rtc processor loop intel_agp agpgart i2c_i801
i2c_core fan cpufreq_userspace cpufreq_stats freq_table
cpufreq_powersave cpufreq_ondemand cpufreq_conservative container
button battery
CPU: 0
EIP: 0060:[<c01d56fb>] Tainted: P VLI
EFLAGS: 00010297 (2.6.14-rc1-mm1)
EIP is at sub_from_ctx_grabbed+0x2b/0x30
eax: 00000000 ebx: 00000000 ecx: 00000001 edx: 00000000
esi: d24deec0 edi: df69e800 ebp: d50fc9e0 esp: cea25d8c
ds: 007b es: 007b ss: 0068
Process firefox-bin (pid: 10393, threadinfo=cea25000 task=de659050)
Stack: 00000001 00000000 c01d63c0 d24deec0 00000001 00000000 de202680 d50fc9e0
d50fc9e0 ce6cb8d4 c01d8594 d50fc9e0 00000001 00000000 de202680 d50fc9e0
de2026b4 c01d85e7 de202680 d50fc9e0 00000000 de202680 c01d861e de202680
Call Trace:
[<c01d63c0>] grabbed2flush_reserved_nolock+0x30/0x70
[<c01d8594>] do_jnode_make_dirty+0xf4/0x120
[<c01d85e7>] jnode_make_dirty_locked+0x27/0x40
[<c01d861e>] znode_make_dirty+0x1e/0x90
[<c01ef1b5>] update_sd_at+0xc5/0x1f0
[<c01ef32d>] update_sd+0x4d/0x70
[<c01ee5fb>] write_sd_by_inode_common+0x8b/0x90
[<c01e37c8>] reiser4_dirty_inode+0x18/0x70
[<c0180883>] __mark_inode_dirty+0xb3/0x190
[<c01784c4>] update_atime+0x54/0x80
[<c01f1aee>] read_unix_file+0x35e/0x3c0
[<c015d316>] vfs_read+0xa6/0x140
[<c015d64d>] sys_read+0x3d/0x70
[<c0102d7b>] sysenter_past_esp+0x54/0x79
Code: 56 53 8b 74 24 0c 8b 5c 24 14 8b 4c 24 10 8b 56 78 8b 46 74 39
da 76 0d 29 c8 19 da 89 46 74 89 56 78 5b 5e c3 72 04 39 c8 73 ed <0f>
0b eb e9 90 8b 4c 24 04 8b 41 74 8b 51 78 03 44 24 08 13 54
<6>note: firefox-bin[10393] exited with preempt_count 3
Please request any extra info you need.
Thanks and keep up the good work.
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-19 1:37 ` PFC
2005-09-19 1:53 ` Kyle Moffett
@ 2005-09-19 4:37 ` Marc Perkel
1 sibling, 0 replies; 143+ messages in thread
From: Marc Perkel @ 2005-09-19 4:37 UTC (permalink / raw)
Cc: LKML, ReiserFS List
PFC wrote:
>
>
>> I'm of the same opinion. If I have hardware that has a problem, and
>> causes downtime, it gets replaced or repaired. I don't switch to a
>> different piece of software to compensate for broken hardware.
>>
>> With that said, I have seen ReiserFS expose hardware that had
>> problems. Hardware was repaired, and ReiserFS rides again.
>
>
>
Agreed - if the hardware has problem and anything is readable I'm happy.
When I was sysadmin at EFF we got a bunch of IBM Deathstar drives - and
for those who experiences this - every one of them fails. But they
usually fail slowly. What amazed me was I would stat to see seek errors
- sector not found and I would copy off everything I could onto a new
drive before I lost anything. And - I thought it was amazing that I
usually managed to get all the important stuff. So - I give reiser
credit for being somewhat resiliant.
here's the way I see it. This isn't like Hans Reiser is some unknown guy
who has some wild idea that we all don't know. ReiserFS is a majoy
player in the Linux world and many people like it the best. Several
distros use Reiser as their default install. So to me this gives him
more than average standing and the way I see it - there has to be a good
reason to NOT merge it rather than a reason TO merge it.
So - is Reiser4 going to break anything? If not - what is the reason to
not do it?
--
Marc Perkel - marc@perkel.com
Spam Filter: http://www.junkemailfilter.com
My Blog: http://marc.perkel.com
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-18 20:04 ` Horst von Brand
2005-09-18 20:29 ` David Masover
@ 2005-09-18 20:33 ` Marc Perkel
2005-09-19 5:44 ` Hans Reiser
2 siblings, 0 replies; 143+ messages in thread
From: Marc Perkel @ 2005-09-18 20:33 UTC (permalink / raw)
To: Horst von Brand
Cc: thenewme91, Christoph Hellwig, Denis Vlasenko, chriswhite,
Hans Reiser, LKML, ReiserFS List
For what it's worth sometimes people get emotional and frustrated and
sometimes people can be difficult at thimes to work with. But - for what
it's worth - I think people should ignore some of that as human nature
and look at the big picture.
And the big picture is ....
Hans has make a huge contribution with Reiser 3 and eventually Reiser 4
is going to be something that will greatly enhance the kernel and
advance Linux the way Reiser 3 has done. Wasn't Resiser 3 the first
journalling file system for Linux that actually worked?
So - I say - if it doesn't break anything else - why not throw it into
the mail kernel? It will get there eventually and if it's there sooner
them more people will be out there trying to break it and it will
develop faster. I don't know personally how stable it is - but from what
I understand it is winning the speed tests and that will shave some time
off of everything the rest of us do. And even if it is somewhat broken -
in a few months it will all be fixed.
And Hans is apparently ready to take abuse if it's broken.
So I say - lets do it already.
My 2 centz ....
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-18 20:04 ` Horst von Brand
2005-09-18 20:29 ` David Masover
2005-09-18 20:33 ` Marc Perkel
@ 2005-09-19 5:44 ` Hans Reiser
2005-09-19 10:39 ` Nikita Danilov
` (3 more replies)
2 siblings, 4 replies; 143+ messages in thread
From: Hans Reiser @ 2005-09-19 5:44 UTC (permalink / raw)
To: Horst von Brand
Cc: thenewme91, Christoph Hellwig, Denis Vlasenko, chriswhite, LKML,
ReiserFS List
Horst von Brand wrote:
>
>>>that and there's much more exciting filesystems like ocfs2 around that
>>>
>>>
>
>
>
>>This is exciting to... whom?
>>
>>
>
>To Cristoph, obviously. You should thank him for doing the (hard, boring,
>thankless) work of reviewing code for free. Even if it isn't yours. As he
>is doing it as community service, I wouldn't dare blame him for picking
>whatever he likes most, for whatever reasons.
>
>
Well maybe he should just go away then and save his and our time.
Reiser4 works just fine without Christoph. Users are happy with it.
None of them have asked for his help. I don't consider Christoph to be
qualified to work on our filesystem. I would not hire him if he applied
--- he is not capable of innovative work.
Reiser4 is far from perfect, but it is ready for more users.
>
>>Is that Hans' fault, or the fault of your lot? Why can't we all just get
>>along?
>>
>>
>
>Hans is one person, and he has managed to alienate a most of the LKML
>bunch. Sure, there are very abrasive people here, but there are plenty that
>are extremely helpful to newbies that /really/ want to learn how to do
>things right.
>
>
Yes, but the helpful ones have nothing to do with VFS. Linux has lost
filesystem developers because of the VFS team, developers who I can tell
you were very very gifted DARPA researchers who decided to work on BSD
because they had too much dignity to develop a filesystem for Linux. I
assure you that no one on the VFS team is as bright or capable as one of
the fellows I know of that they abused away.
>>If you don't have the time to review, then please hold off on replying
>>until you have a through review of at least part of the code.
>>
>>
>
>Can't do. It is mostly an artistic sense of taste.
>
>
Yes, which is why people who have not written a serious filesystem
should not instruct those who have written the measurably fastest one.
> Also, let's say that Reiser4 doesn't get into the kernel, as maybe XFS
>
>>or ext2 or ext3 had never gotten into the kernel. How would their
>>development be now as opposed to how we see it, when they have gotten
>>into the kernel? I don't see anything wrong with the idea of letting
>>what seems a mostly mature FS into the kernel; that is how most bugs
>>are found in the first place. Of course, there is nothing wrong with
>>putting huge warnings on the FS; I'd recommend them, considering that
>>some people are having funky problems with the patch.
>>
>>
>
>Just unloading some untested code on unsuspecting, innocent users is not
>very nice, is it?
>
>
Christoph is not testing. We have tested, our mailing list has tested.....
> There are lots of reports of ReiserFS 3
>
>filesystems completely destroyed by minor hardware flakiness. And that has
>/never/ been fixed, as the developers just went off to do the "next cool
>thing". That history weighs against ReiserFS, heavily.
>
>
We are supposed to write a filesystem so that overheating CPUs do not
make it crash?
Prejudice is a very simple phenomenom. When either ext3 or ReiserFS V3
crash it is almost always due to bad hardware. Prejudice is the process
of remembering that one filesystem crashed due to bad hardware and not
remembering that the other one crashed.
It is remarkably simple how it works: people who use Reiser4 want it in,
people who use ext3 and don't want to have a choice of something else
don't want it in. That was true of V3, and it is true of V4. My point
of course is that those who have used V4 know more about it than those
who haven't......
I think Alan Cox is the only poster who has no intention of using
Reiser4 but said at one point that he thinks it should go in.
V3 is obsoleted by V4 in every way. V3 is old code that should be
marked as deprecated as soon as V4 has passed mass testing. V4 is far
superior in its coding style also. Having V3 in and V4 out is at this
point just stupid.
This whole thing reminds me of an IBMer who told me that he thought that
IBM lost to MS because they called OS/2 by a name other than DOS. The
sad thing is he was probably right.
V4, as it is today, is as much superior to V3 as OS/2 was to DOS. Any
distro or user who would stay with V3 for new installs once we have
passed mass testing is nuts. We need the mass testing.
Hans
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-19 5:44 ` Hans Reiser
@ 2005-09-19 10:39 ` Nikita Danilov
2005-09-19 18:51 ` Hans Reiser
2005-09-19 10:51 ` Alan Cox
` (2 subsequent siblings)
3 siblings, 1 reply; 143+ messages in thread
From: Nikita Danilov @ 2005-09-19 10:39 UTC (permalink / raw)
To: Hans Reiser
Cc: thenewme91, Christoph Hellwig, Denis Vlasenko, chriswhite, LKML,
ReiserFS List
Hans Reiser writes:
[...]
> Well maybe he should just go away then and save his and our time.
> Reiser4 works just fine without Christoph. Users are happy with it.
> None of them have asked for his help. I don't consider Christoph to be
> qualified to work on our filesystem. I would not hire him if he applied
> --- he is not capable of innovative work.
Hans, it seems you misunderstand what is going on.
Necessary prerequisite for reiser4 inclusion is a review by file system
people. Christoph is doing this _work_. You know what it is to review
somebody else code? It's a hard work. He is doing it for free.
If he goes away---reiser4 wouldn't somehow magically be immediately
included into kernel. It'll wait for review---for the next person to
come and to do this work. And that person will most likely point to the
very same things that hch does now only after a delay. Maybe with
slightly more polished style (hair style included) though. :-)
So, please be a little more patient.
>
> Reiser4 is far from perfect, but it is ready for more users.
This is not what is being discussed, stop red-herring, please.
[...]
> >
> Yes, which is why people who have not written a serious filesystem
> should not instruct those who have written the measurably fastest one.
Somebody has to review reiser4 code. If you can persuade somebody else
to do the review, do this.
[...]
>
> V4, as it is today, is as much superior to V3 as OS/2 was to DOS. Any
One way in which half-OS was superior to DOS was how spectacularly the
former project failed after a lot of hype. :-)
> distro or user who would stay with V3 for new installs once we have
> passed mass testing is nuts. We need the mass testing.
>
> Hans
>
Nikita.
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-19 10:39 ` Nikita Danilov
@ 2005-09-19 18:51 ` Hans Reiser
0 siblings, 0 replies; 143+ messages in thread
From: Hans Reiser @ 2005-09-19 18:51 UTC (permalink / raw)
To: Nikita Danilov
Cc: thenewme91, Christoph Hellwig, Denis Vlasenko, chriswhite, LKML,
ReiserFS List
>One way in which half-OS was superior to DOS was how spectacularly the
>former project failed after a lot of hype. :-)
>
>
OS/2 was technically superior to windows 95. The only failure was the
marketing/herd movement issues. I used OS/2, it was better.
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-19 5:44 ` Hans Reiser
2005-09-19 10:39 ` Nikita Danilov
@ 2005-09-19 10:51 ` Alan Cox
2005-09-19 23:03 ` Horst von Brand
2005-09-20 7:51 ` Pavel Machek
3 siblings, 0 replies; 143+ messages in thread
From: Alan Cox @ 2005-09-19 10:51 UTC (permalink / raw)
To: Hans Reiser
Cc: Horst von Brand, thenewme91, Christoph Hellwig, Denis Vlasenko,
chriswhite, LKML, ReiserFS List
On Sul, 2005-09-18 at 22:44 -0700, Hans Reiser wrote:
> We are supposed to write a filesystem so that overheating CPUs do not
> make it crash?
The reverse - and before you lose data.
> I think Alan Cox is the only poster who has no intention of using
> Reiser4 but said at one point that he thinks it should go in.
If its clean enough then yes, like any other fs. Until then no.
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-19 5:44 ` Hans Reiser
2005-09-19 10:39 ` Nikita Danilov
2005-09-19 10:51 ` Alan Cox
@ 2005-09-19 23:03 ` Horst von Brand
2005-09-20 8:00 ` Hans Reiser
2005-09-20 7:51 ` Pavel Machek
3 siblings, 1 reply; 143+ messages in thread
From: Horst von Brand @ 2005-09-19 23:03 UTC (permalink / raw)
To: Hans Reiser
Cc: Horst von Brand, thenewme91, Christoph Hellwig, Denis Vlasenko,
chriswhite, LKML, ReiserFS List
Hans Reiser <reiser@namesys.com> wrote:
> Horst von Brand wrote:
> >>>that and there's much more exciting filesystems like ocfs2 around that
> >>This is exciting to... whom?
> >To Cristoph, obviously. You should thank him for doing the (hard, boring,
> >thankless) work of reviewing code for free. Even if it isn't yours. As he
> >is doing it as community service, I wouldn't dare blame him for picking
> >whatever he likes most, for whatever reasons.
> Well maybe he should just go away then and save his and our time.
Your choice.
> Reiser4 works just fine without Christoph. Users are happy with it.
> None of them have asked for his help. I don't consider Christoph to be
> qualified to work on our filesystem. I would not hire him if he applied
> --- he is not capable of innovative work.
How do you know?
> Reiser4 is far from perfect, but it is ready for more users.
OK.
> >>Is that Hans' fault, or the fault of your lot? Why can't we all just get
> >>along?
> >Hans is one person, and he has managed to alienate a most of the LKML
> >bunch. Sure, there are very abrasive people here, but there are plenty that
> >are extremely helpful to newbies that /really/ want to learn how to do
> >things right.
> Yes, but the helpful ones have nothing to do with VFS.
It just so happens that VFS is a central piece of Linux, and it is has been
carefully engineered over the years, for /lots/ of different filesystems. I
can understand that they don't want to change it willy-nilly.
> Linux has lost
> filesystem developers because of the VFS team, developers who I can tell
> you were very very gifted DARPA researchers
Care to give names?
> who decided to work on BSD
> because they had too much dignity to develop a filesystem for Linux.
Their loss, I presume... and you clearly think the same way, because if it
weren't you wouldn't be around here trying to push ReiserFS into Linux, and
would be bothering one of the BSDs instead.
> I
> assure you that no one on the VFS team is as bright or capable as one of
> the fellows I know of that they abused away.
Yo don't know the whole "VFS team", so...
> >>If you don't have the time to review, then please hold off on replying
> >>until you have a through review of at least part of the code.
> >Can't do. It is mostly an artistic sense of taste.
> Yes, which is why people who have not written a serious filesystem
> should not instruct those who have written the measurably fastest one.
It might be fast, but if the code is horrible, I don't want anything to do
with it. I prefer the code on which I depend reviewable, thank you very
much.
> >> Also, let's say that Reiser4 doesn't get into the kernel, as maybe XFS
> >>or ext2 or ext3 had never gotten into the kernel. How would their
> >>development be now as opposed to how we see it, when they have gotten
> >>into the kernel? I don't see anything wrong with the idea of letting
> >>what seems a mostly mature FS into the kernel; that is how most bugs
> >>are found in the first place. Of course, there is nothing wrong with
> >>putting huge warnings on the FS; I'd recommend them, considering that
> >>some people are having funky problems with the patch.
> >Just unloading some untested code on unsuspecting, innocent users is not
> >very nice, is it?
> Christoph is not testing. We have tested, our mailing list has
> tested.....
I'm not talking about Cristoph, I'm talking about unsuspecting users of
Linus' kernel (and users of distributions that will end up enabling
everything under Kconfig "just in case").
> > There are lots of reports of ReiserFS 3
> >filesystems completely destroyed by minor hardware flakiness. And that has
> >/never/ been fixed, as the developers just went off to do the "next cool
> >thing". That history weighs against ReiserFS, heavily.
> We are supposed to write a filesystem so that overheating CPUs do not
> make it crash?
No... but at least try not to get completely hosed in that case.
> Prejudice is a very simple phenomenom. When either ext3 or ReiserFS V3
> crash it is almost always due to bad hardware. Prejudice is the process
> of remembering that one filesystem crashed due to bad hardware and not
> remembering that the other one crashed.
No. Here it is starkly remembering the cases where the crash got people to
loose /all/ their data, versus at best dimly remembering cases where a file
got into lost+found and had to be restored.
> It is remarkably simple how it works: people who use Reiser4 want it in,
Fair enough.
> people who use ext3 and don't want to have a choice of something else
> don't want it in.
As a ext3 user, I could not care less for XFS, or JFS, or... What I /do/
care about is the code quality of the kernel. And people who don't want to
(or can't) work nicely with the kernel crew just will screw it up, so I'd
veto their code.
> That was true of V3, and it is true of V4. My point
> of course is that those who have used V4 know more about it than those
> who haven't......
People who work all day on the kernel and have looked at the code, and get
misdirected reports and outcries, know more about it than occassional
users...
> I think Alan Cox is the only poster who has no intention of using
> Reiser4 but said at one point that he thinks it should go in.
I too think that Linux can only win with more filesystems, as long as they
are maintainable and don't mean a burden on the core kernel crew. Note that
this means code in the style of the core kernel, and a developer community
that works well with the core crew.
> V3 is obsoleted by V4 in every way. V3 is old code that should be
> marked as deprecated as soon as V4 has passed mass testing. V4 is far
> superior in its coding style also. Having V3 in and V4 out is at this
> point just stupid.
V3 /is/ being used by many people. Just decreeing it has to be pulled out
"because V4 is better" is just irresponsible. And that is exactly the
attitude I don't like.
> This whole thing reminds me of an IBMer who told me that he thought that
> IBM lost to MS because they called OS/2 by a name other than DOS. The
> sad thing is he was probably right.
The IBMer was dead wrong, OS/2 was strangled by lack of applications.
> V4, as it is today, is as much superior to V3 as OS/2 was to DOS. Any
> distro or user who would stay with V3 for new installs once we have
> passed mass testing is nuts. We need the mass testing.
And people who have existing setups don't count? Cautious people who won't
touch a new filesystem with a ten foot pole until it has got mass testing
in a mainstream distribution for a couple of years are irrelevant?
BTW, your post (and my answer, for that matter) don't add any value to
LKML, so please stop here.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-19 23:03 ` Horst von Brand
@ 2005-09-20 8:00 ` Hans Reiser
0 siblings, 0 replies; 143+ messages in thread
From: Hans Reiser @ 2005-09-20 8:00 UTC (permalink / raw)
To: Horst von Brand
Cc: thenewme91, Christoph Hellwig, Denis Vlasenko, chriswhite, LKML,
ReiserFS List
Horst von Brand wrote:
> Care to give names?
Not publicly, no. If akpm or Linus asks, I will happily encourage
either of them to try to win him back.
>
>
>> who decided to work on BSD
>>because they had too much dignity to develop a filesystem for Linux.
>>
>>
>
>Their loss, I presume...
>
everyone's loss, it is a negative sum game.
> and you clearly think the same way, because if it
>weren't you wouldn't be around here trying to push ReiserFS into Linux, and
>would be bothering one of the BSDs instead.
>
>
I committed to Linux way back when it was obscure compared to BSD.....
and I like the way the GPL allows me to make some small amount of money
selling licenses in addition to the GPL, and the way MS can't reuse my
code for free without attribution.
>
>
>
>>V3 is obsoleted by V4 in every way. V3 is old code that should be
>>marked as deprecated as soon as V4 has passed mass testing. V4 is far
>>superior in its coding style also. Having V3 in and V4 out is at this
>>point just stupid.
>>
>>
>
>V3 /is/ being used by many people. Just decreeing it has to be pulled out
>"because V4 is better" is just irresponsible. And that is exactly the
>attitude I don't like.
>
>
I didn't say V3 should be pulled out, I said marked as deprecated. And
left alone so that it gets only bug fixes and not new features.
>
>
>>This whole thing reminds me of an IBMer who told me that he thought that
>>IBM lost to MS because they called OS/2 by a name other than DOS. The
>>sad thing is he was probably right.
>>
>>
>
>The IBMer was dead wrong, OS/2 was strangled by lack of applications.
>
>
Uh, no, it ran all the DOS applications better than DOS did. Seriously,
it did. I remember DOS applications that were easier to make work under
OS/2 due to 640k something or another. I pray the memory of exactly
what does not return to me.;-)
>
>
>>V4, as it is today, is as much superior to V3 as OS/2 was to DOS. Any
>>distro or user who would stay with V3 for new installs once we have
>>passed mass testing is nuts. We need the mass testing.
>>
>>
>
>And people who have existing setups don't count?
>
Of course they count. I don't expect any users to convert from V3 to V4
on an existing OS installation until we have a robustly working
convertfs, and even then most of them won't. Please note the phrase
"new installs", it was very intentional.
> Cautious people who won't
>touch a new filesystem with a ten foot pole until it has got mass testing
>in a mainstream distribution for a couple of years are irrelevant?
>
>
I fully expect that there will be people using V3 long past the time
when better filesystems are available and working and stable, the world
has a lot of lag time to it.;-)
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-19 5:44 ` Hans Reiser
` (2 preceding siblings ...)
2005-09-19 23:03 ` Horst von Brand
@ 2005-09-20 7:51 ` Pavel Machek
2005-09-20 14:41 ` David Masover
` (3 more replies)
3 siblings, 4 replies; 143+ messages in thread
From: Pavel Machek @ 2005-09-20 7:51 UTC (permalink / raw)
To: Hans Reiser
Cc: Horst von Brand, thenewme91, Christoph Hellwig, Denis Vlasenko,
chriswhite, LKML, ReiserFS List
Hi!
> V3 is obsoleted by V4 in every way. V3 is old code that should be
> marked as deprecated as soon as V4 has passed mass testing. V4 is far
> superior in its coding style also. Having V3 in and V4 out is at this
> point just stupid.
Really? Last time I checked, even V3's fsck was not too great. [In
fact I never could make it run stable enough to even _test_ it
properly].
Do you have working fsck for V4? Until then, you should not claim that
users should switch. Journalling does not help you, if you have
unexpected kernel problem or hardware trouble, fsck _is_ mandatory.
Can V4 survive few hours of test below?
Pavel
#!/bin/bash
#
# fscktest
#
# Usage:
# Make sure output is logged somewhere
# First, run fscktest -p as root
# Then you can run fscktest as normal user...
#
prepare() {
SIZE=100000
echo "Creating file..."
cat /dev/zero | head -c $[$SIZE*1024] > test
echo "Making filesystem..."
mkfs.$FS test
echo "Mounting..."
mount test -o loop /mnt || exit "Cant mount"
echo "Copying files..."
cp -a /bin /mnt
cp -a /usr/bin /mnt
cp -a /usr/src/linux /mnt
echo "Syncing..."
sync
echo "Unmounting..."
umount /mnt
echo "Moving..."
mv test fsck.okay
echo "All done."
}
FS=ext2
if [ .$1 == .-p ]; then
prepare
exit
fi
RUN=0
while true; do
RUN=$[$RUN+1]
echo "Run #$RUN"
echo Preparing...
cat fsck.okay > fsck.damaged
echo Damaging...
dd if=/dev/urandom of=fsck.damaged count=10240 seek=7 conv=notrunc
cp fsck.damaged fsck.test
echo First check...
fsck.$FS -fy fsck.damaged
RESULT=$?
if [ $RESULT != 1 -a $RESULT != 2 -a $RESULT != 0 ]; then
echo "Fsck failed in bad way (result = $RESULT)"
exit
fi
echo Second check...
fsck.$FS -fy fsck.damaged
RESULT=$?
if [ $RESULT != 0 ]; then
echo "Fsck lied about its success (result = $RESULT)"
exit
fi
done
--
if you have sharp zaurus hardware you don't need... you know my address
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-20 7:51 ` Pavel Machek
@ 2005-09-20 14:41 ` David Masover
2005-09-20 17:25 ` Hans Reiser
` (2 more replies)
2005-09-20 17:46 ` Hans Reiser
` (2 subsequent siblings)
3 siblings, 3 replies; 143+ messages in thread
From: David Masover @ 2005-09-20 14:41 UTC (permalink / raw)
To: Pavel Machek
Cc: Hans Reiser, Horst von Brand, thenewme91, Christoph Hellwig,
Denis Vlasenko, chriswhite, LKML, ReiserFS List
Pavel Machek wrote:
> Hi!
>
>
>>V3 is obsoleted by V4 in every way. V3 is old code that should be
>>marked as deprecated as soon as V4 has passed mass testing. V4 is far
>>superior in its coding style also. Having V3 in and V4 out is at this
>>point just stupid.
>
>
> Really? Last time I checked, even V3's fsck was not too great. [In
> fact I never could make it run stable enough to even _test_ it
> properly].
>
> Do you have working fsck for V4?
Already saved me once. But then, I should have had backups.
And personally, if it was my FS, I'd stop working on fsck after it was
able to "check". That's what it's for. To fix an FS, you wipe it and
restore from backups.
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-20 14:41 ` David Masover
@ 2005-09-20 17:25 ` Hans Reiser
2005-09-20 18:17 ` Horst von Brand
[not found] ` <20050920175727.GA17820@thunk.org>
2 siblings, 0 replies; 143+ messages in thread
From: Hans Reiser @ 2005-09-20 17:25 UTC (permalink / raw)
To: David Masover
Cc: Pavel Machek, Horst von Brand, thenewme91, Christoph Hellwig,
Denis Vlasenko, chriswhite, LKML, ReiserFS List, vitaly
David Masover wrote:
>
> And personally, if it was my FS, I'd stop working on fsck after it was
> able to "check". That's what it's for. To fix an FS, you wipe it and
> restore from backups.
>
>
Umm, this is going too far David. Our fsck should work, and we will
give his script to Vitaly to play with and comment on.
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-20 14:41 ` David Masover
2005-09-20 17:25 ` Hans Reiser
@ 2005-09-20 18:17 ` Horst von Brand
[not found] ` <20050920175727.GA17820@thunk.org>
2 siblings, 0 replies; 143+ messages in thread
From: Horst von Brand @ 2005-09-20 18:17 UTC (permalink / raw)
To: David Masover
Cc: Pavel Machek, Hans Reiser, Horst von Brand, thenewme91,
Christoph Hellwig, Denis Vlasenko, chriswhite, LKML,
ReiserFS List
David Masover <ninja@slaphack.com> wrote:
> Pavel Machek wrote:
> >>V3 is obsoleted by V4 in every way. V3 is old code that should be
> >>marked as deprecated as soon as V4 has passed mass testing. V4 is far
> >>superior in its coding style also. Having V3 in and V4 out is at this
> >> point just stupid.
> > Really? Last time I checked, even V3's fsck was not too great. [In
> > fact I never could make it run stable enough to even _test_ it
> > properly].
> > Do you have working fsck for V4?
> Already saved me once. But then, I should have had backups.
And if you haven't? Backing up 200+ GiB is no peanuts...
> And personally, if it was my FS, I'd stop working on fsck after it was
> able to "check". That's what it's for. To fix an FS, you wipe it and
> restore from backups.
Remind me /never/ to go near a filesystem you are in any way involved with.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply [flat|nested] 143+ messages in thread
[parent not found: <20050920175727.GA17820@thunk.org>]
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-20 7:51 ` Pavel Machek
2005-09-20 14:41 ` David Masover
@ 2005-09-20 17:46 ` Hans Reiser
[not found] ` <200509202328.28501.rik@osrc.info>
2005-09-21 0:04 ` Theodore Ts'o
3 siblings, 0 replies; 143+ messages in thread
From: Hans Reiser @ 2005-09-20 17:46 UTC (permalink / raw)
To: Pavel Machek
Cc: Horst von Brand, thenewme91, Christoph Hellwig, Denis Vlasenko,
chriswhite, LKML, ReiserFS List, vitaly, E. Gryaznova
Thanks much for this test script, Vitaly, please give it a try and tell
me how it goes.
Hans
Pavel Machek wrote:
>Hi!
>
>
>
>>V3 is obsoleted by V4 in every way. V3 is old code that should be
>>marked as deprecated as soon as V4 has passed mass testing. V4 is far
>>superior in its coding style also. Having V3 in and V4 out is at this
>>point just stupid.
>>
>>
>
>Really? Last time I checked, even V3's fsck was not too great. [In
>fact I never could make it run stable enough to even _test_ it
>properly].
>
>Do you have working fsck for V4? Until then, you should not claim that
>users should switch. Journalling does not help you, if you have
>unexpected kernel problem or hardware trouble, fsck _is_ mandatory.
>
>Can V4 survive few hours of test below?
> Pavel
>
>#!/bin/bash
>#
># fscktest
>#
># Usage:
># Make sure output is logged somewhere
># First, run fscktest -p as root
># Then you can run fscktest as normal user...
>#
>
>prepare() {
> SIZE=100000
> echo "Creating file..."
> cat /dev/zero | head -c $[$SIZE*1024] > test
> echo "Making filesystem..."
> mkfs.$FS test
> echo "Mounting..."
> mount test -o loop /mnt || exit "Cant mount"
> echo "Copying files..."
> cp -a /bin /mnt
> cp -a /usr/bin /mnt
> cp -a /usr/src/linux /mnt
> echo "Syncing..."
> sync
> echo "Unmounting..."
> umount /mnt
> echo "Moving..."
> mv test fsck.okay
> echo "All done."
>}
>
>FS=ext2
>if [ .$1 == .-p ]; then
> prepare
> exit
> fi
>RUN=0
>while true; do
> RUN=$[$RUN+1]
> echo "Run #$RUN"
> echo Preparing...
> cat fsck.okay > fsck.damaged
> echo Damaging...
> dd if=/dev/urandom of=fsck.damaged count=10240 seek=7 conv=notrunc
> cp fsck.damaged fsck.test
> echo First check...
> fsck.$FS -fy fsck.damaged
> RESULT=$?
> if [ $RESULT != 1 -a $RESULT != 2 -a $RESULT != 0 ]; then
> echo "Fsck failed in bad way (result = $RESULT)"
> exit
> fi
> echo Second check...
> fsck.$FS -fy fsck.damaged
> RESULT=$?
> if [ $RESULT != 0 ]; then
> echo "Fsck lied about its success (result = $RESULT)"
> exit
> fi
> done
>
>
>
^ permalink raw reply [flat|nested] 143+ messages in thread
[parent not found: <200509202328.28501.rik@osrc.info>]
* Re: I request inclusion of reiser4 in the mainline kernel
[not found] ` <200509202328.28501.rik@osrc.info>
@ 2005-09-20 20:15 ` Valdis.Kletnieks
2005-09-20 21:17 ` Theodore Ts'o
2005-09-20 21:37 ` Pavel Machek
1 sibling, 1 reply; 143+ messages in thread
From: Valdis.Kletnieks @ 2005-09-20 20:15 UTC (permalink / raw)
To: Roman I Khimov
Cc: reiserfs-list, Pavel Machek, Hans Reiser, Horst von Brand,
thenewme91, Christoph Hellwig, Denis Vlasenko, chriswhite, LKML
[-- Attachment #1: Type: text/plain, Size: 555 bytes --]
On Tue, 20 Sep 2005 23:28:12 +0400, Roman I Khimov said:
> --nextPart1692600.LIfSYN1P7A
> Maybe I'm doing something wrong here, but ext2 have failed on second check
> of first pass with
>
> Second check...
> e2fsck 1.34 (25-Jul-2003)
> Pass 1: Checking inodes, blocks, and sizes
> Pass 2: Checking directory structure
> fsck.damaged: ***** FILE SYSTEM WAS MODIFIED *****
> fsck.damaged: 1345/25064 files (1.7% non-contiguous), 94063/100000 blocks
> fsck lied about its success (result = 1)
What was the return value and output from the *first* fsck?
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-20 20:15 ` Valdis.Kletnieks
@ 2005-09-20 21:17 ` Theodore Ts'o
2005-09-20 21:33 ` Valdis.Kletnieks
0 siblings, 1 reply; 143+ messages in thread
From: Theodore Ts'o @ 2005-09-20 21:17 UTC (permalink / raw)
To: Valdis.Kletnieks
Cc: Roman I Khimov, reiserfs-list, Pavel Machek, Hans Reiser,
Horst von Brand, thenewme91, Christoph Hellwig, Denis Vlasenko,
chriswhite, LKML
On Tue, Sep 20, 2005 at 04:15:41PM -0400, Valdis.Kletnieks@vt.edu wrote:
> On Tue, 20 Sep 2005 23:28:12 +0400, Roman I Khimov said:
> > --nextPart1692600.LIfSYN1P7A
>
> > Maybe I'm doing something wrong here, but ext2 have failed on second check
> > of first pass with
> >
> > Second check...
> > e2fsck 1.34 (25-Jul-2003)
> > Pass 1: Checking inodes, blocks, and sizes
> > Pass 2: Checking directory structure
>
> > fsck.damaged: ***** FILE SYSTEM WAS MODIFIED *****
> > fsck.damaged: 1345/25064 files (1.7% non-contiguous), 94063/100000 blocks
> > fsck lied about its success (result = 1)
>From the fsck man page:
The exit code returned by fsck is the sum of the following conditions:
0 - No errors
1 - File system errors corrected
2 - System should be rebooted
4 - File system errors left uncorrected
8 - Operational error
16 - Usage or syntax error
32 - Fsck canceled by user request
128 - Shared library error
An exit code of 1 means that filesystem errors were corrected
(successfully).
This is a convention that has been around for a long time (since at
least BSD 4.x).
- Ted
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-20 21:17 ` Theodore Ts'o
@ 2005-09-20 21:33 ` Valdis.Kletnieks
0 siblings, 0 replies; 143+ messages in thread
From: Valdis.Kletnieks @ 2005-09-20 21:33 UTC (permalink / raw)
To: Theodore Ts'o
Cc: Roman I Khimov, reiserfs-list, Pavel Machek, Hans Reiser,
Horst von Brand, thenewme91, Christoph Hellwig, Denis Vlasenko,
chriswhite, LKML
[-- Attachment #1: Type: text/plain, Size: 386 bytes --]
On Tue, 20 Sep 2005 17:17:13 EDT, "Theodore Ts'o" said:
>
> An exit code of 1 means that filesystem errors were corrected
> (successfully).
Right. The problem is that this was a *second* check, after the first one
terminated with exit code 0, 1, or 2. Thus, it *should* have exited with 0.
The *first* check lied - if there were unfixed errors, it should have exited
with exit 4.
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
[not found] ` <200509202328.28501.rik@osrc.info>
2005-09-20 20:15 ` Valdis.Kletnieks
@ 2005-09-20 21:37 ` Pavel Machek
[not found] ` <200509210133.41710.rik@osrc.info>
1 sibling, 1 reply; 143+ messages in thread
From: Pavel Machek @ 2005-09-20 21:37 UTC (permalink / raw)
To: Roman I Khimov
Cc: reiserfs-list, Hans Reiser, Horst von Brand, thenewme91,
Christoph Hellwig, Denis Vlasenko, chriswhite, LKML
Hi!
> > Can V4 survive few hours of test below?
>
> Maybe I'm doing something wrong here, but ext2 have failed on second check
> of first pass with
No, you have probably just found bug in e2fsck...
> Second check...
> e2fsck 1.34 (25-Jul-2003)
I have 1.38 here, so yours is too old.
OTOH if reiser4 survives that for 80 cycles... that's pretty good.
Pavel
--
if you have sharp zaurus hardware you don't need... you know my address
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-20 7:51 ` Pavel Machek
` (2 preceding siblings ...)
[not found] ` <200509202328.28501.rik@osrc.info>
@ 2005-09-21 0:04 ` Theodore Ts'o
2005-09-21 0:13 ` Hans Reiser
` (2 more replies)
3 siblings, 3 replies; 143+ messages in thread
From: Theodore Ts'o @ 2005-09-21 0:04 UTC (permalink / raw)
To: Pavel Machek
Cc: Hans Reiser, Horst von Brand, thenewme91, Christoph Hellwig,
Denis Vlasenko, chriswhite, LKML, ReiserFS List
On Tue, Sep 20, 2005 at 09:51:33AM +0200, Pavel Machek wrote:
> Do you have working fsck for V4? Until then, you should not claim that
> users should switch. Journalling does not help you, if you have
> unexpected kernel problem or hardware trouble, fsck _is_ mandatory.
>
> Can V4 survive few hours of test below?
The script could be improved by select random locations to damage the
filesystem, instead of hard-coding the seek=7 value. Seek=7 is good
for testing ext2/ext3 filesystems, but it may not be ideal for other
filesystems.
Another interesting refinement would be to analyze the resulting
filesystem after it has been repaired to determine how much data could
be salvaged by the fsck program.
There is a very interesting paper that I coincidentally just came
across today that talks about making filesystems robust against
various different forms of failures of modern disk systems. It is
going to be presented at the upcoming 2005 SOSP conference.
http://www.cs.wisc.edu/adsl/Publications/iron-sosp05.pdf
It's definitely worth a read. A few comments about it; first of all,
I know nothing about this modified "iron ext3" (ixt3) discussed in the
paper aside from what's the paper itself. It would be interesting to
see what they have done with it. Secondly, I _think_ sct has already
fixed the problems discussed in the paper with respect to inadequate
write squelching after an I/O failure writing to the ext3 journal, but
we need to chat with the paper's authors to confirm that, and if there
still is a problem, obviously we need to fix it. Third of all, I'll
note that the paper does takes an approving note of the fact that
Reiserfs (v3) always panic's when it detects a write fault, so for
those folks in the Reiser team who might have a persecution complex,
relax, the whole world isn't out to get you. :-)
- Ted
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-21 0:04 ` Theodore Ts'o
@ 2005-09-21 0:13 ` Hans Reiser
2005-09-21 0:27 ` Ric Wheeler
2005-09-21 1:01 ` Gregory Maxwell
2 siblings, 0 replies; 143+ messages in thread
From: Hans Reiser @ 2005-09-21 0:13 UTC (permalink / raw)
To: Theodore Ts'o, vitaly
Cc: Pavel Machek, Horst von Brand, thenewme91, Christoph Hellwig,
Denis Vlasenko, chriswhite, LKML, ReiserFS List
Thanks Ted, I'll ask Vitaly to read the paper, and tell us what he
thinks should be learned from it for V4.
Hans
Theodore Ts'o wrote:
>On Tue, Sep 20, 2005 at 09:51:33AM +0200, Pavel Machek wrote:
>
>
>>Do you have working fsck for V4? Until then, you should not claim that
>>users should switch. Journalling does not help you, if you have
>>unexpected kernel problem or hardware trouble, fsck _is_ mandatory.
>>
>>Can V4 survive few hours of test below?
>>
>>
>
>The script could be improved by select random locations to damage the
>filesystem, instead of hard-coding the seek=7 value. Seek=7 is good
>for testing ext2/ext3 filesystems, but it may not be ideal for other
>filesystems.
>
>Another interesting refinement would be to analyze the resulting
>filesystem after it has been repaired to determine how much data could
>be salvaged by the fsck program.
>
>There is a very interesting paper that I coincidentally just came
>across today that talks about making filesystems robust against
>various different forms of failures of modern disk systems. It is
>going to be presented at the upcoming 2005 SOSP conference.
>
> http://www.cs.wisc.edu/adsl/Publications/iron-sosp05.pdf
>
>It's definitely worth a read. A few comments about it; first of all,
>I know nothing about this modified "iron ext3" (ixt3) discussed in the
>paper aside from what's the paper itself. It would be interesting to
>see what they have done with it. Secondly, I _think_ sct has already
>fixed the problems discussed in the paper with respect to inadequate
>write squelching after an I/O failure writing to the ext3 journal, but
>we need to chat with the paper's authors to confirm that, and if there
>still is a problem, obviously we need to fix it. Third of all, I'll
>note that the paper does takes an approving note of the fact that
>Reiserfs (v3) always panic's when it detects a write fault, so for
>those folks in the Reiser team who might have a persecution complex,
>relax, the whole world isn't out to get you. :-)
>
> - Ted
>
>
>
>
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-21 0:04 ` Theodore Ts'o
2005-09-21 0:13 ` Hans Reiser
@ 2005-09-21 0:27 ` Ric Wheeler
2005-09-21 0:44 ` Hans Reiser
2005-09-21 1:01 ` Gregory Maxwell
2 siblings, 1 reply; 143+ messages in thread
From: Ric Wheeler @ 2005-09-21 0:27 UTC (permalink / raw)
To: Theodore Ts'o
Cc: Pavel Machek, Hans Reiser, Horst von Brand, thenewme91,
Christoph Hellwig, Denis Vlasenko, chriswhite, LKML,
ReiserFS List
Theodore Ts'o wrote:
>
> Another interesting refinement would be to analyze the resulting
> filesystem after it has been repaired to determine how much data could
> be salvaged by the fsck program.
We use reiserfs3 to store data and have had very good luck in getting
data off of real world, hard disk failures. In our case, we have a
digital signature which is used to compare validate the content of the
files after recovery so we have an extra comfort level with the results
of a repaired file system...
Working on getting fsck to run reliably and quickly on large file
systems (any type of file system) is certainly a big item on our wish
list. With relatively small file system (320GB) we can spend hours
trying to recover.
>
> There is a very interesting paper that I coincidentally just came
> across today that talks about making filesystems robust against
> various different forms of failures of modern disk systems. It is
> going to be presented at the upcoming 2005 SOSP conference.
>
> http://www.cs.wisc.edu/adsl/Publications/iron-sosp05.pdf
>
> It's definitely worth a read. A few comments about it; first of all,
> I know nothing about this modified "iron ext3" (ixt3) discussed in the
> paper aside from what's the paper itself. It would be interesting to
> see what they have done with it. Secondly, I _think_ sct has already
> fixed the problems discussed in the paper with respect to inadequate
> write squelching after an I/O failure writing to the ext3 journal, but
> we need to chat with the paper's authors to confirm that, and if there
> still is a problem, obviously we need to fix it. Third of all, I'll
> note that the paper does takes an approving note of the fact that
> Reiserfs (v3) always panic's when it detects a write fault, so for
> those folks in the Reiser team who might have a persecution complex,
> relax, the whole world isn't out to get you. :-)
>
> - Ted
We have been sponsors of this work at Wisconsin - a good group with
interesting results.
As an earlier thread on lkml showed this summer, we still have a long
way to go to getting consistent error semantics in face of media
failures between the various file systems. I am not sure that we even
have consensus on what that default behavior should be between
developers, so image how difficult life is for application writers who
want to try to ride through or write automated "HA" recovery scripts for
systems with large numbers of occasionally flaky IO devices ;-)
Ric
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-21 0:27 ` Ric Wheeler
@ 2005-09-21 0:44 ` Hans Reiser
2005-09-21 1:12 ` Ric Wheeler
0 siblings, 1 reply; 143+ messages in thread
From: Hans Reiser @ 2005-09-21 0:44 UTC (permalink / raw)
To: Ric Wheeler, vitaly
Cc: Theodore Ts'o, Pavel Machek, Horst von Brand, thenewme91,
Christoph Hellwig, Denis Vlasenko, chriswhite, LKML,
ReiserFS List
Ric Wheeler wrote:
> As an earlier thread on lkml showed this summer, we still have a long
> way to go to getting consistent error semantics in face of media
> failures between the various file systems. I am not sure that we even
> have consensus on what that default behavior should be between
> developers, so image how difficult life is for application writers who
> want to try to ride through or write automated "HA" recovery scripts
> for systems with large numbers of occasionally flaky IO devices ;-)
If you'd like to form a committee to standardize these things, I will
ask Vitaly to work with you on that committee, and to have ReiserFS3+4
conform to the standards that result.
Hans
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-21 0:44 ` Hans Reiser
@ 2005-09-21 1:12 ` Ric Wheeler
2005-09-21 3:05 ` Hans Reiser
0 siblings, 1 reply; 143+ messages in thread
From: Ric Wheeler @ 2005-09-21 1:12 UTC (permalink / raw)
To: Hans Reiser
Cc: vitaly, Theodore Ts'o, Pavel Machek, Horst von Brand,
thenewme91, Christoph Hellwig, Denis Vlasenko, chriswhite, LKML,
ReiserFS List
Hans Reiser wrote:
> Ric Wheeler wrote:
>
>
>>As an earlier thread on lkml showed this summer, we still have a long
>>way to go to getting consistent error semantics in face of media
>>failures between the various file systems. I am not sure that we even
>>have consensus on what that default behavior should be between
>>developers, so image how difficult life is for application writers who
>>want to try to ride through or write automated "HA" recovery scripts
>>for systems with large numbers of occasionally flaky IO devices ;-)
>
>
> If you'd like to form a committee to standardize these things, I will
> ask Vitaly to work with you on that committee, and to have ReiserFS3+4
> conform to the standards that result.
>
> Hans
I am not a big fan of formal committees, but would be happy to take part
in any effort to standardize, code and test the result...
ric
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-21 1:12 ` Ric Wheeler
@ 2005-09-21 3:05 ` Hans Reiser
2005-09-21 4:55 ` Gregory Maxwell
2005-09-21 10:16 ` Vitaly Fertman
0 siblings, 2 replies; 143+ messages in thread
From: Hans Reiser @ 2005-09-21 3:05 UTC (permalink / raw)
To: Ric Wheeler
Cc: vitaly, Theodore Ts'o, Pavel Machek, Horst von Brand,
thenewme91, Christoph Hellwig, Denis Vlasenko, chriswhite, LKML,
ReiserFS List
Ric Wheeler wrote:
> Hans Reiser wrote:
>
>> Ric Wheeler wrote:
>>
>>
>>> As an earlier thread on lkml showed this summer, we still have a long
>>> way to go to getting consistent error semantics in face of media
>>> failures between the various file systems. I am not sure that we even
>>> have consensus on what that default behavior should be between
>>> developers, so image how difficult life is for application writers who
>>> want to try to ride through or write automated "HA" recovery scripts
>>> for systems with large numbers of occasionally flaky IO devices ;-)
>>
>>
>>
>> If you'd like to form a committee to standardize these things, I will
>> ask Vitaly to work with you on that committee, and to have ReiserFS3+4
>> conform to the standards that result.
>>
>> Hans
>
>
> I am not a big fan of formal committees, but would be happy to take
> part in any effort to standardize, code and test the result...
>
> ric
>
>
>
The committee could simply exchange a set of emails, and agree on
things. I doubt it needs to get all complicated. I suggest you contact
all the folks you want to be consistent with each other, send us an
email asking us to all try to work together, and then ask for proposals
on what we should all conform to. Distill the proposals, and then
suggest a common solution. With luck, we will all just say yes.:)
Hans
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-21 3:05 ` Hans Reiser
@ 2005-09-21 4:55 ` Gregory Maxwell
2005-09-21 11:21 ` Ric Wheeler
2005-09-21 10:16 ` Vitaly Fertman
1 sibling, 1 reply; 143+ messages in thread
From: Gregory Maxwell @ 2005-09-21 4:55 UTC (permalink / raw)
To: Hans Reiser
Cc: Ric Wheeler, vitaly, Theodore Ts'o, Pavel Machek,
Horst von Brand, thenewme91, Christoph Hellwig, Denis Vlasenko,
chriswhite, LKML, ReiserFS List
On 9/20/05, Hans Reiser <reiser@namesys.com> wrote:
> > I am not a big fan of formal committees, but would be happy to take
> > part in any effort to standardize, code and test the result...
> The committee could simply exchange a set of emails, and agree on
> things. I doubt it needs to get all complicated. I suggest you contact
> all the folks you want to be consistent with each other, send us an
> email asking us to all try to work together, and then ask for proposals
> on what we should all conform to. Distill the proposals, and then
> suggest a common solution. With luck, we will all just say yes.:)
Another goal of the group should be to formulate a requested set of
changes or extensions to the makers of drives and other storage
systems. For example, it might be advantageous to be able to disable
bad block relocation and allow the filesystem to perform the action.
The reason for this is because relocates slaughter streaming read
performance, but the filesystem could still contiguously allocate
around them...
Perhaps a more implementable alternative is just a method to find out
which sectors have been relocated so the data can be moved off of them
and they be avoided. (and potentially they be 'derelocated' to
preserve the relocation space)
Ditto for other layers.. if a filesystem has some internal integrity
function and a raid sweep has found that the parity doesn't agree, it
would be nice if the FS could check all possible decodings and see if
there is one that is more sane than all the others... This is even
more useful when you have raid-6 and there is a lot more potential
decoding.
Also things like bubbling up to userspace.. If there is an
unrecoverable read error in a file found during operation or an
automated scan, it should show up in syslog with some working complete
path to the file (as canonical as the fs can provide), and hopefully
an offset to the error. Then my package manager could see if this is a
file replaceable out of a package or if it's user data... If it's user
data, my backup scripts can check the access time on the file and
silently restore it from backup if the file hasn't changed. ... only
leaving me an email "Dear operator, I saved your butt yet again
--love, mr computer"
And finally operator policy.. I'd like corrupted user files to become
permission denied until I run some command to make the accessible,
don't let me hang my apps trying to access them..
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-21 4:55 ` Gregory Maxwell
@ 2005-09-21 11:21 ` Ric Wheeler
2005-09-21 17:36 ` Hans Reiser
0 siblings, 1 reply; 143+ messages in thread
From: Ric Wheeler @ 2005-09-21 11:21 UTC (permalink / raw)
To: gmaxwell
Cc: Hans Reiser, vitaly, Theodore Ts'o, Pavel Machek,
Horst von Brand, thenewme91, Christoph Hellwig, Denis Vlasenko,
chriswhite, LKML, ReiserFS List
Gregory Maxwell wrote:
>On 9/20/05, Hans Reiser <reiser@namesys.com> wrote:
>
>
>
>Another goal of the group should be to formulate a requested set of
>changes or extensions to the makers of drives and other storage
>systems. For example, it might be advantageous to be able to disable
>bad block relocation and allow the filesystem to perform the action.
>The reason for this is because relocates slaughter streaming read
>performance, but the filesystem could still contiguously allocate
>around them...
>
>
>
I think that would be a bad idea - that is how drives used to work and
it made the higher level file system code handle odd stuff.
In the field, what we tend to see is that drives that accumulate more
than a very small percentage of bad blocks (say 100 out of many
millions) tend to be on their way out and need replacing.
>Perhaps a more implementable alternative is just a method to find out
>which sectors have been relocated so the data can be moved off of them
>and they be avoided. (and potentially they be 'derelocated' to
>preserve the relocation space)
>
>
I think that this kind of information is already at hand via smart,
etc. You could write an application to query this data base, but to do
the reverse mapping from block number to file is not easy (i.e., you
need to fibmap each file in the file system in order to construct the
mapping).
>Ditto for other layers.. if a filesystem has some internal integrity
>function and a raid sweep has found that the parity doesn't agree, it
>would be nice if the FS could check all possible decodings and see if
>there is one that is more sane than all the others... This is even
>more useful when you have raid-6 and there is a lot more potential
>decoding.
>
>
One thing we do on our boxes is to run a sweep program that does a
"read-verify" command that allows us to flag bad sectors on the platter
without transferring data, polluting caches, etc. A second, repair
phase goes in and pokes at the suspect sectors trying to force a remap.
If you have the original data (as in the raid case), you can rewrite the
sector and all is well. If not, you need to unmount, re-fsck and try to
revalidate the contents of individual files (this is where the digital
signatures comes in handy).
>Also things like bubbling up to userspace.. If there is an
>unrecoverable read error in a file found during operation or an
>automated scan, it should show up in syslog with some working complete
>path to the file (as canonical as the fs can provide), and hopefully
>an offset to the error. Then my package manager could see if this is a
>file replaceable out of a package or if it's user data... If it's user
>data, my backup scripts can check the access time on the file and
>silently restore it from backup if the file hasn't changed. ... only
>leaving me an email "Dear operator, I saved your butt yet again
>--love, mr computer"
>
>
Good idea, but we don't have that reverse mapping at hand for most file
systems.
>And finally operator policy.. I'd like corrupted user files to become
>permission denied until I run some command to make the accessible,
>don't let me hang my apps trying to access them..
>
>
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-21 11:21 ` Ric Wheeler
@ 2005-09-21 17:36 ` Hans Reiser
2005-09-21 18:12 ` Ric Wheeler
0 siblings, 1 reply; 143+ messages in thread
From: Hans Reiser @ 2005-09-21 17:36 UTC (permalink / raw)
To: Ric Wheeler
Cc: gmaxwell, vitaly, Theodore Ts'o, Pavel Machek,
Horst von Brand, thenewme91, Christoph Hellwig, Denis Vlasenko,
chriswhite, LKML, ReiserFS List
Ric Wheeler wrote:
> Gregory Maxwell wrote:
>
>> On 9/20/05, Hans Reiser <reiser@namesys.com> wrote:
>>
>>
>>
>> Another goal of the group should be to formulate a requested set of
>> changes or extensions to the makers of drives and other storage
>> systems. For example, it might be advantageous to be able to disable
>> bad block relocation and allow the filesystem to perform the action.
>> The reason for this is because relocates slaughter streaming read
>> performance, but the filesystem could still contiguously allocate
>> around them...
>>
>>
>>
The words were attributed to me, but were not mine.
Sometimes mua's do that to one.
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-21 17:36 ` Hans Reiser
@ 2005-09-21 18:12 ` Ric Wheeler
0 siblings, 0 replies; 143+ messages in thread
From: Ric Wheeler @ 2005-09-21 18:12 UTC (permalink / raw)
To: Hans Reiser
Cc: gmaxwell, vitaly, Theodore Ts'o, Pavel Machek,
Horst von Brand, thenewme91, Christoph Hellwig, Denis Vlasenko,
chriswhite, LKML, ReiserFS List
Hans Reiser wrote:
> Ric Wheeler wrote:
>
>
>>Gregory Maxwell wrote:
>>
>>
>>>On 9/20/05, Hans Reiser <reiser@namesys.com> wrote:
>>>
>>>
>>>
>>>Another goal of the group should be to formulate a requested set of
>>>changes or extensions to the makers of drives and other storage
>>>systems. For example, it might be advantageous to be able to disable
>>>bad block relocation and allow the filesystem to perform the action.
>>>The reason for this is because relocates slaughter streaming read
>>>performance, but the filesystem could still contiguously allocate
>>>around them...
>>>
>>>
>>>
>
> The words were attributed to me, but were not mine.
>
> Sometimes mua's do that to one.
>
Sorry - my error in trying to trim my response ended up trimming the
proper attribution to Gregory,
ric
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-21 3:05 ` Hans Reiser
2005-09-21 4:55 ` Gregory Maxwell
@ 2005-09-21 10:16 ` Vitaly Fertman
1 sibling, 0 replies; 143+ messages in thread
From: Vitaly Fertman @ 2005-09-21 10:16 UTC (permalink / raw)
To: Hans Reiser
Cc: Ric Wheeler, vitaly, Theodore Ts'o, Pavel Machek,
Horst von Brand, thenewme91, Christoph Hellwig, Denis Vlasenko,
chriswhite, LKML, ReiserFS List
On Wednesday 21 September 2005 07:05, Hans Reiser wrote:
> Ric Wheeler wrote:
>
> > Hans Reiser wrote:
> >
> >> Ric Wheeler wrote:
> >>
> >>
> >>> As an earlier thread on lkml showed this summer, we still have a long
> >>> way to go to getting consistent error semantics in face of media
> >>> failures between the various file systems. I am not sure that we even
> >>> have consensus on what that default behavior should be between
> >>> developers, so image how difficult life is for application writers who
> >>> want to try to ride through or write automated "HA" recovery scripts
> >>> for systems with large numbers of occasionally flaky IO devices ;-)
> >>
> >>
> >>
> >> If you'd like to form a committee to standardize these things, I will
> >> ask Vitaly to work with you on that committee, and to have ReiserFS3+4
> >> conform to the standards that result.
> >>
> >> Hans
> >
> >
> > I am not a big fan of formal committees, but would be happy to take
> > part in any effort to standardize, code and test the result...
I would be happy to take part in it too.
> > ric
> >
> >
> >
> The committee could simply exchange a set of emails, and agree on
> things. I doubt it needs to get all complicated. I suggest you contact
> all the folks you want to be consistent with each other, send us an
> email asking us to all try to work together, and then ask for proposals
> on what we should all conform to. Distill the proposals, and then
> suggest a common solution. With luck, we will all just say yes.:)
--
Thanks,
Vitaly Fertman
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-21 0:04 ` Theodore Ts'o
2005-09-21 0:13 ` Hans Reiser
2005-09-21 0:27 ` Ric Wheeler
@ 2005-09-21 1:01 ` Gregory Maxwell
2005-09-21 1:15 ` Ric Wheeler
2005-09-23 6:21 ` David Greaves
2 siblings, 2 replies; 143+ messages in thread
From: Gregory Maxwell @ 2005-09-21 1:01 UTC (permalink / raw)
To: Theodore Ts'o, Pavel Machek, Hans Reiser, Horst von Brand,
thenewme91, Christoph Hellwig, Denis Vlasenko, chriswhite, LKML,
ReiserFS List
On 9/20/05, Theodore Ts'o <tytso@mit.edu> wrote:
> The script could be improved by select random locations to damage the
> filesystem, instead of hard-coding the seek=7 value. Seek=7 is good
> for testing ext2/ext3 filesystems, but it may not be ideal for other
> filesystems.
What would be interesting would be to overwrite random blocks in an
sub-exponentially increasing fashion, fsck and measure file loss at
every step. You fail the test if the system panics reading a FS that
passed a fsck. It would be interesting to chart files lost and files
silently corrupted over time...
Another interesting thought would be to snapshot a file system over
and over again while it's got a disk workout suite running on it..
Then fsck the snapshots, and check for the amount of data loss and
corruption.
> There is a very interesting paper that I coincidentally just came
> across today that talks about making filesystems robust against
> various different forms of failures of modern disk systems. It is
> going to be presented at the upcoming 2005 SOSP conference.
>
> http://www.cs.wisc.edu/adsl/Publications/iron-sosp05.pdf
Very interesting indeed, although it almost seems silly to tackle the
difficult problem of making filesystems highly robust against oddball
failure modes while our RAID subsystem falls horribly on it's face in
the fairly common (and conceptually easy to handle) failure mode of a
raid-5 where two disks have single unreadable blocks on differing
parts of the disk. (the current raid system hits one bad block, fails
the whole disk, then you attempt a rebuild and while reading hits the
other bad block and downs the array).
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-21 1:01 ` Gregory Maxwell
@ 2005-09-21 1:15 ` Ric Wheeler
2005-09-23 6:21 ` David Greaves
1 sibling, 0 replies; 143+ messages in thread
From: Ric Wheeler @ 2005-09-21 1:15 UTC (permalink / raw)
To: gmaxwell
Cc: Theodore Ts'o, Pavel Machek, Hans Reiser, Horst von Brand,
thenewme91, Christoph Hellwig, Denis Vlasenko, chriswhite, LKML,
ReiserFS List
Gregory Maxwell wrote:
> On 9/20/05, Theodore Ts'o <tytso@mit.edu> wrote:
>
>>There is a very interesting paper that I coincidentally just came
>>across today that talks about making filesystems robust against
>>various different forms of failures of modern disk systems. It is
>>going to be presented at the upcoming 2005 SOSP conference.
>>
>> http://www.cs.wisc.edu/adsl/Publications/iron-sosp05.pdf
>
>
> Very interesting indeed, although it almost seems silly to tackle the
> difficult problem of making filesystems highly robust against oddball
> failure modes while our RAID subsystem falls horribly on it's face in
> the fairly common (and conceptually easy to handle) failure mode of a
> raid-5 where two disks have single unreadable blocks on differing
> parts of the disk. (the current raid system hits one bad block, fails
> the whole disk, then you attempt a rebuild and while reading hits the
> other bad block and downs the array).
I don't have any problem with fixing RAID code, but I would not describe
the errors in this paper as oddball. Believe me, we see a lot of disk
issues and these are real examples of failures that happen to real file
systems ;-)
Ric
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-21 1:01 ` Gregory Maxwell
2005-09-21 1:15 ` Ric Wheeler
@ 2005-09-23 6:21 ` David Greaves
2005-09-23 11:37 ` Gregory Maxwell
1 sibling, 1 reply; 143+ messages in thread
From: David Greaves @ 2005-09-23 6:21 UTC (permalink / raw)
To: gmaxwell
Cc: Theodore Ts'o, Pavel Machek, Hans Reiser, Horst von Brand,
thenewme91, Christoph Hellwig, Denis Vlasenko, chriswhite, LKML,
ReiserFS List
Gregory Maxwell wrote:
>Very interesting indeed, although it almost seems silly to tackle the
>difficult problem of making filesystems highly robust against oddball
>failure modes while our RAID subsystem falls horribly on it's face in
>the fairly common (and conceptually easy to handle) failure mode of a
>raid-5 where two disks have single unreadable blocks on differing
>parts of the disk. (the current raid system hits one bad block, fails
>the whole disk, then you attempt a rebuild and while reading hits the
>other bad block and downs the array).
>
>
who's not keeping up with the linux-raid list then ;)
David
PS I'm sure assistance would be appreciated in testing and reviewing
this few day old feature - or indeed the newer 'add a new disk to the
array' feature.
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-23 6:21 ` David Greaves
@ 2005-09-23 11:37 ` Gregory Maxwell
0 siblings, 0 replies; 143+ messages in thread
From: Gregory Maxwell @ 2005-09-23 11:37 UTC (permalink / raw)
To: David Greaves
Cc: Theodore Ts'o, Pavel Machek, Hans Reiser, Horst von Brand,
thenewme91, Christoph Hellwig, Denis Vlasenko, chriswhite, LKML,
ReiserFS List
On 9/23/05, David Greaves <david@dgreaves.com> wrote:
> who's not keeping up with the linux-raid list then ;)
>
> David
> PS I'm sure assistance would be appreciated in testing and reviewing
> this few day old feature - or indeed the newer 'add a new disk to the
> array' feature.
After posting that I checked linux-raid.... Thanked the author,
patched a box, but got called out of town before I could test
anything. :)
This is an important development. ... and it's about darn time!
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-18 17:22 ` michael chang
2005-09-18 19:16 ` Valdis.Kletnieks
2005-09-18 20:04 ` Horst von Brand
@ 2005-09-18 20:52 ` Kyle Moffett
2005-09-19 0:56 ` michael chang
2005-09-18 21:38 ` Alan Cox
3 siblings, 1 reply; 143+ messages in thread
From: Kyle Moffett @ 2005-09-18 20:52 UTC (permalink / raw)
To: thenewme91
Cc: Christoph Hellwig, Denis Vlasenko, chriswhite, Hans Reiser, LKML,
ReiserFS List
On Sep 18, 2005, at 13:22:27, michael chang wrote:
> On 9/18/05, Christoph Hellwig <hch@infradead.org> wrote:
>
>> On Sun, Sep 18, 2005 at 01:21:23PM +0300, Denis Vlasenko wrote:
>>
>>> This is it. I do not say "accept reiser4 NOW", I am saying "give
>>> Hans good code review".
>>
>> that and there's much more exciting filesystems like ocfs2 around
>> that
>
> This is exciting to... whom?
To the people that review the code. We're all volunteers here; if
your filesystem is so ugly and hard to read that the code reviewers
don't feel like finding time to slog through the mess, then it
probably means that you need to clean the code, document it better,
make it simpler to understand, fix the coding-style, etc.
> The only thing that appears remotely interesting about it is that
> it's made by Oracle and apparently is supposed to be geared toward
> parallel server whatsits. This might be helpful to corporations,
> but seems senseless toward many consumers. (I'm assuming there's
> still at least one consumer left who still uses Linux.)
Like I said above, we're all volunteers. Personally, I find OCFS2
_much_ more interesting than reiser4, because it has a lot of cool
networked lock-managing algorithms that (given my current limited
understanding), work black magic. Given this, I'm a lot more likely
to spend time reading the OCFS2 code because its interesting than I
am reading reiser4 code, even though somebody eventually probably
needs to do said review. Hans' personal attacks on the people who
have criticized his code make such tasks even less personally
gratifying (IE: less interesting). I think some people are likely
hoping right now that if they put off the reiser4 code review long
enough, maybe the authors will take a hint and have it a bit cleaner
by the time they finally do get around to the review.
> Give Hans a chance; and please try to understand, even if he's hard
> to work with. Discriminate him because he's not a developer you
> can talk with, and I believe that's like discriminating a guy in a
> wheelchair because he can't run with you when you jog in the morning.
When you start getting into obscure discrimination analogies, the
discussion has become _way_ nontechnical. If this goes this goes any
further, somebody's probably going to compare a kernel developer to a
Nazi or Hitler, invoking Godwin's law and effectively killing the
thread. Please get this back onto a technical bent or drop it.
> Not everyone has the same "common sense" that you do. Explain,
> fully, with reasoning, and reproducable back-up statistics on
> common hardware, what code is wrong, and what must be written
> instead. We'd like to be efficient, and it's not being efficient
> to play a guessing
> game with us. If you don't have the time to review, then please
> hold off on replying until you have a through review of at least
> part of the code.
Christoph has noted a number of things in previous emails. I just
looked through the latest released code and several of them are still
valid. I would look through the latest code to see what is still
missing, but I can't get it on account of it being in bitkeeper,
which I don't have installed and don't intend to install.
> I'm willing to go compare... [massive nontechnical rhetoric snipped]
Unless you have technical arguments to contribute (and you indicate
that you do not), please to not spam the LKML with useless rhetoric-
filled emails that most of us will delete because we have too many
other things to do to bother reading or responding to.
Cheers,
Kyle Moffett
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$ L++++(+
++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+ PGP+++ t+(+
++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r !y?(-)
------END GEEK CODE BLOCK------
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-18 20:52 ` Kyle Moffett
@ 2005-09-19 0:56 ` michael chang
0 siblings, 0 replies; 143+ messages in thread
From: michael chang @ 2005-09-19 0:56 UTC (permalink / raw)
To: Kyle Moffett
Cc: Christoph Hellwig, Denis Vlasenko, chriswhite, Hans Reiser, LKML,
ReiserFS List
On 9/18/05, Kyle Moffett <mrmacman_g4@mac.com> wrote:
> On Sep 18, 2005, at 13:22:27, michael chang wrote:
> > On 9/18/05, Christoph Hellwig <hch@infradead.org> wrote:
> >
> >> On Sun, Sep 18, 2005 at 01:21:23PM +0300, Denis Vlasenko wrote:
> >>
> >>> This is it. I do not say "accept reiser4 NOW", I am saying "give
> >>> Hans good code review".
> >>
> >> that and there's much more exciting filesystems like ocfs2 around
> >> that
> >
> > This is exciting to... whom?
>
> To the people that review the code. We're all volunteers here; if
> your filesystem is so ugly and hard to read that the code reviewers
> don't feel like finding time to slog through the mess, then it
> probably means that you need to clean the code, document it better,
> make it simpler to understand, fix the coding-style, etc.
>
> > The only thing that appears remotely interesting about it is that
> > it's made by Oracle and apparently is supposed to be geared toward
> > parallel server whatsits. This might be helpful to corporations,
> > but seems senseless toward many consumers. (I'm assuming there's
> > still at least one consumer left who still uses Linux.)
>
> Like I said above, we're all volunteers. Personally, I find OCFS2
> _much_ more interesting than reiser4, because it has a lot of cool
> networked lock-managing algorithms that (given my current limited
> understanding), work black magic. Given this, I'm a lot more likely
> to spend time reading the OCFS2 code because its interesting than I
> am reading reiser4 code, even though somebody eventually probably
> needs to do said review. Hans' personal attacks on the people who
> have criticized his code make such tasks even less personally
> gratifying (IE: less interesting). I think some people are likely
> hoping right now that if they put off the reiser4 code review long
> enough, maybe the authors will take a hint and have it a bit cleaner
> by the time they finally do get around to the review.
>
> > Give Hans a chance; and please try to understand, even if he's hard
> > to work with. Discriminate him because he's not a developer you
> > can talk with, and I believe that's like discriminating a guy in a
> > wheelchair because he can't run with you when you jog in the morning.
>
> When you start getting into obscure discrimination analogies, the
> discussion has become _way_ nontechnical. If this goes this goes any
> further, somebody's probably going to compare a kernel developer to a
> Nazi or Hitler, invoking Godwin's law and effectively killing the
> thread. Please get this back onto a technical bent or drop it.
>
> > Not everyone has the same "common sense" that you do. Explain,
> > fully, with reasoning, and reproducable back-up statistics on
> > common hardware, what code is wrong, and what must be written
> > instead. We'd like to be efficient, and it's not being efficient
> > to play a guessing
> > game with us. If you don't have the time to review, then please
> > hold off on replying until you have a through review of at least
> > part of the code.
>
> Christoph has noted a number of things in previous emails. I just
> looked through the latest released code and several of them are still
> valid. I would look through the latest code to see what is still
> missing, but I can't get it on account of it being in bitkeeper,
> which I don't have installed and don't intend to install.
>
> > I'm willing to go compare... [massive nontechnical rhetoric snipped]
>
> Unless you have technical arguments to contribute (and you indicate
> that you do not), please to not spam the LKML with useless rhetoric-
> filled emails that most of us will delete because we have too many
> other things to do to bother reading or responding to.
>
Alright, I concede.
Personally, I'm not much of a techie compared to you guys; I'm only in
High School, and I have a mental disorder
(http://en.wikipedia.org/wiki/Asperger's_Syndrome), so I'll stop here,
and hope that you guys can resolve this yourselves. Good luck to all,
and hopefully there will be a peaceful resolution here.
--
~Mike
- Just my two cents
- No man is an island, and no man is unable.
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-18 17:22 ` michael chang
` (2 preceding siblings ...)
2005-09-18 20:52 ` Kyle Moffett
@ 2005-09-18 21:38 ` Alan Cox
2005-09-19 5:07 ` Hans Reiser
3 siblings, 1 reply; 143+ messages in thread
From: Alan Cox @ 2005-09-18 21:38 UTC (permalink / raw)
To: thenewme91
Cc: Christoph Hellwig, Denis Vlasenko, chriswhite, Hans Reiser, LKML,
ReiserFS List
On Sul, 2005-09-18 at 13:22 -0400, michael chang wrote:
> This is exciting to... whom? The only thing that appears remotely
> interesting about it is that it's made by Oracle and apparently is
> supposed to be geared toward parallel server whatsits.
Which no current included fs supports. And parallel file systems btw get
exciting for everyone once you have virtualisation.
> Is that Hans' fault, or the fault of your lot? Why can't we all just get along?
Insufficient drugs ;) ?
> work with. Discriminate him because he's not a developer you can talk
> with, and I believe that's like discriminating a guy in a wheelchair
> because he can't run with you when you jog in the morning.
Hans can learn to work with people, most folks in wheelchairs cannot
take lessons and walk. Many of them have tried months of physiotherapy.
to learn to walk again. I think your comparison is insulting to a lot of
the disabled.
> Also, let's say that Reiser4 doesn't get into the kernel, as maybe XFS
> or ext2 or ext3 had never gotten into the kernel. How would their
Linus refused ext3 initially. It went in because it had a userbase,
vendors shipping it and reliable clean code. Saying "no" a lot is really
rather important to keeping the kernel maintainable. I regularly meet
cases we should have said "no" a lot louder 8)
> I'm willing to go compare Reiser4 to ext2/3 as like H.264 to Mpeg-2.
> Indeed, H.264 crashes some computers, similar to Reiser4 might crash
> some machines, but this is merely because Reiser4 explores new
It doesn't matter if reiser4 causes crashes. It matters that people can
fix them, that they are actively fixed and the code is maintainable. It
will have bugs, all complex code has bugs. Hans team have demonstrated
the ability to fix some of those bugs fast, but we also all remember
what happened with reiser3 later on despite early fast fixing.
One big reason we jump up and down so much about the coding style is
that its the one thing that ensures someone else can maintain and fix
code that the author has abandoned, doesn't have time to fix or that
needs access to specific hardware the authors may not have.
Alan
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-18 21:38 ` Alan Cox
@ 2005-09-19 5:07 ` Hans Reiser
2005-09-19 9:01 ` Christoph Hellwig
` (3 more replies)
0 siblings, 4 replies; 143+ messages in thread
From: Hans Reiser @ 2005-09-19 5:07 UTC (permalink / raw)
To: Alan Cox
Cc: thenewme91, Christoph Hellwig, Denis Vlasenko, chriswhite, LKML,
ReiserFS List
Alan Cox wrote:
>
>It doesn't matter if reiser4 causes crashes. It matters that people can
>fix them, that they are actively fixed and the code is maintainable. It
>will have bugs, all complex code has bugs. Hans team have demonstrated
>the ability to fix some of those bugs fast, but we also all remember
>what happened with reiser3 later on despite early fast fixing.
>
>
What was that?
>One big reason we jump up and down so much about the coding style is
>that its the one thing that ensures someone else can maintain and fix
>code that the author has abandoned, doesn't have time to fix or that
>needs access to specific hardware the authors may not have.
>
So why is the code in the kernel so hard to read then?
Linux kernel code is getting better, and Andrew Morton's code is
especially good, but for the most part it's unnecessarily hard to read.
Look at the elevator code for instance. Ugh.
I differ in one major aspect from some. That is, the only coding style
requirement I have of those who work for me is that it must be easy to
read. That is because at every company I can remember where someone was
gungho about advocating that code be written in a specific defined
style, that someone was always the one with the least readable code.
I have a simple punishment for those who violate my requirement: I go
through the code line by line with them, which they always hate for some
reason, and help them comment and clarify it. 1-2 sessions of this, and
they usually change how they code so that they don't have to go through
it again with me.
Asking for readable code is not that different from asking for readable
novels: if you try to define what is required rather than teaching
instance by instance, you can only get in the way of the artist rather
than instructing.
That is why I just say "make it easy to read and I don't care how you do
that so long as it works."
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-19 5:07 ` Hans Reiser
@ 2005-09-19 9:01 ` Christoph Hellwig
2005-09-19 9:16 ` Christoph Hellwig
2005-09-19 9:21 ` Andrew Morton
2005-09-19 10:43 ` Alan Cox
` (2 subsequent siblings)
3 siblings, 2 replies; 143+ messages in thread
From: Christoph Hellwig @ 2005-09-19 9:01 UTC (permalink / raw)
To: Hans Reiser; +Cc: alan, akpm, linux-kernel
Thanks a lot for the roundless attacks, but I'm done.
I'll stop helping you to review stuff because it's just totally pointless,
you ignore most of the review anyway and start personal attacks.
Please find someone else to review your code for inclusion, that can stand
beeing attacked everytime they write an email. Before you should probably
fix up various bits I wrote up and especialy make sure to get rid of
all duplication of generic I/O code or explain in detail why you need it
and fix your own implementations.
And next time you request review request and inclusion please use nicer
words than 'I request inclusion'. There's no right to get code included
in the kernel tree, it's a honor.
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-19 9:01 ` Christoph Hellwig
@ 2005-09-19 9:16 ` Christoph Hellwig
2005-09-19 9:21 ` Andrew Morton
1 sibling, 0 replies; 143+ messages in thread
From: Christoph Hellwig @ 2005-09-19 9:16 UTC (permalink / raw)
To: Hans Reiser, alan, akpm, linux-kernel
On Mon, Sep 19, 2005 at 10:01:45AM +0100, Christoph Hellwig wrote:
> Thanks a lot for the roundless attacks, but I'm done.
groundless..
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-19 9:01 ` Christoph Hellwig
2005-09-19 9:16 ` Christoph Hellwig
@ 2005-09-19 9:21 ` Andrew Morton
1 sibling, 0 replies; 143+ messages in thread
From: Andrew Morton @ 2005-09-19 9:21 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: reiser, alan, linux-kernel
Christoph Hellwig <hch@infradead.org> wrote:
>
> Before you should probably
> fix up various bits I wrote up and especialy make sure to get rid of
> all duplication of generic I/O code or explain in detail why you need it
> and fix your own implementations.
Yup, thanks. I've made a record of your comments in the changelog for
-mm's reiser4-only.patch.
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-19 5:07 ` Hans Reiser
2005-09-19 9:01 ` Christoph Hellwig
@ 2005-09-19 10:43 ` Alan Cox
2005-09-19 18:50 ` Hans Reiser
2005-09-19 18:51 ` Hans Reiser
2005-09-19 12:45 ` Jens Axboe
2005-09-20 4:16 ` Nick Piggin
3 siblings, 2 replies; 143+ messages in thread
From: Alan Cox @ 2005-09-19 10:43 UTC (permalink / raw)
To: Hans Reiser
Cc: thenewme91, Christoph Hellwig, Denis Vlasenko, chriswhite, LKML,
ReiserFS List
On Sul, 2005-09-18 at 22:07 -0700, Hans Reiser wrote:
> >the ability to fix some of those bugs fast, but we also all remember
> >what happened with reiser3 later on despite early fast fixing.
> >
> >
> What was that?
Jeff Mahoney added file attributes to reiserfs3, you whined and pointed
people at the yet to be released reiserfs4. Someone fixed the 4K stack
on reiserfs3, you whined. Chris Mason added other fixes like
data=journal support to get some kind of journal feature parity with
ext3, you complained and ask it not to be added.
> That is why I just say "make it easy to read and I don't care how you do
> that so long as it works."
Perhaps you do. The kernel follows a coding style. It isn't my coding
style but like everyone else except you I try and follow it.
Alan
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-19 10:43 ` Alan Cox
@ 2005-09-19 18:50 ` Hans Reiser
2005-09-19 18:51 ` Hans Reiser
1 sibling, 0 replies; 143+ messages in thread
From: Hans Reiser @ 2005-09-19 18:50 UTC (permalink / raw)
To: Alan Cox
Cc: thenewme91, Christoph Hellwig, Denis Vlasenko, chriswhite, LKML,
ReiserFS List
Alan Cox wrote:
>On Sul, 2005-09-18 at 22:07 -0700, Hans Reiser wrote:
>
>
>>>the ability to fix some of those bugs fast, but we also all remember
>>>what happened with reiser3 later on despite early fast fixing.
>>>
>>>
>>>
>>>
>>What was that?
>>
>>
>
>Jeff Mahoney added file attributes to reiserfs3, you whined and pointed
>people at the yet to be released reiserfs4.
>
If you benchmarked that code, you might understand why I "whined." You
can't just create a file per directory and stuff the attributes in it
and expect good performance. Let's not forget that there was no
documentation, no design document, no design review, no QA process.
It is always a judgment call to decide what should be deferred to the
next major release and what should go into a stable branch. File
attributes are a significant portion of the bugs that V3 has had. File
attributes got added so that a marketer would have a bullet point added,
which can be very important and I am genuinely eager to work hard to
make marketers happy, but to the extent I get to decide, it will never
happen at the cost of coding it the wrong way.
Jeff is a great guy, and his bitmap related code is great stuff with
good design and solid empirical work behind it. You have to really
understand the difference between V3 and V4 to appreciate that it was
not feasible for him to code xattrs for V3 the right way, because it
would be a disk format change and a nightmare to do it. The code was
doomed by V3's lack of plugins before it was even written. There is a
reason why V4 came into being....
If added to V4, xattrs would be higher performance and cleaner to
implement. It would be far better to have spent the programming effort
on adding them to V4 and getting V4 out a little sooner.
I won't convince you of this one but it is also my reason: They are
inelegant semantics.
I don't remember the details of the 4k stack and journaling issues you
describe, so I will say nothing.
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-19 10:43 ` Alan Cox
2005-09-19 18:50 ` Hans Reiser
@ 2005-09-19 18:51 ` Hans Reiser
1 sibling, 0 replies; 143+ messages in thread
From: Hans Reiser @ 2005-09-19 18:51 UTC (permalink / raw)
To: Alan Cox
Cc: thenewme91, Christoph Hellwig, Denis Vlasenko, chriswhite, LKML,
ReiserFS List
Alan Cox wrote:
>
>Perhaps you do. The kernel follows a coding style. It isn't my coding
>style but like everyone else except you I try and follow it.
>
>
I also don't care enough about coding style issues to resist them.;-)
We have conformed to the coding style issues that were pointed out, and
as more are pointed out we will conform to them.
Hans
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-19 5:07 ` Hans Reiser
2005-09-19 9:01 ` Christoph Hellwig
2005-09-19 10:43 ` Alan Cox
@ 2005-09-19 12:45 ` Jens Axboe
2005-09-20 4:16 ` Nick Piggin
3 siblings, 0 replies; 143+ messages in thread
From: Jens Axboe @ 2005-09-19 12:45 UTC (permalink / raw)
To: Hans Reiser
Cc: Alan Cox, thenewme91, Christoph Hellwig, Denis Vlasenko,
chriswhite, LKML, ReiserFS List
On Sun, Sep 18 2005, Hans Reiser wrote:
> Linux kernel code is getting better, and Andrew Morton's code is
> especially good, but for the most part it's unnecessarily hard to read.
> Look at the elevator code for instance. Ugh.
That's pretty bold, coming from someone who cannot even figure out how
to follow the style guidelines of the kernel.
The elevator core api is so trivial, I don't believe you find this hard
to read. The individual io schedulers tend to have comments in functions
that aren't immediately obvious. So I'm curious, what do part makes you
go 'ugh'?
So please explain or refrain from making stupid unwarranted comments
about other peoples code.
> That is why I just say "make it easy to read and I don't care how you do
> that so long as it works."
Then why do you insist on commenting your code differently than everyone
else ('everyone' means the kernel here, since that is your target)?
--
Jens Axboe
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-19 5:07 ` Hans Reiser
` (2 preceding siblings ...)
2005-09-19 12:45 ` Jens Axboe
@ 2005-09-20 4:16 ` Nick Piggin
2005-09-20 6:28 ` Hans Reiser
3 siblings, 1 reply; 143+ messages in thread
From: Nick Piggin @ 2005-09-20 4:16 UTC (permalink / raw)
To: Hans Reiser
Cc: Alan Cox, thenewme91, Christoph Hellwig, Denis Vlasenko,
chriswhite, LKML, ReiserFS List
Hans Reiser wrote:
>So why is the code in the kernel so hard to read then?
>
>Linux kernel code is getting better, and Andrew Morton's code is
>especially good, but for the most part it's unnecessarily hard to read.
>Look at the elevator code for instance. Ugh.
>
>
What's wrong with the elevator code?
The elevator code was one of the first things I got involved with
as a complete kernel newbie, and I was able to follow the current
code well enough to make a new IO scheduler, and extend the
elevator API sufficiently to provide the fairly unique
capabilities I needed.
If it is the elevator *API* you are worried about, that is fairly
trivial and well documented by Jens and myself in
Documentation/block/biodoc.txt, along with an overview of some key
ideas useful for iosched implementors.
as-iosched.c itself is IMO reasonably well commented (at least
the non-trivial, non-boilerplate functions). That is not to say it
is trivial to understand because it is a fairly complex state
machine and heuristics, but at less than 2000 lines of very well
contained code it is not an impossible task to understand it.
If that is too much for you, noop-iosched.c implements a fully
working io scheduler in exactly 94 lines, including whitespace and
comments.
What are your specific concerns? I would be interested in helping
to fix any valid ones you have.
Thanks,
Nick
Send instant messages to your online friends http://au.messenger.yahoo.com
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-20 4:16 ` Nick Piggin
@ 2005-09-20 6:28 ` Hans Reiser
2005-09-20 7:16 ` Nick Piggin
2005-09-20 15:42 ` Horst von Brand
0 siblings, 2 replies; 143+ messages in thread
From: Hans Reiser @ 2005-09-20 6:28 UTC (permalink / raw)
To: Nick Piggin
Cc: Alan Cox, thenewme91, Christoph Hellwig, Denis Vlasenko,
chriswhite, LKML, ReiserFS List, Nate Diller
Nick Piggin wrote:
> Hans Reiser wrote:
>
>> So why is the code in the kernel so hard to read then?
>>
>> Linux kernel code is getting better, and Andrew Morton's code is
>> especially good, but for the most part it's unnecessarily hard to
>> read. Look at the elevator code for instance. Ugh.
>>
>>
>
> What's wrong with the elevator code?
>
The name for one. There is no elevator algorithm anywhere in it. There
is a least block number first algorithm that was called an elevator, but
it does not have the properties described by Ousterhout and sundry CS
textbooks describing elevator algorithms. The textbook algorithms are
better than least block number first, and it is interesting how nobody
fixed the mislabeling of the algorithm once Linux had gotten to the
point that it was striving for more than making gcc be able to run on it.
cfq is good code though for many usage patterns.
I would say more, but I need to talk a customer into ok'ing releasing
some code first, so I can only say what I knew before doing the work for
that customer at this time.
If you would like many more details of coding/commenting inelegance, ask
Nate Diller after the customer oks his talking about it, which will
happen more easily if we say nothing that we did not know before the
work for them until we first get their ok.....
Hans
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-20 6:28 ` Hans Reiser
@ 2005-09-20 7:16 ` Nick Piggin
2005-09-20 7:59 ` Hans Reiser
2005-09-20 15:42 ` Horst von Brand
1 sibling, 1 reply; 143+ messages in thread
From: Nick Piggin @ 2005-09-20 7:16 UTC (permalink / raw)
To: Hans Reiser
Cc: Alan Cox, thenewme91, Christoph Hellwig, Denis Vlasenko,
chriswhite, lkml, ReiserFS List, Nate Diller
On Mon, 2005-09-19 at 23:28 -0700, Hans Reiser wrote:
> Nick Piggin wrote:
> > What's wrong with the elevator code?
> >
> The name for one. There is no elevator algorithm anywhere in it. There
> is a least block number first algorithm that was called an elevator, but
Well the terminology changed to "io scheduler" now, however the
residual "elevator" name found in places doesn't cause anyone
any problems and there isn't much reason to change it other than
the desire to break things.
> it does not have the properties described by Ousterhout and sundry CS
> textbooks describing elevator algorithms. The textbook algorithms are
> better than least block number first, and it is interesting how nobody
> fixed the mislabeling of the algorithm once Linux had gotten to the
> point that it was striving for more than making gcc be able to run on it.
>
There is no least block number first io scheduler now. And the
deadline scheduler is basically an elevator algorithm with
deadlines.
> cfq is good code though for many usage patterns.
>
But that is not a true elevator algorithm either... so what are
you trying to say?
> I would say more, but I need to talk a customer into ok'ing releasing
> some code first, so I can only say what I knew before doing the work for
> that customer at this time.
>
> If you would like many more details of coding/commenting inelegance, ask
> Nate Diller after the customer oks his talking about it, which will
> happen more easily if we say nothing that we did not know before the
> work for them until we first get their ok.....
>
I happen to think that the "elevator code" is quite nice, the
block layer side, the interface itself, and the io schedulers
too. So I wouldn't fix up anything unless someone came to me
with an issue :)
Anyway, let's kill this subthread. I just don't think you proved
much of a point by picking a random kernel subsystem to point to,
whether such criticism was justified or not.
But if you really need to , I instead suggest badmouthing devfs.
That is sure to get you on the good side of the VFS guys! :)
Nick
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-20 7:16 ` Nick Piggin
@ 2005-09-20 7:59 ` Hans Reiser
2005-09-20 8:31 ` elevators (was Re: I request inclusion of reiser4 in the mainline kernel) Nick Piggin
2005-09-20 11:42 ` I request inclusion of reiser4 in the mainline kernel Jens Axboe
0 siblings, 2 replies; 143+ messages in thread
From: Hans Reiser @ 2005-09-20 7:59 UTC (permalink / raw)
To: Nick Piggin
Cc: Alan Cox, thenewme91, Christoph Hellwig, Denis Vlasenko,
chriswhite, lkml, ReiserFS List, Nate Diller
Nick Piggin wrote:
>On Mon, 2005-09-19 at 23:28 -0700, Hans Reiser wrote:
>
>
>>Nick Piggin wrote:
>>
>>
>
>
>
>>>What's wrong with the elevator code?
>>>
>>>
>>>
>>The name for one. There is no elevator algorithm anywhere in it. There
>>is a least block number first algorithm that was called an elevator, but
>>
>>
>
>Well the terminology changed to "io scheduler" now, however the
>residual "elevator" name found in places doesn't cause anyone
>any problems and there isn't much reason to change it other than
>the desire to break things.
>
>
Did you really say that? I mean, come on, can't you at least manage a
"well, it ought to get changed but I am busy with something more
exciting to me".
>
>
>>it does not have the properties described by Ousterhout and sundry CS
>>textbooks describing elevator algorithms. The textbook algorithms are
>>better than least block number first, and it is interesting how nobody
>>fixed the mislabeling of the algorithm once Linux had gotten to the
>>point that it was striving for more than making gcc be able to run on it.
>>
>>
>>
>
>There is no least block number first io scheduler now. And the
>deadline scheduler is basically an elevator algorithm with
>deadlines.
>
>
Ask Nate about this after he gets an ok from the customer to disclose
his work. It is not so simple as you claim.
>
>
>>cfq is good code though for many usage patterns.
>>
>>
>>
>
>But that is not a true elevator algorithm either... so what are
>you trying to say?
>
>
I am trying to be balanced. 2.6 was a dramatic improvement over 2.4,
and cfq seems to work well.
>But if you really need to , I instead suggest badmouthing devfs.
>That is sure to get you on the good side of the VFS guys! :)
>
>
Devfs was a good idea in its essence. http://kerneltrap.org/node/5665
suggests pretty clearly that the hostility of the VFS guys caused no one
to want to invest enough into devfs to make it viable compared to udev.
They were inappropriately nasty to Mr. Gooch, who was kind enough to
contribute an idea that Linux needed. They could have been helpful and
assisting, and instead they were the opposite. As they are with everyone.
^ permalink raw reply [flat|nested] 143+ messages in thread
* elevators (was Re: I request inclusion of reiser4 in the mainline kernel)
2005-09-20 7:59 ` Hans Reiser
@ 2005-09-20 8:31 ` Nick Piggin
2005-09-20 17:18 ` Hans Reiser
2005-09-20 11:42 ` I request inclusion of reiser4 in the mainline kernel Jens Axboe
1 sibling, 1 reply; 143+ messages in thread
From: Nick Piggin @ 2005-09-20 8:31 UTC (permalink / raw)
To: Hans Reiser; +Cc: lkml, ReiserFS List, Nate Diller
CC list trimmed.
On Tue, 2005-09-20 at 00:59 -0700, Hans Reiser wrote:
> Nick Piggin wrote:
>
> >On Mon, 2005-09-19 at 23:28 -0700, Hans Reiser wrote:
> >
> >
> >Well the terminology changed to "io scheduler" now, however the
> >residual "elevator" name found in places doesn't cause anyone
> >any problems and there isn't much reason to change it other than
> >the desire to break things.
> >
> >
> Did you really say that? I mean, come on, can't you at least manage a
> "well, it ought to get changed but I am busy with something more
> exciting to me".
>
In a perfect world maybe it should be changed, however I don't
know what out of tree drivers rely on the interface and I really
don't care to find out. Simple as that.
> Ask Nate about this after he gets an ok from the customer to disclose
> his work. It is not so simple as you claim.
>
Nate, I would be very interested to hear about your work if
and when you are able to disclose it.
[snip devfs]
Yeah I was just trying to introduce some humour to the thread!
Or maybe deflate one flamewar by starting another :)
Nick
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-20 7:59 ` Hans Reiser
2005-09-20 8:31 ` elevators (was Re: I request inclusion of reiser4 in the mainline kernel) Nick Piggin
@ 2005-09-20 11:42 ` Jens Axboe
2005-09-20 13:30 ` Lorenzo Allegrucci
2005-09-20 17:21 ` Hans Reiser
1 sibling, 2 replies; 143+ messages in thread
From: Jens Axboe @ 2005-09-20 11:42 UTC (permalink / raw)
To: Hans Reiser
Cc: Nick Piggin, Alan Cox, thenewme91, Christoph Hellwig,
Denis Vlasenko, chriswhite, lkml, ReiserFS List, Nate Diller
On Tue, Sep 20 2005, Hans Reiser wrote:
> >>The name for one. There is no elevator algorithm anywhere in it. There
> >>is a least block number first algorithm that was called an elevator, but
> >>
> >>
> >
> >Well the terminology changed to "io scheduler" now, however the
> >residual "elevator" name found in places doesn't cause anyone
> >any problems and there isn't much reason to change it other than
> >the desire to break things.
> >
> >
> Did you really say that? I mean, come on, can't you at least manage a
> "well, it ought to get changed but I am busy with something more
> exciting to me".
Seeing as you are the one that is apparently bothered by the misnomer,
it follows that you would be the one submitting a patch for this. Not
that it would be accepted though, I don't see much point in renaming
functions and breaking drivers just because of a slightly bad name. The
io schedulers are all called foo-iosched.c, it's only the simple core
api that uses the 'elevator' description.
--
Jens Axboe
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-20 11:42 ` I request inclusion of reiser4 in the mainline kernel Jens Axboe
@ 2005-09-20 13:30 ` Lorenzo Allegrucci
2005-09-20 13:41 ` Jens Axboe
` (2 more replies)
2005-09-20 17:21 ` Hans Reiser
1 sibling, 3 replies; 143+ messages in thread
From: Lorenzo Allegrucci @ 2005-09-20 13:30 UTC (permalink / raw)
To: Jens Axboe
Cc: Hans Reiser, Nick Piggin, Alan Cox, thenewme91,
Christoph Hellwig, Denis Vlasenko, chriswhite, lkml,
ReiserFS List, Nate Diller
On Tuesday 20 September 2005 13:42, Jens Axboe wrote:
> On Tue, Sep 20 2005, Hans Reiser wrote:
> > >>The name for one. There is no elevator algorithm anywhere in it. There
> > >>is a least block number first algorithm that was called an elevator, but
> > >>
> > >>
> > >
> > >Well the terminology changed to "io scheduler" now, however the
> > >residual "elevator" name found in places doesn't cause anyone
> > >any problems and there isn't much reason to change it other than
> > >the desire to break things.
> > >
> > >
> > Did you really say that? I mean, come on, can't you at least manage a
> > "well, it ought to get changed but I am busy with something more
> > exciting to me".
>
> Seeing as you are the one that is apparently bothered by the misnomer,
> it follows that you would be the one submitting a patch for this. Not
> that it would be accepted though, I don't see much point in renaming
> functions and breaking drivers just because of a slightly bad name. The
> io schedulers are all called foo-iosched.c, it's only the simple core
> api that uses the 'elevator' description.
Why not just rename the kernel option "elevator" to "iosched" ?
--- elevator.c 2005-09-20 15:26:19.000000000 +0200
+++ elevator.c.iosched 2005-09-20 15:27:11.000000000 +0200
@@ -178,7 +178,7 @@
return 0;
}
-__setup("elevator=", elevator_setup);
+__setup("iosched=", elevator_setup);
int elevator_init(request_queue_t *q, char *name)
{
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-20 13:30 ` Lorenzo Allegrucci
@ 2005-09-20 13:41 ` Jens Axboe
2005-09-20 13:55 ` Nikita Danilov
2005-09-20 15:25 ` Randy.Dunlap
2 siblings, 0 replies; 143+ messages in thread
From: Jens Axboe @ 2005-09-20 13:41 UTC (permalink / raw)
To: Lorenzo Allegrucci
Cc: Hans Reiser, Nick Piggin, Alan Cox, thenewme91,
Christoph Hellwig, Denis Vlasenko, chriswhite, lkml,
ReiserFS List, Nate Diller
On Tue, Sep 20 2005, Lorenzo Allegrucci wrote:
> On Tuesday 20 September 2005 13:42, Jens Axboe wrote:
> > On Tue, Sep 20 2005, Hans Reiser wrote:
> > > >>The name for one. There is no elevator algorithm anywhere in it. There
> > > >>is a least block number first algorithm that was called an elevator, but
> > > >>
> > > >>
> > > >
> > > >Well the terminology changed to "io scheduler" now, however the
> > > >residual "elevator" name found in places doesn't cause anyone
> > > >any problems and there isn't much reason to change it other than
> > > >the desire to break things.
> > > >
> > > >
> > > Did you really say that? I mean, come on, can't you at least manage a
> > > "well, it ought to get changed but I am busy with something more
> > > exciting to me".
> >
> > Seeing as you are the one that is apparently bothered by the misnomer,
> > it follows that you would be the one submitting a patch for this. Not
> > that it would be accepted though, I don't see much point in renaming
> > functions and breaking drivers just because of a slightly bad name. The
> > io schedulers are all called foo-iosched.c, it's only the simple core
> > api that uses the 'elevator' description.
>
> Why not just rename the kernel option "elevator" to "iosched" ?
>
> --- elevator.c 2005-09-20 15:26:19.000000000 +0200
> +++ elevator.c.iosched 2005-09-20 15:27:11.000000000 +0200
> @@ -178,7 +178,7 @@
> return 0;
> }
>
> -__setup("elevator=", elevator_setup);
> +__setup("iosched=", elevator_setup);
>
> int elevator_init(request_queue_t *q, char *name)
> {
Because I know at least SUSE uses this name for setting a different io
scheduler on boot. And there are users out there that have added the
options to their boot loader config.
So let me repeat - we are not going to break any existing setups for no
good reason. End of discussion.
--
Jens Axboe
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-20 13:30 ` Lorenzo Allegrucci
2005-09-20 13:41 ` Jens Axboe
@ 2005-09-20 13:55 ` Nikita Danilov
2005-09-20 17:46 ` Hans Reiser
2005-09-20 15:25 ` Randy.Dunlap
2 siblings, 1 reply; 143+ messages in thread
From: Nikita Danilov @ 2005-09-20 13:55 UTC (permalink / raw)
To: Lorenzo Allegrucci
Cc: Hans Reiser, Nick Piggin, Alan Cox, thenewme91,
Christoph Hellwig, Denis Vlasenko, chriswhite, lkml,
ReiserFS List, Nate Diller
Lorenzo Allegrucci <l.allegrucci@gmail.com> writes:
[...]
>
> Why not just rename the kernel option "elevator" to "iosched" ?
At least update Documentation/kernel-parameters.txt to be consistent,
but I think kernel boot options are considered to be a part of the "user
space API" and, as such, cannot be changed that easily.
Nikita.
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-20 13:55 ` Nikita Danilov
@ 2005-09-20 17:46 ` Hans Reiser
0 siblings, 0 replies; 143+ messages in thread
From: Hans Reiser @ 2005-09-20 17:46 UTC (permalink / raw)
To: Nikita Danilov
Cc: Lorenzo Allegrucci, Nick Piggin, Alan Cox, thenewme91,
Christoph Hellwig, Denis Vlasenko, chriswhite, lkml,
ReiserFS List, Nate Diller
Nikita Danilov wrote:
>Lorenzo Allegrucci <l.allegrucci@gmail.com> writes:
>
>[...]
>
>
>
>>Why not just rename the kernel option "elevator" to "iosched" ?
>>
>>
>
>At least update Documentation/kernel-parameters.txt to be consistent,
>but I think kernel boot options are considered to be a part of the "user
>space API" and, as such, cannot be changed that easily.
>
>Nikita.
>
>
>
>
You could make both names work, and then deprecate "elevator".....
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-20 13:30 ` Lorenzo Allegrucci
2005-09-20 13:41 ` Jens Axboe
2005-09-20 13:55 ` Nikita Danilov
@ 2005-09-20 15:25 ` Randy.Dunlap
2 siblings, 0 replies; 143+ messages in thread
From: Randy.Dunlap @ 2005-09-20 15:25 UTC (permalink / raw)
To: Lorenzo Allegrucci
Cc: Jens Axboe, Hans Reiser, Nick Piggin, Alan Cox, thenewme91,
Christoph Hellwig, Denis Vlasenko, chriswhite, lkml,
ReiserFS List, Nate Diller
On Tue, 20 Sep 2005, Lorenzo Allegrucci wrote:
> On Tuesday 20 September 2005 13:42, Jens Axboe wrote:
> > On Tue, Sep 20 2005, Hans Reiser wrote:
> > > >>The name for one. There is no elevator algorithm anywhere in it. There
> > > >>is a least block number first algorithm that was called an elevator, but
> > > >>
> > > >>
> > > >
> > > >Well the terminology changed to "io scheduler" now, however the
> > > >residual "elevator" name found in places doesn't cause anyone
> > > >any problems and there isn't much reason to change it other than
> > > >the desire to break things.
> > > >
> > > >
> > > Did you really say that? I mean, come on, can't you at least manage a
> > > "well, it ought to get changed but I am busy with something more
> > > exciting to me".
> >
> > Seeing as you are the one that is apparently bothered by the misnomer,
> > it follows that you would be the one submitting a patch for this. Not
> > that it would be accepted though, I don't see much point in renaming
> > functions and breaking drivers just because of a slightly bad name. The
> > io schedulers are all called foo-iosched.c, it's only the simple core
> > api that uses the 'elevator' description.
>
> Why not just rename the kernel option "elevator" to "iosched" ?
>
> --- elevator.c 2005-09-20 15:26:19.000000000 +0200
> +++ elevator.c.iosched 2005-09-20 15:27:11.000000000 +0200
> @@ -178,7 +178,7 @@
> return 0;
> }
>
> -__setup("elevator=", elevator_setup);
> +__setup("iosched=", elevator_setup);
>
> int elevator_init(request_queue_t *q, char *name)
> {
> -
if you are serious, also update
Documentation/kernel-parameters.txt (s/elevator/iosched/)
[which would make some sense]
--
~Randy
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-20 11:42 ` I request inclusion of reiser4 in the mainline kernel Jens Axboe
2005-09-20 13:30 ` Lorenzo Allegrucci
@ 2005-09-20 17:21 ` Hans Reiser
2005-09-20 18:18 ` Jens Axboe
1 sibling, 1 reply; 143+ messages in thread
From: Hans Reiser @ 2005-09-20 17:21 UTC (permalink / raw)
To: Jens Axboe
Cc: Nick Piggin, Alan Cox, thenewme91, Christoph Hellwig,
Denis Vlasenko, chriswhite, lkml, ReiserFS List, Nate Diller
Jens Axboe wrote:
>
>Seeing as you are the one that is apparently bothered by the misnomer,
>it follows that you would be the one submitting a patch for this. Not
>that it would be accepted though, I don't see much point in renaming
>functions and breaking drivers just because of a slightly bad name. The
>io schedulers are all called foo-iosched.c, it's only the simple core
>api that uses the 'elevator' description.
>
>
>
He asked for an example of messy code, I gave one. Nate can give
details on other messiness in that code.
Reiser4 has flaws also....
Give all the code time, and it will improve. The "elevator" code has
gotten a LOT better.
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-20 17:21 ` Hans Reiser
@ 2005-09-20 18:18 ` Jens Axboe
0 siblings, 0 replies; 143+ messages in thread
From: Jens Axboe @ 2005-09-20 18:18 UTC (permalink / raw)
To: Hans Reiser
Cc: Nick Piggin, Alan Cox, thenewme91, Christoph Hellwig,
Denis Vlasenko, chriswhite, lkml, ReiserFS List, Nate Diller
On Tue, Sep 20 2005, Hans Reiser wrote:
> Jens Axboe wrote:
>
> >
> >Seeing as you are the one that is apparently bothered by the misnomer,
> >it follows that you would be the one submitting a patch for this. Not
> >that it would be accepted though, I don't see much point in renaming
> >functions and breaking drivers just because of a slightly bad name. The
> >io schedulers are all called foo-iosched.c, it's only the simple core
> >api that uses the 'elevator' description.
> >
> >
> >
> He asked for an example of messy code, I gave one. Nate can give
> details on other messiness in that code.
You never gave any details on why the code is "messy" or made you go
"ugh", so no you gave no such examples. Which is a pretty odd position
to put yourself in to be honest, anyone can make silly unsubstantiated
claims.
> Reiser4 has flaws also....
All code has flaws, nothing is perfect. It's not the point. Forgive me
for being a little offended that you call my code messy for no obvious
reason.
--
Jens Axboe
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-20 6:28 ` Hans Reiser
2005-09-20 7:16 ` Nick Piggin
@ 2005-09-20 15:42 ` Horst von Brand
2005-09-20 17:46 ` Hans Reiser
2005-09-20 17:55 ` Hans Reiser
1 sibling, 2 replies; 143+ messages in thread
From: Horst von Brand @ 2005-09-20 15:42 UTC (permalink / raw)
To: Hans Reiser
Cc: Nick Piggin, Alan Cox, thenewme91, Christoph Hellwig,
Denis Vlasenko, chriswhite, LKML, ReiserFS List, Nate Diller
Hans Reiser <reiser@namesys.com> wrote:
> Nick Piggin wrote:
> > Hans Reiser wrote:
> >> So why is the code in the kernel so hard to read then?
> >>
> >> Linux kernel code is getting better, and Andrew Morton's code is
> >> especially good, but for the most part it's unnecessarily hard to
> >> read. Look at the elevator code for instance. Ugh.
> > What's wrong with the elevator code?
> The name for one. There is no elevator algorithm anywhere in it.
IO schedulers are commonly called "elevators", even though most of them
aren't. Standard operating system terminology.
> There
> is a least block number first algorithm that was called an elevator, but
> it does not have the properties described by Ousterhout and sundry CS
> textbooks describing elevator algorithms. The textbook algorithms are
> better than least block number first,
Funny that the "texbook algorithms" aren't used in real life. Wonder why...
> and it is interesting how nobody
> fixed the mislabeling of the algorithm once Linux had gotten to the
> point that it was striving for more than making gcc be able to run on it.
Could you /please/ stop your snide remarks on the code and its authors? If
for nothing else, the very people you are insulting in public are the exact
ones that will decide if they take on the work of auditing and integrating
your code.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-20 15:42 ` Horst von Brand
@ 2005-09-20 17:46 ` Hans Reiser
2005-09-20 18:25 ` Jens Axboe
2005-09-20 18:27 ` Nikita Danilov
2005-09-20 17:55 ` Hans Reiser
1 sibling, 2 replies; 143+ messages in thread
From: Hans Reiser @ 2005-09-20 17:46 UTC (permalink / raw)
To: Horst von Brand
Cc: Nick Piggin, Alan Cox, thenewme91, Christoph Hellwig,
Denis Vlasenko, chriswhite, LKML, ReiserFS List, Nate Diller
Horst von Brand wrote:
>
>
>Funny that the "texbook algorithms" aren't used in real life. Wonder why...
>
>
Try BSD. If the BSD book can be believed, they use"texbook algorithms".
;-)
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-20 17:46 ` Hans Reiser
@ 2005-09-20 18:25 ` Jens Axboe
2005-09-20 18:27 ` Nikita Danilov
1 sibling, 0 replies; 143+ messages in thread
From: Jens Axboe @ 2005-09-20 18:25 UTC (permalink / raw)
To: Hans Reiser
Cc: Horst von Brand, Nick Piggin, Alan Cox, thenewme91,
Christoph Hellwig, Denis Vlasenko, chriswhite, LKML,
ReiserFS List, Nate Diller
On Tue, Sep 20 2005, Hans Reiser wrote:
> Horst von Brand wrote:
>
> >
> >
> >Funny that the "texbook algorithms" aren't used in real life. Wonder why...
> >
> >
> Try BSD. If the BSD book can be believed, they use"texbook algorithms".
Even the BSD people are looking for better algorithms. To be honest, I
think any OS using the classic elevator sort is a joke. It's only really
suited for batch processing.
--
Jens Axboe
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-20 17:46 ` Hans Reiser
2005-09-20 18:25 ` Jens Axboe
@ 2005-09-20 18:27 ` Nikita Danilov
2005-09-21 21:16 ` Hans Reiser
1 sibling, 1 reply; 143+ messages in thread
From: Nikita Danilov @ 2005-09-20 18:27 UTC (permalink / raw)
To: Hans Reiser
Cc: Nick Piggin, Alan Cox, thenewme91, Christoph Hellwig,
Denis Vlasenko, chriswhite, LKML, ReiserFS List, Nate Diller
Hans Reiser writes:
> Horst von Brand wrote:
>
> >
> >
> >Funny that the "texbook algorithms" aren't used in real life. Wonder why...
> >
> >
> Try BSD. If the BSD book can be believed, they use"texbook algorithms".
The "textbook" one-way elevator (as indeed exemplified by FreeBSD's
src/sys/kern/subr_disk.c:bioq_disksort()) has well-known weaknesses. For
example,
dd if=/dev/zero of=FILE
can easily monopolize device queue and starve accesses to the blocks
with low block numbers.
>
> ;-)
Nikita.
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-20 18:27 ` Nikita Danilov
@ 2005-09-21 21:16 ` Hans Reiser
2005-09-21 21:37 ` Nikita Danilov
0 siblings, 1 reply; 143+ messages in thread
From: Hans Reiser @ 2005-09-21 21:16 UTC (permalink / raw)
To: Nikita Danilov
Cc: Nick Piggin, Alan Cox, thenewme91, Christoph Hellwig,
Denis Vlasenko, chriswhite, LKML, ReiserFS List, Nate Diller
Nikita Danilov wrote:
>Hans Reiser writes:
> > Horst von Brand wrote:
> >
> > >
> > >
> > >Funny that the "texbook algorithms" aren't used in real life. Wonder why...
> > >
> > >
> > Try BSD. If the BSD book can be believed, they use"texbook algorithms".
>
>The "textbook" one-way elevator (as indeed exemplified by FreeBSD's
>src/sys/kern/subr_disk.c:bioq_disksort()) has well-known weaknesses. For
>example,
>
> dd if=/dev/zero of=FILE
>
>can easily monopolize device queue and starve accesses to the blocks
>with low block numbers.
>
> >
> > ;-)
>
>Nikita.
>
>
>
>
Yes, and one can compensate for them fairly cleanly. I can't say more
without the customer releasing the code first.
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-21 21:16 ` Hans Reiser
@ 2005-09-21 21:37 ` Nikita Danilov
2005-09-21 22:07 ` Hans Reiser
0 siblings, 1 reply; 143+ messages in thread
From: Nikita Danilov @ 2005-09-21 21:37 UTC (permalink / raw)
To: Hans Reiser
Cc: Nick Piggin, Alan Cox, thenewme91, Christoph Hellwig,
Denis Vlasenko, chriswhite, LKML, ReiserFS List, Nate Diller
Hans Reiser writes:
[...]
> >
> Yes, and one can compensate for them fairly cleanly. I can't say more
> without the customer releasing the code first.
That's the point: text-book algorithms are usually useless as is. They
need adjustments and changes to work in real life.
Nikita.
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-21 21:37 ` Nikita Danilov
@ 2005-09-21 22:07 ` Hans Reiser
0 siblings, 0 replies; 143+ messages in thread
From: Hans Reiser @ 2005-09-21 22:07 UTC (permalink / raw)
To: Nikita Danilov
Cc: Nick Piggin, Alan Cox, thenewme91, Christoph Hellwig,
Denis Vlasenko, chriswhite, LKML, ReiserFS List, Nate Diller
Nikita Danilov wrote:
>Hans Reiser writes:
>
>[...]
>
> > >
> > Yes, and one can compensate for them fairly cleanly. I can't say more
> > without the customer releasing the code first.
>
>That's the point: text-book algorithms are usually useless as is. They
>need adjustments and changes to work in real life.
>
>Nikita.
>
>
>
>
Yes, but you want to understand the textbook algorithms first before you
tweak. If you don't understand why least block number first is inferior
to real elevator.....
There is value to reading the classics of literature, even though they
are always simplistic compared to real life.
Hans
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: I request inclusion of reiser4 in the mainline kernel
2005-09-20 15:42 ` Horst von Brand
2005-09-20 17:46 ` Hans Reiser
@ 2005-09-20 17:55 ` Hans Reiser
1 sibling, 0 replies; 143+ messages in thread
From: Hans Reiser @ 2005-09-20 17:55 UTC (permalink / raw)
To: Horst von Brand
Cc: Nick Piggin, Alan Cox, thenewme91, Christoph Hellwig,
Denis Vlasenko, chriswhite, LKML, ReiserFS List, Nate Diller
Horst von Brand wrote:
> Could you /please/ stop your snide remarks on the code and its authors? If
>
>for nothing else, the very people you are insulting in public are the exact
>ones that will decide if they take on the work of auditing and integrating
>your code.
>
>
Our code was called messy. It is less messy than the rest of the
kernel. I was asked for specifics. I gave one.
Sure, let this thread die. Can we all agree to that?
My guys will send patches responding to the technical portion of what
Hellwig said, the kthread stuff, etc., were useful comments to receive,
and I thank him for them.
Hans
^ permalink raw reply [flat|nested] 143+ messages in thread