From: Chris Gentile <cnjgentile@gmail.com>
To: Ivan Shapovalov <intelfx100@gmail.com>
Cc: Edward Shishkin <edward.shishkin@gmail.com>,
reiserfs-devel <reiserfs-devel@vger.kernel.org>
Subject: Quick update
Date: Tue, 17 Sep 2013 17:26:48 +0000 [thread overview]
Message-ID: <523890D8.1080407@gmail.com> (raw)
In-Reply-To: <523614FD.6010708@gmail.com>
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
>
next prev parent reply other threads:[~2013-09-17 17:26 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-06 5:36 Reiser4 for 3.11 Ivan Shapovalov
2013-09-09 10:44 ` Edward Shishkin
2013-09-09 10:53 ` Ivan Shapovalov
2013-09-15 19:37 ` Edward Shishkin
2013-09-15 19:51 ` Ivan Shapovalov
2013-09-15 20:13 ` Chris Gentile
2013-09-17 17:26 ` Chris Gentile [this message]
-- strict thread matches above, loose matches on Subject: below --
2011-04-21 4:55 quick update Sage Weil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=523890D8.1080407@gmail.com \
--to=cnjgentile@gmail.com \
--cc=edward.shishkin@gmail.com \
--cc=intelfx100@gmail.com \
--cc=reiserfs-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.