Re: Formal Reiser4 inclusion and todo list?

Re: Formal Reiser4 inclusion and todo list?

[Christian Stroetmann]

Hi Glenn;

On the 28.07.2010 21:58, I wrote:
> Aloha Glenn;
>
> At the 28.07.2010 17:21, you (doiggl@velocitynet.com.au) wrote:
>>> The following items are still unaddressed:
>>>
>>> 1. running igrab() in the writepage() path is really going to hammer
>>>     inode_lock.  Something else will need to be done here.
>>>
>>> 2. Running iput() in entd() is a bit surprising.  iirc there are 
>>> various
>>> ways
>>>     in which this can recur into the filesystem, perform I/O, etc.  I
>>> guess it
>>>     works..
>>>     But again, it will hammer inode_lock.
>>>
>>> 3. the writeout logic in entd_flush() is interesting (as in "holy 
>>> cow").
>>>     It's very central and really needs some good comments describing
>> what's
>>>     going on in there - what problems are being solved, which decisions
>> were
>>>     taken and why, etc.
>>>
>>> 4. reiser4_wait_page_writeback() needs commenting.
>>>
>>> 5. reading the comment in txnmgr.c regarding MAP_SHARED pages: a number
>> of
>>>     things have changed since then.  We have page-becoming-writeable
>>>     notifications and probably soon we'll always take a pagefault 
>>> when a
>>>     MAP_SHARED page transitions from pte-clean to pte-dirty (although I
>>> wouldn't
>>>     recommend that a filesystem rely upon the latter for a while yet).
>>>
>>> Feel free to address them.
>>>
>>> Thanks,
>>> Edward.
>> Has the number of items reduced at all ?
>> just curious
>> Cheers Glenn
>
> I haven't looked at the code since several years. But as far as I have 
> followed the development, all of the patch sets since then (April 
> 2009) were only of cosmetical nature, or said with other words, to 
> keep it coping with changes at different positions, like eg. VFS.
> And in a handful of blogs I got no additional/other informations, 
> despite that the maintainer is working at a company in the field of 
> another file system since the end of last year, so that he has only 
> few time for Reiser FSs, and also that the opinions are that the 
> project is dead.
>

We also found out that, like the ReiserFS maintainer, the starter of 
this thread, who is also the starter and maintainer of the ReiserFS wiki 
as well as the filler of the ReiserFS wiki with copyrighted materials, 
has changed to the development of the Btrfs file system, too. For 
example in June he made a patch with:

-	tristate "Btrfs filesystem (EXPERIMENTAL) Unstable disk format"
-	depends on EXPERIMENTAL
+	tristate "Btrfs filesystem"

so that "Btrfs is highly experimental" could be substituted with "Btrfs 
is under heavy development".

Again, this gives something to think about the engagement of the person, 
as well. We always had the impression that he, like a handful of other 
persons, was only here at reiserfs to mess up the R4 development, to 
work and make politics against this project, and to disturb the 
developers and their businesses.
Btw.: In the case of copying copyrighted materials into the ReiserFS 
wiki the kernel.org administrator was already informed by us, but 
explained that it's up to [Hans Reiser] to ask for removing these 
materials from kernel.org, which is an argumentation we are unable to 
understand, because the kernel.org administrator does know that 
copyrighted materials are illegally publicated on the kernel.org website.

Cheerio
Christian *<:o)   O>-<   -(D)>-<

Re: Formal Reiser4 inclusion and todo list?

[Nick Piggin]

On Sun, Aug 01, 2010 at 03:43:05PM +0200, Christian Stroetmann wrote:
> Hi Glenn;
> 
> On the 28.07.2010 21:58, I wrote:
> >Aloha Glenn;
> >
> >At the 28.07.2010 17:21, you (doiggl@velocitynet.com.au) wrote:
> >>>The following items are still unaddressed:
> >>>
> >>>1. running igrab() in the writepage() path is really going to hammer
> >>>    inode_lock.  Something else will need to be done here.
> >>>
> >>>2. Running iput() in entd() is a bit surprising.  iirc there
> >>>are various
> >>>ways
> >>>    in which this can recur into the filesystem, perform I/O, etc.  I
> >>>guess it
> >>>    works..
> >>>    But again, it will hammer inode_lock.

