Re: the " 'official' point of view" expressed by kernelnewbies.org

Re: the " 'official' point of view" expressed by kernelnewbies.org

[Al Boldi]

Jeff Garzik wrote:
> Hans Reiser wrote:
> > As the other poster mentioned, they went off to startups, and did not
> > become part of our community.  How much of that was because their
> > contributions were more hassled than welcomed, I cannot say with
> > certainty, I can only say that they were discouraged by the difficulty
> > of getting their stuff in, and this was not as it should have been.
> > They were more knowledgeable than we were on the topics they spoke on,
> > and this was not recognized and acknowledged.
> >
> > Outsiders are not respected by the kernel community.  This means we miss
> > a lot.
>
> Anyone who fails to respect the kernel development process, the process
> of building consensus, is turn not respected, flamed, and/or ignored.
>
> If you don't respect us, why should we respect you?

Respect what?  The process or the content?

Rejecting content due to disrespect for process guidelines would be rather 
sad.

If the content is worth its salt, it should be accepted w/o delay, then 
modified to comply with the process guidelines as necessary.  It's what the 
GPL allows, afterall.

Thanks!

--
Al

Re: the " 'official' point of view" expressed by kernelnewbies.org

[Horst H. von Brand]

Al Boldi <a1426z@gawab.com> wrote:
> Jeff Garzik wrote:
> > Hans Reiser wrote:
> > > As the other poster mentioned, they went off to startups, and did not
> > > become part of our community.  How much of that was because their
> > > contributions were more hassled than welcomed, I cannot say with
> > > certainty, I can only say that they were discouraged by the difficulty
> > > of getting their stuff in, and this was not as it should have been.
> > > They were more knowledgeable than we were on the topics they spoke on,
> > > and this was not recognized and acknowledged.
> > >
> > > Outsiders are not respected by the kernel community.  This means we miss
> > > a lot.

> > Anyone who fails to respect the kernel development process, the process
> > of building consensus, is turn not respected, flamed, and/or ignored.
> >
> > If you don't respect us, why should we respect you?

> Respect what?  The process or the content?

> Rejecting content due to disrespect for process guidelines would be rather 
> sad.

But necessary, as the available manpower sadly isn't infinite.

> If the content is worth its salt, it should be accepted w/o delay,

Ideally...

>                                                                    then 
> modified to comply with the process guidelines as necessary.

... and pray who is going to do that, while making sure that the needed
cleanup and adjustments don't break it? Surely the original author is in
the best position to do this, moreover by writing directly in the accepted
way even to avoid needless work.

>                                                               It's what the 
> GPL allows, afterall.

No. The GPL allows you to branch the kernel and create your own kernel with
Reiser 4 included, it doesn't say that you have the right to get your
patches into Linus' tree. [Thankfully. I've seen such a mass of junk
proposed here over the years...]
-- 
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

Re: the " 'official' point of view" expressed by kernelnewbies.org

[H. Peter Anvin]

Followup to:  <200607241857.38889.a1426z@gawab.com>
By author:    Al Boldi <a1426z@gawab.com>
In newsgroup: linux.dev.kernel
> 
> Respect what?  The process or the content?
> 
> Rejecting content due to disrespect for process guidelines would be rather 
> sad.
> 

No, it's not.  That's what you have to do to keep the kernel maintainable.

> If the content is worth its salt, it should be accepted w/o delay, then 
> modified to comply with the process guidelines as necessary.  It's what the 
> GPL allows, afterall.

Uhm, no.  That's basically "throw it over the fence and let someone
else fix the crap."  Fix it first, then it can go in.

	-hpa

Re: the " 'official' point of view" expressed by kernelnewbies.org

[Matthew Frost]

