Hi Glenn;
On the 28.07.2010 21:58, I wrote:
> Aloha Glenn;
>
> At the 28.07.2010 17:21, you ([email protected]) 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)>-<
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 ([email protected]) 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).
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 ([email protected]) 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.