Re: reiser4 merging action list

Re: reiser4 merging action list

[Andi Kleen]

Hans Reiser <reiser@namesys.com> writes:

>    * metafiles should be disabled until we can present code that works
> right.  Half the list thinks we cannot solve the cycles problem ever. 
> Disable metafiles and postpone problem until working code, or the
> failure to produce it, makes it possible to do more than rant at each
> other.  This is currently already done in the -mm patches, but is
> mentioned lest someone think it forgotten.
> 
>    * update the locking documentation
> 
> Probably I forget something.

These are all big picture issues, but I think some low level attention to
the individual code is still needed.

Some stuff that stood out from a very quick look:

I would like for the custom spin lock debugging (spin_macros.h) and
profiling code to be removed (prof.[ch], spinprof.[ch]). Such code shouldn't 
be in specific subsystems. 

The division functions in lib.h are useless IMHO, both callers seem
to use divide by a power of two. And gcc supports shift in 64bit
fine in the kernel. Can you remove that please? 

statcnt.h: This is completely useless because you don't align
the individual fields for cache lines - so you will still
have false sharing everywhere. Also using NR_CPUS is nasty
because it can be very big - num_possible_cpus() is better. 
It should use the new dynamic per cpu allocator.

Best you just remove it for now and use atomic_t and readd properly
when you do real SMP tuning with measurements.

debug.[ch]: A lot of these functions like "schedulable" are name space
space polluting. 
reiser4_kmalloc() such wrappers are deprecated. Please remove.
xmemset et.al should be replaced with the normal functions everywhere

Best would be probably to remove most of these files for submission.

What is reiser4_internal? Can't you just use static like
everybody else?

status_flags.c: Please remove that CONFIG_FRAME_POINTER code.
In general i think it would be better if you removed that 
"private mini crashdumping".

Is there any reason you can't just use wait queues like everybody
else instead of these reimplemented condition variables in kcond.[ch]?

In general it would be good if someone experienced not from the reiser team
would read the whole source and looks for obvious problems
(I didn't, just mentioning stuff I from a quick look at some support
files) 

-Andi

Re: reiser4 merging action list

[Vladimir Saveliev]

Hello

On Tue, 2005-06-28 at 06:58, Andi Kleen wrote:
> Hans Reiser <reiser@namesys.com> writes:
> 
> >    * metafiles should be disabled until we can present code that works
> > right.  Half the list thinks we cannot solve the cycles problem ever. 
> > Disable metafiles and postpone problem until working code, or the
> > failure to produce it, makes it possible to do more than rant at each
> > other.  This is currently already done in the -mm patches, but is
> > mentioned lest someone think it forgotten.
> > 
> >    * update the locking documentation
> > 
> > Probably I forget something.
> 
> These are all big picture issues, but I think some low level attention to
> the individual code is still needed.
> 
> Some stuff that stood out from a very quick look:
> 
> I would like for the custom spin lock debugging (spin_macros.h) and
> profiling code to be removed (prof.[ch], spinprof.[ch]). Such code shouldn't 
> be in specific subsystems. 
> 
sorry, Andi, I guess you are looking at something old. Reiser4 does not
have neither prof.[ch], nor spinprof.[ch] and we removed already some
debugging code from spin_macros.h.

> The division functions in lib.h are useless IMHO, both callers seem
> to use divide by a power of two. And gcc supports shift in 64bit
> fine in the kernel. Can you remove that please? 
> 
ok

> statcnt.h: This is completely useless because you don't align
> the individual fields for cache lines - so you will still
> have false sharing everywhere. Also using NR_CPUS is nasty
> because it can be very big - num_possible_cpus() is better. 
> It should use the new dynamic per cpu allocator.
> 
statcnt.h is already removed.

> Best you just remove it for now and use atomic_t and readd properly
> when you do real SMP tuning with measurements.
> 
> debug.[ch]: A lot of these functions like "schedulable" are name space
> space polluting. 
> reiser4_kmalloc() such wrappers are deprecated. Please remove.
ok
> xmemset et.al should be replaced with the normal functions everywhere
> 
done.

