reiser4 patches and todo list

reiser4 patches and todo list

[doiggl]

Hello,
Questions:
- Are there any plans for a reiser4 patch for Linux kernel 3.2/3.1/3.0
series ?
- Has the reiser4 todo list changed since 2009 [1] ?

[1]
https://reiser4.wiki.kernel.org/articles/t/o/d/TODO_b7b1.html

Thanks Glenn

Re: reiser4 patches and todo list

[Edward Shishkin]

On 01/05/2012 11:51 AM, doiggl@velocitynet.com.au wrote:
> Hello,
> Questions:
> - Are there any plans for a reiser4 patch for Linux kernel 3.2/3.1/3.0
> series ?

Maybe for 3.2, but not sure..

fs-writeback has been changed a lot and I don't have a time to adjust
reiser4 to every stupid VFS change. Anybody care to? I'll provide the 
hints..

Thanks,
Edward.

> - Has the reiser4 todo list changed since 2009 [1] ?
>
> [1]
> https://reiser4.wiki.kernel.org/articles/t/o/d/TODO_b7b1.html
>
> Thanks Glenn
>
> --
> To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: reiser4 patches and todo list

[Edward Shishkin]

On 01/05/2012 08:33 PM, Marcin Baczyński wrote:
> 2012/1/5 Edward Shishkin<edward.shishkin@gmail.com>:
>> On 01/05/2012 11:51 AM, doiggl@velocitynet.com.au wrote:
>>>
>>> Hello,
>>> Questions:
>>> - Are there any plans for a reiser4 patch for Linux kernel 3.2/3.1/3.0
>>> series ?
>>
>>
>> Maybe for 3.2, but not sure..
>>
>> fs-writeback has been changed a lot and I don't have a time to adjust
>> reiser4 to every stupid VFS change. Anybody care to? I'll provide the
>> hints..
>>
>
> Well, if you have patience to provide the hints for somebody with little
> kernel experience and who is just learning how the internals of VFS
> work than I think I can do it :]


Ok, I think that adjusting reiser4 to 3.2 would be a good start.

Unlike other file systems reiser4's ->writepages() address space
operation doesn't actually write pages to disk. Instead
reiser4_writepages() puts them into a transaction (actually it
takes place for so-called "anonymous" pages, dirtied via mmap).

So with every portion of writeback-ed inodes we also need in addition
to call reiser4_writeout().

Such slight inconsistency with VFS semantic was fixed via introducing
a new super operation ->writeback_inodes(), so that 
reiser4_writeback_inodes() makes sure that everything is written
properly (see patches 0-7 for details):

http://marc.info/?l=reiserfs-devel&m=126507575609892&w=2
http://marc.info/?l=reiserfs-devel&r=1&b=201002&w=2

The following 6 patches adjusts reiser4 to further changes in
fs-writeback:

http://marc.info/?l=reiserfs-devel&r=1&b=201007&w=2

And now (in 3.1) fs-writeback.c got changed again. Specifically,
semantic of writeback_sb_inodes(), the "implicit" ->writeback_inodes()
super operation, has been changed: now it writes not necessarily all
inodes of a superblock. As a result It'll break reiser4_sync_fs() and
reiser4's entd worker semantic, which require _all_ inodes of reiser4
superblock to be writeback-ed.

So I guess we need a version of writeback_sb_inodes(), which writes 
(optionally) _all_ inodes of a superblock.

Note, that fs-writeback is a single pain in the ass: in other bits
reiser4 is perfectly coherent with VFS.


>
> BTW is there any chance that R4 will be merged into Linus' tree?


Merging upstream has mostly marketing/political aspects which would
mean additional burden for me personally.

Who cares to merge it with upstream? It might be important for some
vendor, who is ready to pay money for reiser4 development.

Perhaps we'll consider possibility of merging, but not now.
Now, when I spend my weekends for reiser4, I would prefer to
concentrate on scientific aspects of file system development.

Edward.


> Or that known bugs will get fixed? Following this list, one can get an
> impression that R4 is in a maintenance-only mode...

>>
>>
>>> - Has the reiser4 todo list changed since 2009 [1] ?
>>>
>>> [1]
>>> https://reiser4.wiki.kernel.org/articles/t/o/d/TODO_b7b1.html
>>>
>>> Thanks Glenn
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: reiser4 patches and todo list

[Edward Shishkin]