Al Boldi wrote:
> Jeff Garzik wrote:
>> Hans Reiser wrote:
>>> As the other poster mentioned, they went off to startups, and did not
>>> become part of our community.  How much of that was because their
>>> contributions were more hassled than welcomed, I cannot say with
>>> certainty, I can only say that they were discouraged by the difficulty
>>> of getting their stuff in, and this was not as it should have been.
>>> They were more knowledgeable than we were on the topics they spoke on,
>>> and this was not recognized and acknowledged.
>>>
>>> Outsiders are not respected by the kernel community.  This means we miss
>>> a lot.
>> Anyone who fails to respect the kernel development process, the process
>> of building consensus, is turn not respected, flamed, and/or ignored.
>>
>> If you don't respect us, why should we respect you?
> 
> Respect what?  The process or the content?
> 
> Rejecting content due to disrespect for process guidelines would be rather 
> sad.
> 
> If the content is worth its salt, it should be accepted w/o delay, then 
> modified to comply with the process guidelines as necessary.  It's what the 
> GPL allows, afterall.
> 

I just love it when people try to ignore a longstanding social system 
and butt right in, demanding to be heard and acted upon with all haste. 
  Politeness and protocol are essential social lubricants for a system 
that doesn't work that well to begin with.  You've seen this fortune 
entry before.

As a system administrator, how do you handle a process that repeatedly 
violates system policy?  That repeatedly submits bad input and defies 
correction?  A user that repeatedly attempts to circumvent priority and 
management structures?    Is that content 'worth its salt' if it 
violates the good order of the system?  Or do you attempt to fix the 
program, or educate the user?  And when that fails, don't you kill that 
process, or kick that user and revoke their privileges?

The kernel developers have done better than they had to for a repeated 
violation of protocol, and an obnoxious attitude towards proper 
procedure and politeness.  Yes, there were responses in kind, and flames 
back and forth, but there were helpful suggestions and good advice, 
mostly seen as affront to the 'importance' of this particular project. 
The very attitude that "If it's good enough, it doesn't need to obey 
protocol" is what has killed Reiser4.  Understand this, above all.

Submit output that can be taken as input by this system without 
judicious additional parsing.  Be UNIX-like.  Do many separate things 
separately, do them each well, and submit them to be executed 
atomically.  If one fails, fix it and resubmit.  Reiser4 has not earned 
privileges above any other user on this system.

> Thanks!

Any time.

> --
> Al
> 

Matt

Re: the " 'official' point of view" expressed by kernelnewbies.org

[Al Boldi]

H. Peter Anvin wrote:
> Al Boldi wrote:
> > Respect what?  The process or the content?
> >
> > Rejecting content due to disrespect for process guidelines would be
> > rather sad.
>
> No, it's not.  That's what you have to do to keep the kernel maintainable.
>
> > If the content is worth its salt, it should be accepted w/o delay, then
> > modified to comply with the process guidelines as necessary.  It's what
> > the GPL allows, afterall.
>
> Uhm, no.  That's basically "throw it over the fence and let someone
> else fix the crap."  Fix it first, then it can go in.

Sure, it would be terrible, if we started to accept "crap", but I wouldn't 
consider content that is worth its "salt", like reiserfs4, to be "crap".

Rejection of content should be based on technical merits only, and no process 
guidelines should stay in the way of its preliminary acceptance.  Otherwise, 
we would be asking for a return to a bureaucratic system that inhibits 
innovation, which I'm sure is not the intention of anybody, I hope.

BTW, this does not mean that impoliteness should be rewarded, on the 
contrary, impoliteness has no place anywhere, and should just be ignored, 
even if the content is worth its salt.

Thanks!

--
Al

Re: the " 'official' point of view" expressed by kernelnewbies.org

[Jeff Garzik]

Al Boldi wrote:
> Rejection of content should be based on technical merits only, and no process 
> guidelines should stay in the way of its preliminary acceptance.  Otherwise, 
> we would be asking for a return to a bureaucratic system that inhibits 
> innovation, which I'm sure is not the intention of anybody, I hope.

The most perfect filesystem in the world would be rejected, if it lacked 
a maintainer and/or is otherwise undebuggable or unmaintainable.

	Jeff

Re: the ' 'official' point of view' expressed by kernelnewbies.org

[Luigi Genoni]

Please, I'm starting to me quite upset of all those references to impoliteness.