> Best would be probably to remove most of these files for submission.
> 
> What is reiser4_internal? Can't you just use static like
> everybody else?

ok

> status_flags.c: Please remove that CONFIG_FRAME_POINTER code.
> In general i think it would be better if you removed that 
> "private mini crashdumping".

ok

> 
> Is there any reason you can't just use wait queues like everybody
> else instead of these reimplemented condition variables in kcond.[ch]?
> 
I will investigate that

> In general it would be good if someone experienced not from the reiser team
> would read the whole source and looks for obvious problems
> (I didn't, just mentioning stuff I from a quick look at some support
> files) 
> 
> -Andi
> 
> 

Re: reiser4 merging action list

[Andi Kleen]

On Tue, Jun 28, 2005 at 12:37:11PM +0400, Vladimir Saveliev wrote:
> have neither prof.[ch], nor spinprof.[ch] and we removed already some
> debugging code from spin_macros.h.

Yes, i was looking at some older tree with reiser4. Sorry, just
ignore what is already done.

But still spin_macros.h should be completely removed imho. Such
custom lock wrappers are strongly discouraged because it 
makes it hard for others to read your code.


> > statcnt.h: This is completely useless because you don't align
> > the individual fields for cache lines - so you will still
> > have false sharing everywhere. Also using NR_CPUS is nasty
> > because it can be very big - num_possible_cpus() is better. 
> > It should use the new dynamic per cpu allocator.
> > 
> statcnt.h is already removed.

Great.

-Andi

Re: reiser4 merging action list

[Artem B. Bityuckiy]

Andi Kleen wrote:
> Yes, i was looking at some older tree with reiser4. Sorry, just
> ignore what is already done.
> 
> But still spin_macros.h should be completely removed imho. Such
> custom lock wrappers are strongly discouraged because it 
> makes it hard for others to read your code.
>
I may comfirm that this makes Reiser4 very difficult to investigate.
Ctags doesn't work with that too..

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

Re: reiser4 plugins

[David Masover]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alan Cox wrote:
> On Iau, 2005-06-23 at 23:04, David Masover wrote:
> 
>>>What for? It works just fine as it stands, AFAICS.
>>
>>So does DOS.  Do you use DOS?  I don't even use DOS to run DOS programs.
> 
> 
> False argument. So does the pen, so do hinges on doors. Do you still
> have hinges on your doors - probably.

Indeed.  Because there's nothing better -- not because I "like it the
way it is".

>>"Ain't broke" is the battle cry of stagnation.
> 
> 
> Its also the battle cry of everyone over the age of 20 who also has a
> real job to do 8)

You caught me.  I'm not over 20.  But I have a real job, with a company
that understands the difference between "ain't broke" and "works well".

>>But, there are some things Reiser does better and faster than ext3, even
>>if you don't count file-as-directory and other toys.  There's nothing
>>ext3 does better than Reiser, unless you count the compatibility with
>>random bootloaders and low-level tools.
> 
> 
> Certainly compared with reiser3 you've missed a few out including
> resilience to disk errors (nearly nil on reiser3), and SMP scaling.

Actually, I was talking about reiser4.  And Hans corrected me on that...

Although resilience to disk errors isn't a design decision.  That's what
SMART and new hard drives are for.  And if you're stubborn enough to
keep the same FS around, there's dm-bbr.

I think Hans (or someone) decided that when hardware stops working, it's
not the job of the FS to compensate, it's the job of lower layers, or
better, the job of the admin to replace the disk and restore from backups.

>>You know how many I've had thrashed on Reiser4?  Two.  The first one was
>>with a VERY early alpha/beta, and the second one was when I dropped a
>>laptop and the disk failed.
> 
> 
> Entirely or bad blocks ? The latter should have a minimal cost on a well
> designed fs.

I was able to recover from bad blocks, though of course no Reiser that I
know of has had bad block relocation built in...  But I got all my files
off of it, fortunately.

