Reiser4 for 3.11

Reiser4 for 3.11

[Ivan Shapovalov]

Hi Edward!

I'm sorry for the silence... The summer, as it usually happens, turned out to 
be not-easier-than-studying-days (personal life and all), so unfortunately 
there is not much progress with TRIM implementation for reiser4. There is some 
code, but it's stability is zero.

Anyway, here is my usual attempt to port reiser4 to next kernel. 3.11 got a 
significant API change (readdir() of file_operations changed to iterate()), 
and I'm unsure if I done that correctly. But it works, unlike TRIM. :)

(FYI, iterate() differs from readdir() mostly in that it works with a copy of 
f_pos instead of with f->f_pos directly.)

Thanks,
Ivan

Re: Reiser4 for 3.11

[Edward Shishkin]

On 09/06/2013 07:36 AM, Ivan Shapovalov wrote:
> Hi Edward!
>
> I'm sorry for the silence... The summer, as it usually happens, turned out to
> be not-easier-than-studying-days (personal life and all), so unfortunately
> there is not much progress with TRIM implementation for reiser4. There is some
> code, but it's stability is zero.
>
> Anyway, here is my usual attempt to port reiser4 to next kernel. 3.11 got a
> significant API change (readdir() of file_operations changed to iterate()),
> and I'm unsure if I done that correctly. But it works, unlike TRIM. :)


Cool. Thanks!!!


>
> (FYI, iterate() differs from readdir() mostly in that it works with a copy of
> f_pos instead of with f->f_pos directly.)


AFAIK they fixed races in readdir() and friends.
I'll take a look at this more carefully...


Edward.

Re: Reiser4 for 3.11

[Ivan Shapovalov]

On Monday 09 September 2013 at 12:44:01, Edward wrote:
> On 09/06/2013 07:36 AM, Ivan Shapovalov wrote:
> > Hi Edward!
> >
> > I'm sorry for the silence... The summer, as it usually happens, turned out to
> > be not-easier-than-studying-days (personal life and all), so unfortunately
> > there is not much progress with TRIM implementation for reiser4. There is some
> > code, but it's stability is zero.
> >
> > Anyway, here is my usual attempt to port reiser4 to next kernel. 3.11 got a
> > significant API change (readdir() of file_operations changed to iterate()),
> > and I'm unsure if I done that correctly. But it works, unlike TRIM. :)
> 
> 
> Cool. Thanks!!!
> 
> 
> >
> > (FYI, iterate() differs from readdir() mostly in that it works with a copy of
> > f_pos instead of with f->f_pos directly.)
> 
> 
> AFAIK they fixed races in readdir() and friends.
> I'll take a look at this more carefully...

Yes, I've seen that reason. I'd be grateful if you could check my patch - because,
again, I could have easily missed something wrt. locking and whether we can modify f->f_pos
in the code that fixes it up when entries are inserted/removed.

- Ivan

> 
> 
> Edward.

Re: Reiser4 for 3.11

[Edward Shishkin]

On 09/09/2013 12:44 PM, Edward Shishkin wrote:
> On 09/06/2013 07:36 AM, Ivan Shapovalov wrote:
>> Hi Edward!
>>
>> I'm sorry for the silence... The summer, as it usually happens, 
>> turned out to
>> be not-easier-than-studying-days (personal life and all), so 
>> unfortunately
>> there is not much progress with TRIM implementation for reiser4. 
>> There is some
>> code, but it's stability is zero.
>>
>> Anyway, here is my usual attempt to port reiser4 to next kernel. 3.11 
>> got a
>> significant API change (readdir() of file_operations changed to 
>> iterate()),
>> and I'm unsure if I done that correctly. But it works, unlike TRIM. :)
>
>
> Cool. Thanks!!!
>
>
>>
>> (FYI, iterate() differs from readdir() mostly in that it works with a 
>> copy of
>> f_pos instead of with f->f_pos directly.)
>
>
> AFAIK they fixed races in readdir() and friends.
> I'll take a look at this more carefully...


Vfs people have introduced a new field (.for_sync) of  struct 
wb_writeback_work,
it should be initialized as 1 in reiser4_sync_fs().

The next comment is that all PF_FOO flags should be "independent". In 
particular,
"compound" values like 0x80000002 are unacceptable for PF_FLUSHER (is it 
clear,
why so?). I would recommend 0x00000001, or 0x00000002.

In other bits the patch looks OK.

Thanks!
Edward.

Re: Reiser4 for 3.11

[Ivan Shapovalov]

On Sunday 15 September 2013 at 21:37:31, Edward wrote:
> On 09/09/2013 12:44 PM, Edward Shishkin wrote:
> > On 09/06/2013 07:36 AM, Ivan Shapovalov wrote:
> >> Hi Edward!
> >>
> >> I'm sorry for the silence... The summer, as it usually happens, 
> >> turned out to
> >> be not-easier-than-studying-days (personal life and all), so 
> >> unfortunately
> >> there is not much progress with TRIM implementation for reiser4. 
> >> There is some
> >> code, but it's stability is zero.
> >>
> >> Anyway, here is my usual attempt to port reiser4 to next kernel. 3.11 
> >> got a
> >> significant API change (readdir() of file_operations changed to 
> >> iterate()),
> >> and I'm unsure if I done that correctly. But it works, unlike TRIM. :)
> >
> >
> > Cool. Thanks!!!
> >
> >
> >>
> >> (FYI, iterate() differs from readdir() mostly in that it works with a 
> >> copy of
> >> f_pos instead of with f->f_pos directly.)
> >
> >
> > AFAIK they fixed races in readdir() and friends.
> > I'll take a look at this more carefully...
> 
> 
> Vfs people have introduced a new field (.for_sync) of  struct 
> wb_writeback_work,
> it should be initialized as 1 in reiser4_sync_fs().