Every time on lkml someone talks about reiserFS/reiser4, immediatelly after
espressing his technical point (if he has something to say, of course), then
he feels he needs to add that developers should be polite. i.e he feels he
needs to take the distance from reiserFs developers attitude towards other
kernel maintainers.

I am replying to this mail because it is the last one I am reading, but the
previos mails from all the other who discussed this topic are really tipical
about this attitude.

I follow lkml since years, I know very well what happened, but do you think
that people are going to change, and their attitude is going to improve, if
in every post they read, they fell to be marked as "the bad guy ready to
flame everyone who disagrees with him in the worst impolite way"? If you
want thing to go better, please avoid those considerations and be happy just
focusing on the technical arguments.

Luigi Genoni

On Tue, July 25, 2006 06:57, Al Boldi wrote:

> BTW, this does not mean that impoliteness should be rewarded, on the
> contrary, impoliteness has no place anywhere, and should just be ignored,
> even if the content is worth its salt.
>

Re: the " 'official' point of view" expressed by kernelnewbies.org

[Horst H. von Brand]

Al Boldi <a1426z@gawab.com> wrote:
> H. Peter Anvin wrote:
> > Al Boldi wrote:
> > > Respect what?  The process or the content?

> > > Rejecting content due to disrespect for process guidelines would be
> > > rather sad.

> > No, it's not.  That's what you have to do to keep the kernel maintainable.
> >
> > > If the content is worth its salt, it should be accepted w/o delay, then
> > > modified to comply with the process guidelines as necessary.  It's what
> > > the GPL allows, afterall.

> > Uhm, no.  That's basically "throw it over the fence and let someone
> > else fix the crap."  Fix it first, then it can go in.

> Sure, it would be terrible, if we started to accept "crap", but I wouldn't 
> consider content that is worth its "salt", like reiserfs4, to be "crap".

If the content is OK, but requires a /lot/ of work to integrate, it is a
liability. 

> Rejection of content should be based on technical merits only, and no
> process guidelines should stay in the way of its preliminary acceptance.

Reiser 4 has been accepted in principle, so this isn't an issue at
all. There have been /serious/ technical objections to its current state,
tho...

> Otherwise, we would be asking for a return to a bureaucratic system that
> inhibits innovation, which I'm sure is not the intention of anybody, I
> hope.

There was never any bureaucratic system here, just a meritocracy. And yes,
the merits are not only in terms of "this code is cool" but also in terms
of "this code integrates well with the rest" and "there is a very good
chance that it will be maintained in-kernel by its creator"

> BTW, this does not mean that impoliteness should be rewarded, on the 
> contrary, impoliteness has no place anywhere, and should just be ignored, 
> even if the content is worth its salt.

How is that not rewarding impoliteness? Nobody here is forced to work on
the kernel. Somebody who doesn't want to play nice with others has no place
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

Re: the " 'official' point of view" expressed by kernelnewbies.org

[Lexington Luthor]

Horst H. von Brand wrote:
> Reiser 4 has been accepted in principle, so this isn't an issue at
> all. There have been /serious/ technical objections to its current state,
> tho...
> 

Where can I find this list of issues relating to the current version of 
reiser4?

Thanks,
LL

Re: the " 'official' point of view" expressed by kernelnewbies.org

[Matthias Andree]

On Tue, 25 Jul 2006, Al Boldi wrote:

> Rejection of content should be based on technical merits only, and no process 

It pretty much looks like the original rejection (not to forget that)
after review was based on technical reasons, then the messenger was
hurt, and that's where the fussing started and it thus became a social
issue.

-- 
Matthias Andree

Re: the " 'official' point of view" expressed by kernelnewbies.org

[Tom Reinhart]

Anyone with serious need for data integrity already uses RAID, so why add 
brand new complexity for a solved problem?

RAID is great at recovering data, but not detecting errors.  File system can 
detect errors with checksum.  What is missing is an API between layers for 
filesystem to say "this sector is bad, go rebuild it."

This seems like a much more simple and useful thing than adding ECC into the 
filesystem itself.