But the disk did fail, completely, later.  Lots of loud clicking.

>>Duplication of effort.  With plugins, we can optimize the upper layers
>>of ALL filesystems, regardless of the lower layers, in such a way that
> 
> 
> In which case the features belong in the VFS as all those with
> experience and kernel contributions have been arguing.

No one's arguing that.  What we're arguing is that there does seem to be
a bit of prejudice when fuck-me-with-a-chainsaw and YOU ARE A FOOL FOR
ENABLING THIS all got in, and with at least one of those, there doesn't
seem to be any intention of changing it -- all of that, and even with an
expressed intention to fix the aesthetical problems with Reiser4 later,
we can't get the working version in now.

More infuriatingly, I, at least, have a distinct feeling that once all
the issues are fixed, an entirely different crowd of benevolent
dictators will come around and say that we can't get in because we
change the VFS.  At least some people on this list have said things to
that effect.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQrt7MngHNmZLgCUhAQKdXA/+PDpOzZYTVXgF2n4qiFyrmjFeQ6h0n8i6
c/hXx+QUU0Hw5mjq31+jf2vNpDCKQxcE/HTLdJlRfw8az+xklVOfxzEHf9yV41tv
mVKMRJYBhzk2mEvKEDNtnw47SQPBAKo9BtJvl7gOEofiPK/f2K/cy8yMUrow1E9D
02PNT0XX8ysoe86Dqip35+sphczkQN8gilXyUQujNe8edEdkW7PBhbJn92zBQag2
JxA194bquxRyhW78T3tKAEN6/tTPgZYJNy202KC619zzLlK3TslwjjfOQILdRb2i
NNkaSQBdYDK70BiFs5Ri7ZbfJHenY6mgGv7yG0vjGF6zjoXtVNsKGrYt9KBL6E1D
392ayxOlWCvBoG9n9sAUzHzcQxmU1lP6OHcO9xWrL6ySD7Fzv4rCtM0uo7gXOzNB
aDl5vK7q+ysEjOXZJWT0ikj5ndATCv0Ry8wnt1uL/uktOuaE0egwsouU0jgCDgx1
8Ib8KX/B6bhCy13WkYLPTb6Yg0k+ph0BUyONEcN5cxJIcqfcEt/4Un4MYM+CjGck
KLYrrZDclZr8p/paWdNqx1dI9NIBn+F3u78OcWY3NIGfZPh1jmSdG3LRt9DZo5bZ
ua2UlAiAWnEDHNLQyMH2zcji31DMqIUwmQ5bX9isBcxt8LORX+IKxoLdUICoY8JS
Ii5kNWJAjf4=
=Xsdv
-----END PGP SIGNATURE-----

Re: reiser4 plugins

[Horst von Brand]

David Masover <ninja@slaphack.com> wrote:
> Alan Cox wrote:
> > On Iau, 2005-06-23 at 23:04, David Masover wrote:

[...]

> >>>What for? It works just fine as it stands, AFAICS.

> >>So does DOS.  Do you use DOS?  I don't even use DOS to run DOS programs.

> > False argument. So does the pen, so do hinges on doors. Do you still
> > have hinges on your doors - probably.

> Indeed.  Because there's nothing better -- not because I "like it the
> way it is".

There being nothing better means nobody has ever been able to come up with
a better way. Most of the time at least.

> >>"Ain't broke" is the battle cry of stagnation.

> > Its also the battle cry of everyone over the age of 20 who also has a
> > real job to do 8)

> You caught me.  I'm not over 20.  But I have a real job, with a company
> that understands the difference between "ain't broke" and "works well".

"Doesn't work well" /is/ the definition of "broken". Modulo how irritating
the "not working well" is...

> >>But, there are some things Reiser does better and faster than ext3, even
> >>if you don't count file-as-directory and other toys.  There's nothing
> >>ext3 does better than Reiser, unless you count the compatibility with
> >>random bootloaders and low-level tools.

> > Certainly compared with reiser3 you've missed a few out including
> > resilience to disk errors (nearly nil on reiser3), and SMP scaling.