Ah, missed that.

> 
> The next comment is that all PF_FOO flags should be "independent". In 
> particular,
> "compound" values like 0x80000002 are unacceptable for PF_FLUSHER (is it 
> clear,
> why so?). I would recommend 0x00000001, or 0x00000002.

That seems to be a typo... Of course, I know it's a bitmask :)

> 
> In other bits the patch looks OK.
> 
> Thanks!
> Edward.

Thanks for the review! I'll fix the points and send an updated patch shortly.

-- 
Ivan Shapovalov / intelfx /

Re: Reiser4 for 3.11

[Chris Gentile]

On 09/15/13 19:51, Ivan Shapovalov wrote:
> On Sunday 15 September 2013 at 21:37:31, Edward wrote:
>> On 09/09/2013 12:44 PM, Edward Shishkin wrote:
>>> On 09/06/2013 07:36 AM, Ivan Shapovalov wrote:
>>>> Hi Edward!
>>>>
>>>> I'm sorry for the silence... The summer, as it usually happens, 
>>>> turned out to
>>>> be not-easier-than-studying-days (personal life and all), so 
>>>> unfortunately
>>>> there is not much progress with TRIM implementation for reiser4. 
>>>> There is some
>>>> code, but it's stability is zero.
>>>>
>>>> Anyway, here is my usual attempt to port reiser4 to next kernel. 3.11 
>>>> got a
>>>> significant API change (readdir() of file_operations changed to 
>>>> iterate()),
>>>> and I'm unsure if I done that correctly. But it works, unlike TRIM. :)
>>>
>>> Cool. Thanks!!!
>>>
>>>
>>>> (FYI, iterate() differs from readdir() mostly in that it works with a 
>>>> copy of
>>>> f_pos instead of with f->f_pos directly.)
>>>
>>> AFAIK they fixed races in readdir() and friends.
>>> I'll take a look at this more carefully...
>>
>> Vfs people have introduced a new field (.for_sync) of  struct 
>> wb_writeback_work,
>> it should be initialized as 1 in reiser4_sync_fs().
> Ah, missed that.
>
>> The next comment is that all PF_FOO flags should be "independent". In 
>> particular,
>> "compound" values like 0x80000002 are unacceptable for PF_FLUSHER (is it 
>> clear,
>> why so?). I would recommend 0x00000001, or 0x00000002.
> That seems to be a typo... Of course, I know it's a bitmask :)
>
>> In other bits the patch looks OK.
>>
>> Thanks!
>> Edward.
> Thanks for the review! I'll fix the points and send an updated patch shortly.
>

Please forward to me as well if you don't mind?
Thanks!
Chris

Quick update

[Chris Gentile]

Out of curiosity had to try it, attempted compile w/Reiser4 built in
with the first patch I received from Ivan on the new 3.12-rc1.

To nobody's surprise it failed.

Ivan, had you released that new patch by chance with the changes Edward
was mentioning?

Thanks again,
Chris


On 09/15/2013 08:13 PM, Chris Gentile wrote:
> On 09/15/13 19:51, Ivan Shapovalov wrote:
>> On Sunday 15 September 2013 at 21:37:31, Edward wrote:
>>> On 09/09/2013 12:44 PM, Edward Shishkin wrote:
>>>> On 09/06/2013 07:36 AM, Ivan Shapovalov wrote:
>>>>> Hi Edward!
>>>>>
>>>>> I'm sorry for the silence... The summer, as it usually happens, 
>>>>> turned out to
>>>>> be not-easier-than-studying-days (personal life and all), so 
>>>>> unfortunately
>>>>> there is not much progress with TRIM implementation for reiser4. 
>>>>> There is some
>>>>> code, but it's stability is zero.
>>>>>
>>>>> Anyway, here is my usual attempt to port reiser4 to next kernel. 3.11 
>>>>> got a
>>>>> significant API change (readdir() of file_operations changed to 
>>>>> iterate()),
>>>>> and I'm unsure if I done that correctly. But it works, unlike TRIM. :)
>>>> Cool. Thanks!!!
>>>>
>>>>
>>>>> (FYI, iterate() differs from readdir() mostly in that it works with a 
>>>>> copy of
>>>>> f_pos instead of with f->f_pos directly.)
>>>> AFAIK they fixed races in readdir() and friends.
>>>> I'll take a look at this more carefully...
>>> Vfs people have introduced a new field (.for_sync) of  struct 
>>> wb_writeback_work,
>>> it should be initialized as 1 in reiser4_sync_fs().
>> Ah, missed that.
>>
>>> The next comment is that all PF_FOO flags should be "independent". In 
>>> particular,
>>> "compound" values like 0x80000002 are unacceptable for PF_FLUSHER (is it 
>>> clear,
>>> why so?). I would recommend 0x00000001, or 0x00000002.
>> That seems to be a typo... Of course, I know it's a bitmask :)
>>
>>> In other bits the patch looks OK.
>>>
>>> Thanks!
>>> Edward.
>> Thanks for the review! I'll fix the points and send an updated patch shortly.
>>
> Please forward to me as well if you don't mind?
> Thanks!
> Chris
>

quick update

[Sage Weil]

We started a new 'next' branch that will become v0.27 at the end of the 
week.  The 0.27 cycle work can be found at
	http://tracker.newdream.net/projects/1/issues?sort=position
There's also a pile of clustered MDS fixes Greg has been working on that 
mostly landed in 0.27.

We're shooting for 2 weeks for 0.28.  The main items are rgw fixes, a 
libceph cleanup, and a refactor of the OSD peering/recovery code to make 
it more understandable and (presumably) less buggy.

A couple of our devs will be at the openstack developer summit so next 
week may be a bit slow...

sage