>>>How about we switch to ecc, which would help with bit rot not sector
>>>loss?
>>
>>
>>Interesting aspect.
>>
>>Yes, we can implement ECC as a special crypto transform that inflates
>>data. As I mentioned earlier, it is possible via translation of key
>>offsets with scale factor > 1.
>>
>>Of course, it is better then nothing, but anyway meta-data remains
>>ecc-unprotected, and, hence, robustness is not increased..
>>

_________________________________________________________________
On the road to retirement? Check out MSN Life Events for advice on how to 
get there! http://lifeevents.msn.com/category.aspx?cid=Retirement

Re: the " 'official' point of view" expressed by kernelnewbies.org

[Hans Reiser]

Tom Reinhart wrote:
> Anyone with serious need for data integrity already uses RAID, so why
> add brand new complexity for a solved problem?
>
> RAID is great at recovering data, but not detecting errors.  File
> system can detect errors with checksum.  What is missing is an API
> between layers for filesystem to say "this sector is bad, go rebuild it."
I agree that such an API is needed.  I think there are a lot of systems
on desktops that lack RAID though.  Probably I should leave ECC for some
"hopefully next year" future release though.
>
> This seems like a much more simple and useful thing than adding ECC
> into the filesystem itself.
>
>
>>>> How about we switch to ecc, which would help with bit rot not sector
>>>> loss?
>>>
>>>
>>> Interesting aspect.
>>>
>>> Yes, we can implement ECC as a special crypto transform that inflates
>>> data. As I mentioned earlier, it is possible via translation of key
>>> offsets with scale factor > 1.
>>>
>>> Of course, it is better then nothing, but anyway meta-data remains
>>> ecc-unprotected, and, hence, robustness is not increased..
>>>
>
> _________________________________________________________________
> On the road to retirement? Check out MSN Life Events for advice on how
> to get there! http://lifeevents.msn.com/category.aspx?cid=Retirement
>
>
>

Re: the " 'official' point of view" expressed by kernelnewbies.org

[Edward Shishkin]

Tom Reinhart wrote:
> Anyone with serious need for data integrity already uses RAID, so why 
> add brand new complexity for a solved problem?
> 
> RAID is great at recovering data, but not detecting errors.  File system 
> can detect errors with checksum.  What is missing is an API between 
> layers for filesystem to say "this sector is bad, go rebuild it."
> 

Actually we dont need a special API: kernel should warn and recommend
running fsck, which scans the whole tree and handles blocks with bad
checksums.

> This seems like a much more simple and useful thing than adding ECC into 
> the filesystem itself.

checksumming is _not_ much more easy then ecc-ing from implementation
standpoint, however it would be nice, if some part of errors will get
fixed without massive surgery performed by fsck


> 
> 
>>>> How about we switch to ecc, which would help with bit rot not sector
>>>> loss?
>>>
>>>
>>>
>>> Interesting aspect.
>>>
>>> Yes, we can implement ECC as a special crypto transform that inflates
>>> data. As I mentioned earlier, it is possible via translation of key
>>> offsets with scale factor > 1.
>>>
>>> Of course, it is better then nothing, but anyway meta-data remains
>>> ecc-unprotected, and, hence, robustness is not increased..
>>>
> 
> _________________________________________________________________
> On the road to retirement? Check out MSN Life Events for advice on how 
> to get there! http://lifeevents.msn.com/category.aspx?cid=Retirement
> 
> 
> 

Re: the " 'official' point of view" expressed by kernelnewbies.org

[Hans Reiser]