> Actually, I was talking about reiser4.  And Hans corrected me on that...
> 
> Although resilience to disk errors isn't a design decision.  That's what
> SMART and new hard drives are for.  And if you're stubborn enough to
> keep the same FS around, there's dm-bbr.

> I think Hans (or someone) decided that when hardware stops working, it's
> not the job of the FS to compensate, it's the job of lower layers, or
> better, the job of the admin to replace the disk and restore from
> backups.

Handling other people's data this way is just reckless irresponsibility.
Sure, you can get high performance if you just forego some of your basic
responsibilities.

> >>You know how many I've had thrashed on Reiser4?  Two.  The first one was
> >>with a VERY early alpha/beta, and the second one was when I dropped a
> >>laptop and the disk failed.

> > Entirely or bad blocks ? The latter should have a minimal cost on a well
> > designed fs.

> I was able to recover from bad blocks, though of course no Reiser that I
> know of has had bad block relocation built in...  But I got all my files
> off of it, fortunately.

And if the bad blocks had been on files? 

[...]

> > In which case the features belong in the VFS as all those with
> > experience and kernel contributions have been arguing.

> No one's arguing that.  What we're arguing is that there does seem to be
> a bit of prejudice when fuck-me-with-a-chainsaw and YOU ARE A FOOL FOR
> ENABLING THIS all got in, and with at least one of those, there doesn't
> seem to be any intention of changing it -- all of that, and even with an
> expressed intention to fix the aesthetical problems with Reiser4 later,
> we can't get the working version in now.
> 
> More infuriatingly, I, at least, have a distinct feeling that once all
> the issues are fixed, an entirely different crowd of benevolent
> dictators will come around and say that we can't get in because we
> change the VFS.  At least some people on this list have said things to
> that effect.

The dictators here have changed over time, sure. Their general attitude has
been the same all the way through, since the list started. And you might
not like it that way, but I am sure Linux is of the current high quality
exactly because any core code that gets into the kernel (and a new
filesystem that wants to be central is clearly of this kind) is checked by
multiple people with (sometimes widely) diverging backgrounds, interests,
and views. Linus himself has stated more than once that his principal job
isn't to integrate code into the kernel, but leaving stuff out.
-- 
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: reiser4 plugins

[Markus Törnqvist]