inode_lock should be going away within 6 months or so, with the
vfs-scaling developments (see linux-fsdevel).

Inode refcounting becomes very light-weight, as it should be.


> >>>3. the writeout logic in entd_flush() is interesting (as in
> >>>"holy cow").
> >>>    It's very central and really needs some good comments describing
> >>what's
> >>>    going on in there - what problems are being solved, which decisions
> >>were
> >>>    taken and why, etc.
> >>>
> >>>4. reiser4_wait_page_writeback() needs commenting.
> >>>
> >>>5. reading the comment in txnmgr.c regarding MAP_SHARED pages: a number
> >>of
> >>>    things have changed since then.  We have page-becoming-writeable
> >>>    notifications and probably soon we'll always take a
> >>>pagefault when a
> >>>    MAP_SHARED page transitions from pte-clean to pte-dirty (although I
> >>>wouldn't
> >>>    recommend that a filesystem rely upon the latter for a while yet).

It is now possible to trap all dirtying activity from all sources
except get_user_pages (but filesystems tend to ignore that little
problem).

Re: Formal Reiser4 inclusion and todo list?

[Edward Shishkin]

Nick Piggin wrote:
> On Sun, Aug 01, 2010 at 03:43:05PM +0200, Christian Stroetmann wrote:
>   
>> Hi Glenn;
>>
>> On the 28.07.2010 21:58, I wrote:
>>     
>>> Aloha Glenn;
>>>
>>> At the 28.07.2010 17:21, you (doiggl@velocitynet.com.au) wrote:
>>>       
>>>>> The following items are still unaddressed:
>>>>>
>>>>> 1. running igrab() in the writepage() path is really going to hammer
>>>>>    inode_lock.  Something else will need to be done here.
>>>>>
>>>>> 2. Running iput() in entd() is a bit surprising.  iirc there
>>>>> are various
>>>>> ways
>>>>>    in which this can recur into the filesystem, perform I/O, etc.  I
>>>>> guess it
>>>>>    works..
>>>>>    But again, it will hammer inode_lock.
>>>>>           
>
> inode_lock should be going away within 6 months or so, with the
> vfs-scaling developments (see linux-fsdevel).
>   

Yup, I keep a track of your efforts,
it would be nice..

> Inode refcounting becomes very light-weight, as it should be.
>
>
>   
>>>>> 3. the writeout logic in entd_flush() is interesting (as in
>>>>> "holy cow").
>>>>>    It's very central and really needs some good comments describing
>>>>>           
>>>> what's
>>>>         
>>>>>    going on in there - what problems are being solved, which decisions
>>>>>           
>>>> were
>>>>         
>>>>>    taken and why, etc.
>>>>>
>>>>> 4. reiser4_wait_page_writeback() needs commenting.
>>>>>
>>>>> 5. reading the comment in txnmgr.c regarding MAP_SHARED pages: a number
>>>>>           
>>>> of
>>>>         
>>>>>    things have changed since then.  We have page-becoming-writeable
>>>>>    notifications and probably soon we'll always take a
>>>>> pagefault when a
>>>>>    MAP_SHARED page transitions from pte-clean to pte-dirty (although I
>>>>> wouldn't
>>>>>    recommend that a filesystem rely upon the latter for a while yet).
>>>>>           
>
> It is now possible to trap all dirtying activity from all sources
> except get_user_pages (but filesystems tend to ignore that little
> problem).
>   

Thanks for looking at this.

Edward.

Re: Formal Reiser4 inclusion and todo list?

[Christian Stroetmann]