On 02/08/2012 08:40 PM, Marcin Baczyński wrote:
> W dniu 8 stycznia 2012 14:53 użytkownik Edward Shishkin
> <edward.shishkin@gmail.com>  napisał:
>> On 01/05/2012 08:33 PM, Marcin Baczyński wrote:
>>>
>>> 2012/1/5 Edward Shishkin<edward.shishkin@gmail.com>:
>>>>
>>>> On 01/05/2012 11:51 AM, doiggl@velocitynet.com.au wrote:
>>>>>
>>>>>
>>>>> Hello,
>>>>> Questions:
>>>>> - Are there any plans for a reiser4 patch for Linux kernel 3.2/3.1/3.0
>>>>> series ?
>>>>
>>>>
>>>>
>>>> Maybe for 3.2, but not sure..
>>>>
>>>> fs-writeback has been changed a lot and I don't have a time to adjust
>>>> reiser4 to every stupid VFS change. Anybody care to? I'll provide the
>>>> hints..
>>>>
>>>
>>> Well, if you have patience to provide the hints for somebody with little
>>> kernel experience and who is just learning how the internals of VFS
>>> work than I think I can do it :]
>>
>>
>>
>> Ok, I think that adjusting reiser4 to 3.2 would be a good start.
>>
>> Unlike other file systems reiser4's ->writepages() address space
>> operation doesn't actually write pages to disk. Instead
>> reiser4_writepages() puts them into a transaction (actually it
>> takes place for so-called "anonymous" pages, dirtied via mmap).
>>
>> So with every portion of writeback-ed inodes we also need in addition
>> to call reiser4_writeout().
>>
>> Such slight inconsistency with VFS semantic was fixed via introducing
>> a new super operation ->writeback_inodes(), so that
>> reiser4_writeback_inodes() makes sure that everything is written
>> properly (see patches 0-7 for details):
>>
>> http://marc.info/?l=reiserfs-devel&m=126507575609892&w=2
>> http://marc.info/?l=reiserfs-devel&r=1&b=201002&w=2
>>
>> The following 6 patches adjusts reiser4 to further changes in
>> fs-writeback:
>>
>> http://marc.info/?l=reiserfs-devel&r=1&b=201007&w=2
>>
>> And now (in 3.1) fs-writeback.c got changed again. Specifically,
>> semantic of writeback_sb_inodes(), the "implicit" ->writeback_inodes()
>> super operation, has been changed: now it writes not necessarily all
>> inodes of a superblock. As a result It'll break reiser4_sync_fs() and
>> reiser4's entd worker semantic, which require _all_ inodes of reiser4
>> superblock to be writeback-ed.
>>
>> So I guess we need a version of writeback_sb_inodes(), which writes
>> (optionally) _all_ inodes of a superblock.
>>
>> Note, that fs-writeback is a single pain in the ass: in other bits
>> reiser4 is perfectly coherent with VFS.
>>
>
> Ok, so attached is my attempt to port the 2.6.39-1 path to the 3.2 kernel.


Great!
I'll take a look for details a bit later..


> I'm not sure if I got the writeback parts right, so please take a closer look
> at them and tell me if I missed or misunderstood something.
> The code is probably closer to ugly than to pretty around converting
> struct wb_writeback_work to writeback_control and back again right now.
> I'll clean this up if that code does what it should.
>
> Another thing I don't know what to do with are the new start and end
> arguments to reiser4_sync_common. Currently they are ignored, which
> I think results in always syncing everything.


You are right: we can not fsync specified range, at least in the current
transaction model.
The best we can do is figure out what atom contains specified page
and commit it (that is exactly what the entd worker tries to do).

Thank you,
Edward.


>
> With this patch, Reiser4 compiles as a module or builtin, and is able to
> do some simple operations on a filesystem. I tried copying some rather
> large directories to and on the filesystem, but that's pretty much all the
> testing I have done, so if the kconfig option was marked as 'experimental',
> it probably should be 'highly experimental' by now :)
>

--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: reiser4 patches and todo list

[Edward Shishkin]

[...]
On 01/08/2012 04:43 PM, Daniel Horne wrote:
>
>
>         Your patch for 2.6.39-1 seems to compile fine on 3.0, but not on
>         3.1 or
>         3.2. The problem seems to be that the patch re-adds the
>         PF_FLUSHER flag
>         to the sched.h, as it relies on it, but on 3.1 and on that
>         flag's value
>         is used for the PF_NPROC_EXCEEDED flag.
>
>         I'd be tempted to to swap the PF_FLUSHER check for PF_SWAPWRITE,
>         as all
>         kthreads that set PF_FLUSHER also set PF_SWAPWRITE, but there'd
>         be some
>         false-positives there and I'm not sure what effect this would have.
>
>
>     Hello Daniel,
>
>     I don't see any PF_FLUSHER flag in vanilla 3.2, so it shouldn't
>     be an issue.
>
>     There is one more problem with 3.X. I have described it here:
>     http://marc.info/?l=reiserfs-__devel&m=132603099732236&w=2
>     <http://marc.info/?l=reiserfs-devel&m=132603099732236&w=2>
>
>     Thanks,
>     Edward.
>
>
>
> There isn't a PF_FLUSHER, but the value it used to have is now defined
> as PF_NPROC_EXCEEDED.

Ah, you are right.

> I suppose we could define PF_FLUSHER to be 0x00080000, as that doesn't
> seem to be taken.

Yes, that's the way.
We need to make sure that task is a flusher, so I think using
PF_SWAPWRITE for this purpose is not a good idea..

Thanks!
Edward.