[-- Attachment #1: Type: text/plain, Size: 717 bytes --]

On Thu, Jun 23, 2005 at 11:34:50PM -0400, Horst von Brand wrote:
>David Masover <ninja@slaphack.com> wrote:

>> I think Hans (or someone) decided that when hardware stops working, it's
>> not the job of the FS to compensate, it's the job of lower layers, or
>> better, the job of the admin to replace the disk and restore from
>> backups.
>Handling other people's data this way is just reckless irresponsibility.
>Sure, you can get high performance if you just forego some of your basic
>responsibilities.

Your honest-to-bog opinion is that the FS vendor is responsible for
the admin not taking backups or the hardware vendor shipping crap?

*still trying to understand how that can be*

-- 
mjt


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: reiser4 plugins

[Theodore Ts'o]

On Mon, Jun 27, 2005 at 12:21:38PM +0300, Markus   T?rnqvist wrote:
> On Thu, Jun 23, 2005 at 11:34:50PM -0400, Horst von Brand wrote:
> >David Masover <ninja@slaphack.com> wrote:
> 
> >> I think Hans (or someone) decided that when hardware stops working, it's
> >> not the job of the FS to compensate, it's the job of lower layers, or
> >> better, the job of the admin to replace the disk and restore from
> >> backups.
> >Handling other people's data this way is just reckless irresponsibility.
> >Sure, you can get high performance if you just forego some of your basic
> >responsibilities.
> 
> Your honest-to-bog opinion is that the FS vendor is responsible for
> the admin not taking backups or the hardware vendor shipping crap?
> 
> *still trying to understand how that can be*

Most Linux users are using PC-class hardware.  And Ted's First Law of
PC-Class Hardware is: "Most of it is crap".  And then there's Ted's
Second Law, "Too many system administrators don't do backups".  This
is because most system admins are users who've never been trained to
be a sysadmin, or who haven't (yet) had weeks or months of works
disappear after a hardware failure.  

So it's a matter of matching the filesystem to the needs of the user.
If you have a filesystem which is blazingly fast, but which at the
slightest sign of trouble, trashes your data, versus one which is fast
but perhaps not-so-fast as the other filesystem, but which is much
more reliable, which would you choose?  

XFS has similar issues where it assumes that hardware has powerfail
interrupts, and that the OS can use said powerfail interrupt to stop
DMA's in its tracks on an power failure, so that you don't have
garbage written to key filesystem data structures when the memory
starts suffering from the dropping voltage on the power bus faster
than the DMA engine or the disk drives.  So XFS is a great filesystem
--- but you'd better be running it on a UPS, or on a system which has
power fail interrupts and an OS that knows what to do.  Ext3, because
it does physical block journalling, does not suffer from this problem.
(Yes, Resierfs uses logical journalling as well, so it suffers from
the same problem.)

So perhaps it's not the job of the FS vendor to be responsible for
crap hardware or lazy sysadmins that don't do backups.  But a system
administrator who knows that he doesn't do backups frequently enough,
or is running on cheap, crap hardware, would be wise to consider
carefully which filesystem he/she wants to use given the systems
configuration and his backup habits.  

Me, I'll go for the robust filesystem, just on general principles.  As
a friend from the large-scale enterprise storage world once put it,
"Performance is Job 2.  Robustness is Job #1."  (Of course, if you
want to put your fragile filesystem on a multi-million dollar
enterprise storage system such as an IBM Shark or an EMC Symmetrix
box, I'm sure IBM or EMC will be happy to sell you one.  :-)

							- Ted

Re: reiser4 plugins

[Hans Reiser]

Steve, there is a remark about XFS below which you are going to be more
expert on.

Theodore Ts'o wrote:

>Most Linux users are using PC-class hardware.  And Ted's First Law of
>PC-Class Hardware is: "Most of it is crap".  And then there's Ted's
>Second Law, "Too many system administrators don't do backups".  This
>is because most system admins are users who've never been trained to
>be a sysadmin, or who haven't (yet) had weeks or months of works
>disappear after a hardware failure.  
>  
>
The above I agree with.  Your words below though are irresponsible.

I get users who tell me that ext* is crap and fsck.ext2 corrupted their
filesystem and thats why they use ReiserFS.  A difference between us is
that I tell them that with all the major linux filesystems (I include
XFS and JFS in this)  it is by this time far more likely to be hardware
that caused corruption than the filesystem software, whereas I guess you
tell them something else.

Describing us as trashing data at the slightest sign of trouble is
irresponsible.  We do block journaling not logical journaling, but there
is absolutely nothing inherently wrong with logical journaling, and no
reason why it could not be just as robust if that is what XFS uses, so I
suspect the rest of your remarks about XFS are unlikely to be sound.

I would say much more, but I am trying to avoid flames this week.

Ted, please try to consider that maybe your competitors also do a fairly
good job at the mundane but important aspects of filesystem work, and
lets all avoid FUDing each others work.  Both ext* and XFS are excellent
filesystems, and Linux is lucky to have 3 of the 4 best filesystems
available for it.

It will be interesting to see though whether Dominic Giampaolo beats all
three of us in the next five years.  He probably won't have the
performance, but he sure might have the semantic features, and he is
very bright.  If MS ever makes good use of the talent they have been
hiring, we'll have a hard time there also.  We may get lucky on that
though.....;-)

>So it's a matter of matching the filesystem to the needs of the user.
>If you have a filesystem which is blazingly fast, but which at the
>slightest sign of trouble, trashes your data, versus one which is fast
>but perhaps not-so-fast as the other filesystem, but which is much
>more reliable, which would you choose?  
>
>XFS has similar issues where it assumes that hardware has powerfail
>interrupts, and that the OS can use said powerfail interrupt to stop
>DMA's in its tracks on an power failure, so that you don't have
>garbage written to key filesystem data structures when the memory
>starts suffering from the dropping voltage on the power bus faster
>than the DMA engine or the disk drives.  So XFS is a great filesystem
>--- but you'd better be running it on a UPS, or on a system which has
>power fail interrupts and an OS that knows what to do.  Ext3, because
>it does physical block journalling, does not suffer from this problem.
>(Yes, Resierfs uses logical journalling as well, so it suffers from
>the same problem.)
>
>So perhaps it's not the job of the FS vendor to be responsible for
>crap hardware or lazy sysadmins that don't do backups.  But a system
>administrator who knows that he doesn't do backups frequently enough,
>or is running on cheap, crap hardware, would be wise to consider
>carefully which filesystem he/she wants to use given the systems
>configuration and his backup habits.  
>
>Me, I'll go for the robust filesystem, just on general principles.  As
>a friend from the large-scale enterprise storage world once put it,
>"Performance is Job 2.  Robustness is Job #1."  (Of course, if you
>want to put your fragile filesystem on a multi-million dollar
>enterprise storage system such as an IBM Shark or an EMC Symmetrix
>box, I'm sure IBM or EMC will be happy to sell you one.  :-)
>
>							- Ted
>
>
>  
>

Re: reiser4 plugins

[Theodore Ts'o]

On Mon, Jun 27, 2005 at 12:46:23PM -0700, Hans Reiser wrote:
> A difference between us is
> that I tell them that with all the major linux filesystems (I include
> XFS and JFS in this)  it is by this time far more likely to be hardware
> that caused corruption than the filesystem software, whereas I guess you
> tell them something else.

Oh, I agree with this, and I do tell people that.  The question though
is how the filesystem recovers from said hardware-caused corruption
once it does happen.  You've admitted that reiserfs3 has less than
optimal recovery characteristics from hardware-induced corruptions if
said filesystem contains reiserfs filesystem images; that would be an
example of a filesystem not being as robust as it could be.  (It'll be
interesting to see if SuSE will support reiserfsv3 in combination with
the Xen hypervisor or other virtualization systems, which makes use of
filesystem images.)  Another example would be DMA'ing garbage into the
hard drive after a power failure --- how does a filesystem respond to
this eventuality?

You probably hear more stories people who got unlucky with
hardware-induced corruptions with ext2/3, and I probably hear more
from users who have sworn off of reiserfs just because are sample sets
are somewhat biased.  Such are the dangers of relying on anecdotal
evidence.

However, logically speaking, if a filesystem is designed such that in
certain cases, the fsck program has to brute-force search every single
disk block looking for data structures that _look_ like they might be
part of the filesystem data, well, that's always going to be more
error prone than one where the filesystem metadata is in
easily-predicted locations.  It sounds like you've added some more
checks in reiser4, and that's definitely a good thing.  Time will tell
whether they are sufficient or not.

Regards,

						- Ted

Re: reiser4 merging action list

[Hans Reiser]

Andrew asked me to put together a list of things that need to be done
before merging:

    * VFS will dispatch directly to the method of the plugin for the
*_operations methods.  This requires duplicating to all plugin methods
the common code currently used by all reiser4 plugins for a given
method.  It has the desirable side effect of making the methods more
fully self-contained, which is somethng I had wanted two years ago and
was a little sad to not get, and the cost of duplicating some code. 
Since not all plugin methods are *_operations, it means we have two
structures with duplicated data, and duplicate data that must be in sync
at all times is classical badness in programming technique (see Codd and
normalization).                                 vs owns this task

    * review all sparse complaints, and revise as appropriate. 

    * panic and code beauty: everyone agrees that having function, file,
and line added to reiser4_panic output hurts nothing (I hope).  Everyone
agrees that restarting the machine without an error message seems like a
useless option to allow.   Much else was argued, not sure if anything
was a consensus view.  Various detail improvements were suggested by
Pecca, and I agreed with half of them.


   * metafiles should be disabled until we can present code that works
right.  Half the list thinks we cannot solve the cycles problem ever. 
Disable metafiles and postpone problem until working code, or the
failure to produce it, makes it possible to do more than rant at each
other.  This is currently already done in the -mm patches, but is
mentioned lest someone think it forgotten.

   * update the locking documentation

Probably I forget something.

Best,

Hans

Re: reiser4 merging action list

[Andrew Morton]

Hans Reiser <reiser@namesys.com> wrote:
>
> 
> Andrew asked me to put together a list of things that need to be done
> before merging:

Thanks.

As I said to Hans, if we can get a list of bullet-point actions nailed down
and agreed to then we have an uncontroversial path to happiness and a
merge.  Let's get down and concentrate on technical specifics.

Hans, please maintain this list and republish it as we work through things.

>     * VFS will dispatch directly to the method of the plugin for the
> *_operations methods.  This requires duplicating to all plugin methods
> the common code currently used by all reiser4 plugins for a given
> method.  It has the desirable side effect of making the methods more
> fully self-contained, which is somethng I had wanted two years ago and
> was a little sad to not get, and the cost of duplicating some code. 
> Since not all plugin methods are *_operations, it means we have two
> structures with duplicated data, and duplicate data that must be in sync
> at all times is classical badness in programming technique (see Codd and
> normalization).                                 vs owns this task
> 
>     * review all sparse complaints, and revise as appropriate. 
> 
>     * panic and code beauty: everyone agrees that having function, file,
> and line added to reiser4_panic output hurts nothing (I hope).  Everyone
> agrees that restarting the machine without an error message seems like a
> useless option to allow.   Much else was argued, not sure if anything
> was a consensus view.  Various detail improvements were suggested by
> Pecca, and I agreed with half of them.
> 
> 
>    * metafiles should be disabled until we can present code that works
> right.  Half the list thinks we cannot solve the cycles problem ever. 
> Disable metafiles and postpone problem until working code, or the
> failure to produce it, makes it possible to do more than rant at each
> other.  This is currently already done in the -mm patches, but is
> mentioned lest someone think it forgotten.
> 
>    * update the locking documentation
> 

There's also the custom list, hash and debug code.  We should either

a) remove them or

b) generify them and submit as standalone works or

c) justify them as custom-to-reiser4 and leave them as-is.

Re: reiser4 merging action list

[Hans Reiser]

Andrew Morton wrote:

>Hans Reiser <reiser@namesys.com> wrote:
>  
>
>>Andrew asked me to put together a list of things that need to be done
>>before merging:
>>    
>>
>
>Thanks.
>
>As I said to Hans, if we can get a list of bullet-point actions nailed down
>and agreed to then we have an uncontroversial path to happiness and a
>merge.  Let's get down and concentrate on technical specifics.
>
>Hans, please maintain this list and republish it as we work through things.
>
>  
>
>>    * VFS will dispatch directly to the method of the plugin for the
>>*_operations methods.  This requires duplicating to all plugin methods
>>the common code currently used by all reiser4 plugins for a given
>>method.  It has the desirable side effect of making the methods more
>>fully self-contained, which is somethng I had wanted two years ago and
>>was a little sad to not get, and the cost of duplicating some code. 
>>Since not all plugin methods are *_operations, it means we have two
>>structures with duplicated data, and duplicate data that must be in sync
>>at all times is classical badness in programming technique (see Codd and
>>normalization).                                 vs owns this task
>>
>>    * review all sparse complaints, and revise as appropriate. 
>>
>>    * panic and code beauty: everyone agrees that having function, file,
>>and line added to reiser4_panic output hurts nothing (I hope).  Everyone
>>agrees that restarting the machine without an error message seems like a
>>useless option to allow.   Much else was argued, not sure if anything
>>was a consensus view.  Various detail improvements were suggested by
>>Pecca, and I agreed with half of them.
>>
>>
>>   * metafiles should be disabled until we can present code that works
>>right.  Half the list thinks we cannot solve the cycles problem ever. 
>>Disable metafiles and postpone problem until working code, or the
>>failure to produce it, makes it possible to do more than rant at each
>>other.  This is currently already done in the -mm patches, but is
>>mentioned lest someone think it forgotten.
>>
>>   * update the locking documentation
>>
>>    
>>
>
>There's also the custom list, hash and debug code.  We should either
>
>a) remove them or
>
>b) generify them and submit as standalone works or
>
>c) justify them as custom-to-reiser4 and leave them as-is.
>
>
>
>
>  
>
either b) or c) is ok with me for the list code.  The debug code should
be c) I think.