Hello Ralph;
On the 02.08.2010 16:30, you wrote:
> Christian Stroetmann 2010-08-01 15:43:
>    
>>> I haven't looked at the code since several years. But as far as I
>>> have followed the development, all of the patch sets since then
>>> (April 2009) were only of cosmetical nature, or said with other
>>> words, to keep it coping with changes at different positions, like
>>> eg. VFS. And in a handful of blogs I got no additional/other
>>> informations, despite that the maintainer is working at a company in
>>> the field of another file system since the end of last year, so that
>>>        
> ...
>    
>> We always had the impression that he, like a handful
>> of other persons, was only here at reiserfs to mess up the R4
>> development, to work and make politics against this project, and to
>> disturb the developers and their businesses.
>>      
> I would like to thank E. Shishkin for his efforts to keep Reiser4
> breathing. I never had the impression someone wants to disturb
> development....
>
>    

That is a problematic part of IT-business, and insights, feelings and 
experiences for and in such situations can be best developed, if someone 
is directly involved.

>>> , and also that the opinions are that the project is dead.
>>>        
> I see an amount of features went into btrfs. And the skills of former
> Reiser4 developers also. Also Shishkin did his expertise on btrfs.

Yes

>   What
> never was discussed during efforts to get Reiser4 into mainline kernel
> development:
>
> The potentials of a never coming Reiser5 regarding semantics.
>    

Sorry Ralph, but: No, that's not right.
What we did is exactly what you have mentioned: We gave it ontologics, 
which includes semantics and ontology based semantics. Or let say it 
with other words: Our [....]FS is based on R4 and could be described 
very rough as H. Reisers vision of the further development of R4 in a 
Semantic[/Ontologic] Web style, which could be seen as the R5 you 
mentioned, but has now another name that fits better with semantics and 
ontologics.
And we have explained such a semantic feature in a discussion on this 
mailing list. But just right from the start we got the advice by the 
actual maintainer:
"Go away!"
Later, we were also heavily attacked by other members of this mailing 
list with statements like "stealing", "that's rude" and so on.
Since then we are not allowed to talk about our R4 based fork.

Please read also this whole thread again, especially the messages of the 
days 19.04.2009 and 20.04.2009.

> - As one can see at Christian Stroetmanns sites he has done some
> thinking that direction.
>    

We hade started around the 1995s while no one was really interesting in 
these kind of semantic, ontologic and ontology based technologies.
And we have not done some thinking, it was in fact much more.

> - As one can see watching the Nepomuk development, semantic development
> is hard, unprecedented and therefore has a very slowly ongoing.
>    

Sorry again, but: No, that's not right. The EU-funded research project 
Nepomuk is largely based on stolen technologies from my company (eg. 
ontology for file system). After the presentation of our Linux based 
distribution with an R4 forked file system, that we are not allowed to 
mention here, and the ending of the monetary support of the related 
research project with tax money we gave only in small steps new 
informations about our technology so that it couldn't be stolen further 
by that project, members of the project, a newer project, a company, or 
others. That's the real reason and has nothing to do with the technology 
itself, but in fact more with international governmental and industrial 
issues. Or said with oher words: We have the thumb on it.
Please, understand all that this kind of technologies, including R4, are 
no kindergarden games.

> Development of an all purpose filesystem mixed with an all purpose
> semantic feature seems to be too big of a challange yet.

We have to say sorry once again, but: No, that's wrong. Our R4 based 
file system is not only conceptually ready since 2006.

> Me, non developer, would faczinate a revived Reiser4 as a fuse-
> filesystem for experimental storage ideas! Some sort of database? A
> Nepomuk storage backend? I wonder if some NoSql projects out there have
> reimplemented Reiser4 techniques?
>    

Sorry, but: Our R4 and NoSql based file system is not only conceptually 
ready since 2006. Also, we had developed it, because several FUSE based 
approaches exist for these kinds of applications, but are to slow or not 
consistent from the point of view of their architectures. R4 has several 
features that fit exactly and a FUSE based R4 makes really no sense, 
because it is already a file system. Believe us, we were already there 
more than 8 years ago.

If the explanations were to harsh, then we beg for apologize.

With all the best and Yeah
Christian *<:o)   O>-<   -(D)>-<