Edward Shishkin wrote:
> Tom Reinhart wrote:
>> Anyone with serious need for data integrity already uses RAID, so why
>> add brand new complexity for a solved problem?
>>
>> RAID is great at recovering data, but not detecting errors.  File
>> system can detect errors with checksum.  What is missing is an API
>> between layers for filesystem to say "this sector is bad, go rebuild
>> it."
>>
>
> Actually we dont need a special API: kernel should warn and recommend
> running fsck, which scans the whole tree and handles blocks with bad
> checksums.
Yes, but our fsck knows nothing about RAID currently so....
>
>> This seems like a much more simple and useful thing than adding ECC
>> into the filesystem itself.
>
> checksumming is _not_ much more easy then ecc-ing from implementation
> standpoint, however it would be nice, if some part of errors will get
> fixed without massive surgery performed by fsck
>
>
>>
>>
>>>>> How about we switch to ecc, which would help with bit rot not sector
>>>>> loss?
>>>>
>>>>
>>>>
>>>> Interesting aspect.
>>>>
>>>> Yes, we can implement ECC as a special crypto transform that inflates
>>>> data. As I mentioned earlier, it is possible via translation of key
>>>> offsets with scale factor > 1.
>>>>
>>>> Of course, it is better then nothing, but anyway meta-data remains
>>>> ecc-unprotected, and, hence, robustness is not increased..
>>>>
>>
>> _________________________________________________________________
>> On the road to retirement? Check out MSN Life Events for advice on
>> how to get there! http://lifeevents.msn.com/category.aspx?cid=Retirement
>>
>>
>>
>
>
>

Re: the " 'official' point of view" expressed by kernelnewbies.org

[David Masover]

Edward Shishkin wrote:
> Tom Reinhart wrote:
>> Anyone with serious need for data integrity already uses RAID, so why 
>> add brand new complexity for a solved problem?
>>
>> RAID is great at recovering data, but not detecting errors.  File 
>> system can detect errors with checksum.  What is missing is an API 
>> between layers for filesystem to say "this sector is bad, go rebuild it."
>>
> 
> Actually we dont need a special API: kernel should warn and recommend
> running fsck, which scans the whole tree and handles blocks with bad
> checksums.

What does this have to do with RAID, though?

Re: the " 'official' point of view" expressed by kernelnewbies.org

[Edward Shishkin]

David Masover wrote:
> Edward Shishkin wrote:
> 
>> Tom Reinhart wrote:
>>
>>> Anyone with serious need for data integrity already uses RAID, so why 
>>> add brand new complexity for a solved problem?
>>>
>>> RAID is great at recovering data, but not detecting errors.  File 
>>> system can detect errors with checksum.  What is missing is an API 
>>> between layers for filesystem to say "this sector is bad, go rebuild 
>>> it."
>>>
>>
>> Actually we dont need a special API: kernel should warn and recommend
>> running fsck, which scans the whole tree and handles blocks with bad
>> checksums.
> 
> 
> What does this have to do with RAID, though?
> 
> 

I assumed we dont have raid: reiser4 can support its own checksums/ecc
signatures for (meta)data protection via node plugin

Re: the " 'official' point of view" expressed by kernelnewbies.org

[David Masover]

Edward Shishkin wrote:
> David Masover wrote:
>> Edward Shishkin wrote:
>>
>>> Tom Reinhart wrote:
>>>
>>>> Anyone with serious need for data integrity already uses RAID, so 
>>>> why add brand new complexity for a solved problem?
>>>>
>>>> RAID is great at recovering data, but not detecting errors.  File 
>>>> system can detect errors with checksum.  What is missing is an API 
>>>> between layers for filesystem to say "this sector is bad, go rebuild 
>>>> it."
>>>>
>>>
>>> Actually we dont need a special API: kernel should warn and recommend
>>> running fsck, which scans the whole tree and handles blocks with bad
>>> checksums.
>>
>>
>> What does this have to do with RAID, though?
>>
>>
> 
> I assumed we dont have raid: reiser4 can support its own checksums/ecc
> signatures for (meta)data protection via node plugin

We don't have a guaranteed raid, however, it would be nice to do the 
right thing when there is raid.

Re: the " 'official' point of view" expressed by kernelnewbies.org

[Gregory Maxwell]

On 8/15/06, Edward Shishkin <edward@namesys.com> wrote:
> checksumming is _not_ much more easy then ecc-ing from implementation
> standpoint, however it would be nice, if some part of errors will get
> fixed without massive surgery performed by fsck

We need checksumming even with eccing... ECCing on large spans of data
is too computationally costly to do unless we know something is wrong
(via a checksum).