Probably vs can offer a more detailed and accurate opinion,

Hans

Re: reiser4 merging action list

[Pekka Enberg]

Andrew Morton wrote:
> > There's also the custom list, hash and debug code.  We should either
> >
> > a) remove them or
> >
> > b) generify them and submit as standalone works or
> >
> > c) justify them as custom-to-reiser4 and leave them as-is.

On 6/29/05, Hans Reiser <reiser@namesys.com> wrote:
> either b) or c) is ok with me for the list code.  The debug code should
> be c) I think.
> 
> Probably vs can offer a more detailed and accurate opinion,

I completely agree that the current state of the generic hashing
facilities is somewhat poor but I fail to see why you can't use
<linux/list.h>.

As for the debugging code, I would love to see that turned into
something generic (every subsystem has their own now) but it is
definitely not something that should stop you from merging.

                                Pekka

Re: reiser4 merging action list

[Hans Reiser]

Pekka Enberg wrote:

>Andrew Morton wrote:
>  
>
>>>There's also the custom list, hash and debug code.  We should either
>>>
>>>a) remove them or
>>>
>>>b) generify them and submit as standalone works or
>>>
>>>c) justify them as custom-to-reiser4 and leave them as-is.
>>>      
>>>
>
>On 6/29/05, Hans Reiser <reiser@namesys.com> wrote:
>  
>
>>either b) or c) is ok with me for the list code.  The debug code should
>>be c) I think.
>>
>>Probably vs can offer a more detailed and accurate opinion,
>>    
>>
>
>I completely agree that the current state of the generic hashing
>facilities is somewhat poor but I fail to see why you can't use
><linux/list.h>.
>  
>
I'll let vs and maybe nikita comment.