Lets pause for a minute, when you talk about ECC what are you actually
talking about?   If you're talking about a hamming code (used on ram,
http://en.wikipedia.org/wiki/Hamming_code) or Convolutional code (used
on telecom links, http://en.wikipedia.org/wiki/Convolutional_code) or
are you talking about an erasure code like RS coding
(http://en.wikipedia.org/wiki/Reed-Solomon_code)?

I assume in the discussions that you're not talking about an RS like
code... because RAID-5 and RAID-6 are, fundamentally, a form of RS
coding. They don't solve bit errors, but when you know you've lost a
block of data they can recover it.

Non-RS forms of ECC are very slow in software (esp decoding) .. and
really aren't that useful: most of the time HDD's will lose data in
nice big chunks that erasure codes handle well but other codes do not.

The challenge with erasure codes is that you must know that a block is
bad... most of the times the drives will tell you, but some times
corruption leaks through. This is where block level checksums come
into play... they allow you to detect bad blocks and then your erasure
code allows you to recover the data.   The checksum must be fast
because you must perform it on every read from disk... this makes ECC
unsuitable, because although it could detect errors, it is too slow.
Also, the number of additional errors ECC could fix are very small..
It would simply be better to store more erasure code blocks.

An optimal RS codes which allows one block of N to fail (and require
one block extra storage)  is computationally trivial. We call it
raid-5.  If your 'threat model' is bad sectors rather than bad disks
(an increasingly realistic shift) then N needs to have nothing to do
with the number of disks you have and can be instead related to how
much protection you want on a file.

If 1:N isn't enough for you, RS can be generalized to any number of
redundant blocks. Unfortunately, doing so requires modular aritmetic
which current CPUs are not too impressively fast at. However, the
Linux Raid-6 code demonstrates that two part parity can be done quite
quickly in software.

As such, I think 'ecc' is useless.. checksums are useful because they
are cheap and allow us to use cheap erasure coding (which could be in
a lower levle raid driver, or implemented in the FS) to achieve data
integrity.

The question of including error coding in the FS or in a lower level
is, as far as I'm concerned, so clear a matter that it is hardly worth
discussing anymore.  In my view it is absolutely idiotic to place
redundancy in a lower level.

The advantage of placing redundancy in a lower level is code
simplicity and sharing.

The problem with doing so, however, is many fold.

The redundancy requirements for various parts of the file system
differ dramatically, without tight FS integration matching the need to
the service is nearly impossible.

The most important reason, however, is performance.  Raid-5 (and
raid-6) suffer a tremendous performance hit because of the requirement
to write a full stripe OR execute a read modify write cycle.  With FS
integrated erasure codes it is possible to adjust the layout of the
written blocks to ensure that every write is a full stripe write,
effectively you adjust the stripe width with every write to ensure
that the write always spans all the disks.  Alternatively you can
reduce the number of stripe chunks  (i.e. number of disks) in the
parity computation to make the write fit (although doing so wastes
space)...

FS redundancy integration also solves the layout problem. From my
experience most systems with hardware raid are getting far below
optimal performance because even when their FS is smart enough to do
file allocation in a raid aware way (XFS and to a lesser extent
EXT2/3) this is usually foiled by the partition table at the beginning
of the raid device. Resulting in 1:N FS blocks actually spanning two
disks! (thus reading that block incurres potentially 2x disk latency).

Seperated FS and redundancy layers are an antiquated concept.. The
FS's job is to provide reliable storage, fully stop.  It's shocking to
see that a dinosaur like SUN has figured this out but the free
software community still fights against it.

Re: the " 'official' point of view" expressed by kernelnewbies.org

[Tom Reinhart]

>>Anyone with serious need for data integrity already uses RAID, so why
>>add brand new complexity for a solved problem?
>>
>>RAID is great at recovering data, but not detecting errors.  File
>>system can detect errors with checksum.  What is missing is an API
>>between layers for filesystem to say "this sector is bad, go rebuild it."

>I agree that such an API is needed.  I think there are a lot of systems
>on desktops that lack RAID though.  Probably I should leave ECC for some
>"hopefully next year" future release though.

Of course, not everyone uses RAID.  ECC would benefit some people in some 
cases... no argument there.

But as a business man, you know about targetting the right features to the 
right customers:

Customer 1 uses RAID.  Obviously, reliability is very important to customer 
1, he is willing to take the extra expense to get it.  Adding another level 
of protection (checksumming/RAID restore) is a no brainer, especially since 
it adds very little overhead over what he already sacrificed to RAID.

Customer 2 doesn't use RAID.  You can add all the fancy features to the 
filesystem you want, this customer is already vulnerable to total disk loss. 
  If he really cared about integrity, he would be customer 1.  If he won't 
pay for RAID, why would he pay for ECC?  (in money or disk space overhead).

Having ECC without RAID recovery is simply targetting the wrong person.

(having both wouldn't suck.  The more layers of protection, the better, 
although ECC would only be necessary against RAID failures, which just adds 
more .9's to the reliability score.  But, you can also do this by adding 
more redundanncy disks to the array, so it's questionable if having both is 
even worth the development expense)

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar – get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

Re: the " 'official' point of view" expressed by kernelnewbies.org

[Tom Reinhart]

>From: Edward Shishkin <edward@namesys.com>

>Actually we dont need a special API: kernel should warn and recommend
>running fsck, which scans the whole tree and handles blocks with bad
>checksums.

Running fsck requires taking filesystem offline and having downtime.  No 
fun.  :(

Correcting individual data errors can be done quickly and on-line as long as 
there exists a subset of the RAID that can reconstruct the correct data 
(with the correct checksum).

_________________________________________________________________
Don’t just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/

Re: the " 'official' point of view" expressed by kernelnewbies.org

[Gregory Maxwell]

On 8/15/06, Tom Reinhart <rhino_tom@hotmail.com> wrote:
> Of course, not everyone uses RAID.  ECC would benefit some people in some
> cases... no argument there.

We can use RAID mechanisms (RS erasure code) on a single disk. You
could technically call it ECC, but if you do so you will confuse
people.  "Block level parity" would be correct.

Re: the " 'official' point of view" expressed by kernelnewbies.org

[Hans Reiser]

I am skeptical that bitflip errors above the storage layer are as common
as the ZFS authors say, and their statistics that I have seen somehow
lack a lot of detail about how they were gathered.  If, say, a device
with 100 errors counts as 100 instances for their statistics.....  Well,
it would be nice to know how they were gathered.  Next time I meet them
I must ask.

That said, if users want it, there should be a plugin that checks the bits.

I agree that stripe awareness and the need to signal the underlying raid
that a block needs to be recovered is important.  Checksumming at the fs
level seems like a reasonable plugin.

I have no opinion on the computational cost of ECC vs. checksums, I will
trust that you are correct.

Re: the " 'official' point of view" expressed by kernelnewbies.org

[Ric Wheeler]

Hans Reiser wrote:
> I am skeptical that bitflip errors above the storage layer are as common
> as the ZFS authors say, and their statistics that I have seen somehow
> lack a lot of detail about how they were gathered.  If, say, a device
> with 100 errors counts as 100 instances for their statistics.....  Well,
> it would be nice to know how they were gathered.  Next time I meet them
> I must ask.
>   
I think that most big vendors have a lot of information about failure 
rates on drives, but cannot actually share the details in public (due to 
NDA's with the suppliers).

One thing that we are trying to do is to get some of the more 
"community" oriented people at Seagate Research to come out and talk to 
the people about what are reasonable types of errors to code against.  
Current idea is to get everyone in the same place a couple of days 
before the next FAST conference (i.e., linux IO people or file system 
people and these vendors).  (See the USENIX page for details on FAST at 
http://www.usenix.org/events/fast07/cfp/).

I will say that media errors tend to be larger than single bit errors, 
i.e. you will lose a set of sectors instead of seeing a single bit flip 
on one sector (remember that the drive vendors do extensive ECC at their 
level).  What their ECC will not fix is something like junk settling on 
the platter or a really bad error like a bad disk head.

> That said, if users want it, there should be a plugin that checks the bits.
>
> I agree that stripe awareness and the need to signal the underlying raid
> that a block needs to be recovered is important.  Checksumming at the fs
> level seems like a reasonable plugin.
>
> I have no opinion on the computational cost of ECC vs. checksums, I will
> trust that you are correct.
>   

What we can (and should) do is to make sure that we detect errors much 
better than we do today.  I think that ECC would be overkill, but we 
certainly could do simple checksums for strategic parts of the file 
system data.

Also note that there is work underway in the SCSI space on something 
called "block guard" that defines some extra bytes per disk sector for 
application level data.  That could be used for per block sanity 
checking information, but how to get at it from the file system is an 
interesting question.

Val's write up at LWN on the file system workshop & the comments on that 
write up has a an active discussion on this kind of thing 
(http://lwn.net/Articles/190222/).

ric

Re: the " 'official' point of view" expressed by kernelnewbies.org

[Hans Reiser]

Ric Wheeler wrote:
> Hans Reiser wrote:
>> I am skeptical that bitflip errors above the storage layer are as common
>> as the ZFS authors say, and their statistics that I have seen somehow
>> lack a lot of detail about how they were gathered.  If, say, a device
>> with 100 errors counts as 100 instances for their statistics.....  Well,
>> it would be nice to know how they were gathered.  Next time I meet them
>> I must ask.
>>   
> I think that most big vendors have a lot of information about failure
> rates on drives, but cannot actually share the details in public (due
> to NDA's with the suppliers).
>
> One thing that we are trying to do is to get some of the more
> "community" oriented people at Seagate Research to come out and talk
> to the people about what are reasonable types of errors to code
> against.  Current idea is to get everyone in the same place a couple
> of days before the next FAST conference (i.e., linux IO people or file
> system people and these vendors).  (See the USENIX page for details on
> FAST at http://www.usenix.org/events/fast07/cfp/).
>
> I will say that media errors tend to be larger than single bit errors,
> i.e. you will lose a set of sectors instead of seeing a single bit
> flip on one sector (remember that the drive vendors do extensive ECC
> at their level).  What their ECC will not fix is something like junk
> settling on the platter or a really bad error like a bad disk head.
I think that integration of fs, fsck, and raid is the right solution for
media errors.  What I haven't seen data I trust on is what is bitflip
error rate for the  non-media sources.  Since I haven't seen data I
believe (where belief requires details being supplied), my inclination
is to say plugins that users can choose to use if they want them are the
right solution.
> I think that ECC would be overkill,
I view it as an option that we make available to enterprise customers
who want to feel good.

It is not for me to tell them that they are wrong, for I lack the data,
it is merely for me to supply it as a non-default option, and let the
users tell me how often it actually gets triggered when they use it.

Re: the " 'official' point of view" expressed by kernelnewbies.org

[PFC]

> Seperated FS and redundancy layers are an antiquated concept.. The
> FS's job is to provide reliable storage, fully stop.  It's shocking to
> see that a dinosaur like SUN has figured this out but the free
> software community still fights against it.

	I so totally agree.

	Some random points :

	- Modern harddisks use elaborate error correction schemes, so when a  
sector has an uncorrectable error, it won't be a bit flip, but rather  
something akin to a full sector worth of random bits, or at least enough  
wrong bits that the sector is pretty useless.

	- RAID could be used to detect errors, but it would be quite slow to do  
this, as all mirrors or parity disks would have to be read and checked for  
equality / zero XOR sum on each read. It is a lot more interesting  
performance-wise to send reads in parallel to all disks.

	- Checksums are needed to catch silent errors. The checksum needs to be  
long enough and strong enough (ie. not a 32 bit CRC).

	- The ZFS approach of integrating FS, redundancy and checks seems good to  
me, because there needs to be some communication between the FS and the  
redundancy layer : re-reading bad blocks and especially making all writes  
full stripe.

	- Harddisks are cheap. Would it be possible to store the FS log on a disk  
and the FS data itself on another disk ? The log disk would only hit  
sequential writes ; the data disk would sync as seldom as possible. Both  
"disks" could be raid mirrors pairs ; or the log disk could be solid-state  
in a few years when a version of the ram harddisk with ECC and decent  
bandwidth appears.