>As for the debugging code, I would love to see that turned into
>something generic (every subsystem has their own now) but it is
>definitely not something that should stop you from merging.
>
>                                Pekka
>
>
>  
>
If I encourage you to make a patch, is that ok of me? 

Re: reiser4 merging action list

[Christoph Hellwig]

On Mon, Jun 27, 2005 at 04:00:01PM -0700, Hans Reiser wrote:
> 
> Andrew asked me to put together a list of things that need to be done
> before merging:

...

> Probably I forget something.

I've started to do a very basic look over the tree and there's a few
more things that spring to mind:

 - cpp abuse.  There's quite a lot of really odd macros - the typesafe_list,
   typesafe_hash stuff is mentioned already, but there's really horrible
   stuff like _INIT_ and _DONE_ bits in init_super.c, and the wrappers for
   plugin method invocations.
 - endianess handling.  The d* types are a lovely attempt to make sure
   you're not missing endianess conversions.  We have a more general
   way to ensure that now using sparse, that's the __le* / __be* types.
   Try running sparse -Wbitwise to find places you'll need that annotations
   (after the normal sparse warnings are fixed, else you'll have a hard
   time seeing them I guess) - after that the single element struct thing
   can go away.  Also you're defining a CPU_IN_DISK_ORDER macro that's
   never used..
 - lease use kthread_* instead of kernel_thread() + lots of opencoding

Re: reiser4 merging action list

[Adrian Bunk]

On Mon, Jun 27, 2005 at 04:00:01PM -0700, Hans Reiser wrote:
> 
> Andrew asked me to put together a list of things that need to be done
> before merging:
>...
> Probably I forget something.


  * remove the dependency on !4KSTACKS


> Best,
> 
> Hans

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed