Reiser4 Upstream Git Repositories on GitHub

Reiser4 Upstream Git Repositories on GitHub

[Edward Shishkin]

Hello everyone,

I have set up the updated Namesys repositories at my Github page.
Those repositories are supposed to contain the latest updates in
the (stable) master branch and in other (experimental) branches that
I'll announce.

1) https://github.com/edward6/reiser4

This is a "standalone" reiser4 tree, which doesn't include specific
changes of Linux kernel needed for reiser4 port. Such changes can be
found at the project's page on Sourceforge:
https://sourceforge.net/projects/reiser4/

An example of work with the standalone reiser4 tree:

. Patch the respective kernel with the latest available stuff from
   Sourceforge;
. cd to the "fs" directory;
. delete the directory reiser4;
. instead of the deleted stuff clone the standalone reiser4
   repository from Github;
. build and install as usual.

2) Libaal and Reiser4progs:

https://github.com/edward6/libaal
https://github.com/edward6/reiser4progs

Before building Libaal and Reiser4progs execute the ./prepare script,
which will create files needed for build process.

Thanks,
Edward.

Re: Reiser4 Upstream Git Repositories on GitHub

[Christian Kujau]

On Sat, 24 Sep 2016, Edward Shishkin wrote:
> I have set up the updated Namesys repositories at my Github page.
> Those repositories are supposed to contain the latest updates in
> the (stable) master branch and in other (experimental) branches that
> I'll announce.

Very cool, thanks for that!

> An example of work with the standalone reiser4 tree:

I've updated https://reiser4.wiki.kernel.org/index.php/Reiser4progs and 
https://reiser4.wiki.kernel.org/index.php/Reiser4_patchsets on how to 
build both userspace and the kernel (module) and it worked for a Linux 4.7 
kernel! ;-)

Christian.
-- 
BOFH excuse #280:

Traceroute says that there is a routing problem in the backbone.  It's not our problem.

Re: Reiser4 Upstream Git Repositories on GitHub

[Ivan Shapovalov]

[-- Attachment #1: Type: text/plain, Size: 1380 bytes --]

On 2016-09-24 at 22:16 +0200, Edward Shishkin wrote:
> Hello everyone,
> 
> I have set up the updated Namesys repositories at my Github page.
> Those repositories are supposed to contain the latest updates in
> the (stable) master branch and in other (experimental) branches that
> I'll announce.
> 
> 1) https://github.com/edward6/reiser4
> 
> This is a "standalone" reiser4 tree, which doesn't include specific
> changes of Linux kernel needed for reiser4 port. Such changes can be
> found at the project's page on Sourceforge:
> https://sourceforge.net/projects/reiser4/
> 
> An example of work with the standalone reiser4 tree:
> 
> . Patch the respective kernel with the latest available stuff from
>    Sourceforge;
> . cd to the "fs" directory;
> . delete the directory reiser4;
> . instead of the deleted stuff clone the standalone reiser4
>    repository from Github;
> . build and install as usual.
> 
> 2) Libaal and Reiser4progs:
> 
> https://github.com/edward6/libaal
> https://github.com/edward6/reiser4progs
> 
> Before building Libaal and Reiser4progs execute the ./prepare script,
> which will create files needed for build process.
> 
> Thanks,
> Edward.

Wow, finally.

Maybe we could avoid that "all changes for 10 years" commit?
I tried to keep track of all patches since 3.2...

-- 
Ivan Shapovalov / intelfx /

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: Reiser4 Upstream Git Repositories on GitHub

[Edward Shishkin]

On 09/27/2016 12:05 AM, Ivan Shapovalov wrote:
> On 2016-09-24 at 22:16 +0200, Edward Shishkin wrote:
>> Hello everyone,
>>
>> I have set up the updated Namesys repositories at my Github page.
>> Those repositories are supposed to contain the latest updates in
>> the (stable) master branch and in other (experimental) branches that
>> I'll announce.
>>
>> 1) https://github.com/edward6/reiser4
>>
>> This is a "standalone" reiser4 tree, which doesn't include specific
>> changes of Linux kernel needed for reiser4 port. Such changes can be
>> found at the project's page on Sourceforge:
>> https://sourceforge.net/projects/reiser4/
>>
>> An example of work with the standalone reiser4 tree:
>>
>> . Patch the respective kernel with the latest available stuff from
>>     Sourceforge;
>> . cd to the "fs" directory;
>> . delete the directory reiser4;
>> . instead of the deleted stuff clone the standalone reiser4
>>     repository from Github;
>> . build and install as usual.
>>
>> 2) Libaal and Reiser4progs:
>>
>> https://github.com/edward6/libaal
>> https://github.com/edward6/reiser4progs
>>
>> Before building Libaal and Reiser4progs execute the ./prepare script,
>> which will create files needed for build process.
>>
>> Thanks,
>> Edward.
> Wow, finally.
>
> Maybe we could avoid that "all changes for 10 years" commit?

Hi Ivan,
Sorry, don't have a time to granulate it.

> I tried to keep track of all patches since 3.2...

There will be "all changes for 6 years" commit.
Is it much better?

Re: Reiser4 Upstream Git Repositories on GitHub

[Ivan Shapovalov]

[-- Attachment #1: Type: text/plain, Size: 1886 bytes --]

On 2016-09-27 at 00:37 +0200, Edward Shishkin wrote:
> On 09/27/2016 12:05 AM, Ivan Shapovalov wrote:
> > 
> > On 2016-09-24 at 22:16 +0200, Edward Shishkin wrote:
> > > 
> > > Hello everyone,
> > > 
> > > I have set up the updated Namesys repositories at my Github page.
> > > Those repositories are supposed to contain the latest updates in
> > > the (stable) master branch and in other (experimental) branches
> > > that
> > > I'll announce.
> > > 
> > > 1) https://github.com/edward6/reiser4
> > > 
> > > This is a "standalone" reiser4 tree, which doesn't include
> > > specific
> > > changes of Linux kernel needed for reiser4 port. Such changes can
> > > be
> > > found at the project's page on Sourceforge:
> > > https://sourceforge.net/projects/reiser4/
> > > 
> > > An example of work with the standalone reiser4 tree:
> > > 
> > > . Patch the respective kernel with the latest available stuff
> > > from
> > >     Sourceforge;
> > > . cd to the "fs" directory;
> > > . delete the directory reiser4;
> > > . instead of the deleted stuff clone the standalone reiser4
> > >     repository from Github;
> > > . build and install as usual.
> > > 
> > > 2) Libaal and Reiser4progs:
> > > 
> > > https://github.com/edward6/libaal
> > > https://github.com/edward6/reiser4progs
> > > 
> > > Before building Libaal and Reiser4progs execute the ./prepare
> > > script,
> > > which will create files needed for build process.
> > > 
> > > Thanks,
> > > Edward.
> > Wow, finally.
> > 
> > Maybe we could avoid that "all changes for 10 years" commit?
> 
> Hi Ivan,
> Sorry, don't have a time to granulate it.
> 
> > 
> > I tried to keep track of all patches since 3.2...
> 
> There will be "all changes for 6 years" commit.
> Is it much better?

I'll check how much better it is exactly :)

-- 
Ivan Shapovalov / intelfx /

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: Reiser4 Upstream Git Repositories on GitHub

[Ivan Shapovalov]

[-- Attachment #1: Type: text/plain, Size: 2047 bytes --]

On 2016-09-27 at 00:37 +0200, Edward Shishkin wrote:
> On 09/27/2016 12:05 AM, Ivan Shapovalov wrote:
> > 
> > On 2016-09-24 at 22:16 +0200, Edward Shishkin wrote:
> > > 
> > > Hello everyone,
> > > 
> > > I have set up the updated Namesys repositories at my Github page.
> > > Those repositories are supposed to contain the latest updates in
> > > the (stable) master branch and in other (experimental) branches
> > > that
> > > I'll announce.
> > > 
> > > 1) https://github.com/edward6/reiser4
> > > 
> > > This is a "standalone" reiser4 tree, which doesn't include
> > > specific
> > > changes of Linux kernel needed for reiser4 port. Such changes can
> > > be
> > > found at the project's page on Sourceforge:
> > > https://sourceforge.net/projects/reiser4/
> > > 
> > > An example of work with the standalone reiser4 tree:
> > > 
> > > . Patch the respective kernel with the latest available stuff
> > > from
> > >     Sourceforge;
> > > . cd to the "fs" directory;
> > > . delete the directory reiser4;
> > > . instead of the deleted stuff clone the standalone reiser4
> > >     repository from Github;
> > > . build and install as usual.
> > > 
> > > 2) Libaal and Reiser4progs:
> > > 
> > > https://github.com/edward6/libaal
> > > https://github.com/edward6/reiser4progs
> > > 
> > > Before building Libaal and Reiser4progs execute the ./prepare
> > > script,
> > > which will create files needed for build process.
> > > 
> > > Thanks,
> > > Edward.
> > Wow, finally.
> > 
> > Maybe we could avoid that "all changes for 10 years" commit?
> 
> Hi Ivan,
> Sorry, don't have a time to granulate it.
> 
> > 
> > I tried to keep track of all patches since 3.2...
> 
> There will be "all changes for 6 years" commit.
> Is it much better?

I've noticed that your tree has an if(0) in should_punch_hole(),
while you've previously posted code for race detection in the hole
punch mechanism, and this code is not in your tree... is this correct?

-- 
Ivan Shapovalov / intelfx /

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: Reiser4 Upstream Git Repositories on GitHub

[Ivan Shapovalov]

[-- Attachment #1: Type: text/plain, Size: 2942 bytes --]

On 2016-09-27 at 00:37 +0200, Edward Shishkin wrote:
> On 09/27/2016 12:05 AM, Ivan Shapovalov wrote:
> > 
> > On 2016-09-24 at 22:16 +0200, Edward Shishkin wrote:
> > > 
> > > Hello everyone,
> > > 
> > > I have set up the updated Namesys repositories at my Github page.
> > > Those repositories are supposed to contain the latest updates in
> > > the (stable) master branch and in other (experimental) branches
> > > that
> > > I'll announce.
> > > 
> > > 1) https://github.com/edward6/reiser4
> > > 
> > > This is a "standalone" reiser4 tree, which doesn't include
> > > specific
> > > changes of Linux kernel needed for reiser4 port. Such changes can
> > > be
> > > found at the project's page on Sourceforge:
> > > https://sourceforge.net/projects/reiser4/
> > > 
> > > An example of work with the standalone reiser4 tree:
> > > 
> > > . Patch the respective kernel with the latest available stuff
> > > from
> > >     Sourceforge;
> > > . cd to the "fs" directory;
> > > . delete the directory reiser4;
> > > . instead of the deleted stuff clone the standalone reiser4
> > >     repository from Github;
> > > . build and install as usual.
> > > 
> > > 2) Libaal and Reiser4progs:
> > > 
> > > https://github.com/edward6/libaal
> > > https://github.com/edward6/reiser4progs
> > > 
> > > Before building Libaal and Reiser4progs execute the ./prepare
> > > script,
> > > which will create files needed for build process.
> > > 
> > > Thanks,
> > > Edward.
> > Wow, finally.
> > 
> > Maybe we could avoid that "all changes for 10 years" commit?
> 
> Hi Ivan,
> Sorry, don't have a time to granulate it.
> 
> > 
> > I tried to keep track of all patches since 3.2...
> 
> There will be "all changes for 6 years" commit.
> Is it much better?

So well, I finished splitting off all known diffs from that big commit.
Tt was 12k(+)/8k(-), now it is 7k(+)/7k(-).

The updated branch is here: https://github.com/intelfx/reiser4
(unfortunately, not fast-forward).

Moreover, my tree has accumulated quite a few differences from your
one. I've dropped trivial discrepancies (comments, formatting etc.)
and put the larger ones in separate branches:

1. https://github.com/intelfx/reiser4/tree/differences/enotty
   (unsupported ioctls return -ENOTTY, not -ENOSYS)

2. https://github.com/intelfx/reiser4/tree/differences/migratepage
   (the ->migratepage() implementation, which I still do not completely
    understand, but it works)

3. https://github.com/intelfx/reiser4/tree/differences/renameat2
   (renameat2(RENAME_NOREPLACE) implementation, which you haven't
    merged somewhy)

4. https://github.com/intelfx/reiser4/tree/differences/adjust-to-3.15
   (part of porting to 3.15 which, again, you haven't merged somewhy)

These branches are on top of that granular "master".
Anyway, please take a look.

-- 
Ivan Shapovalov / intelfx /

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: Reiser4 Upstream Git Repositories on GitHub

[Edward Shishkin]

On 09/27/2016 03:43 AM, Ivan Shapovalov wrote:
> On 2016-09-27 at 00:37 +0200, Edward Shishkin wrote:
>> On 09/27/2016 12:05 AM, Ivan Shapovalov wrote:
>>> On 2016-09-24 at 22:16 +0200, Edward Shishkin wrote:
>>>> Hello everyone,
>>>>
>>>> I have set up the updated Namesys repositories at my Github page.
>>>> Those repositories are supposed to contain the latest updates in
>>>> the (stable) master branch and in other (experimental) branches
>>>> that
>>>> I'll announce.
>>>>
>>>> 1)https://github.com/edward6/reiser4
>>>>
>>>> This is a "standalone" reiser4 tree, which doesn't include
>>>> specific
>>>> changes of Linux kernel needed for reiser4 port. Such changes can
>>>> be
>>>> found at the project's page on Sourceforge:
>>>> https://sourceforge.net/projects/reiser4/
>>>>
>>>> An example of work with the standalone reiser4 tree:
>>>>
>>>> . Patch the respective kernel with the latest available stuff
>>>> from
>>>>      Sourceforge;
>>>> . cd to the "fs" directory;
>>>> . delete the directory reiser4;
>>>> . instead of the deleted stuff clone the standalone reiser4
>>>>      repository from Github;
>>>> . build and install as usual.
>>>>
>>>> 2) Libaal and Reiser4progs:
>>>>
>>>> https://github.com/edward6/libaal
>>>> https://github.com/edward6/reiser4progs
>>>>
>>>> Before building Libaal and Reiser4progs execute the ./prepare
>>>> script,
>>>> which will create files needed for build process.
>>>>
>>>> Thanks,
>>>> Edward.
>>> Wow, finally.
>>>
>>> Maybe we could avoid that "all changes for 10 years" commit?
>> Hi Ivan,
>> Sorry, don't have a time to granulate it.
>>
>>> I tried to keep track of all patches since 3.2...
>> There will be "all changes for 6 years" commit.
>> Is it much better?
> I've noticed that your tree has an if(0) in should_punch_hole(),
> while you've previously posted code for race detection in the hole
> punch mechanism, and this code is not in your tree... is this correct?

Yes, I disabled hole punching because of specific problems:
if the flush procedure can not find a parent of a dirty child
in the tree, then it jumps to error path and reports about
corruption.

If dirty page cluster contains only zeros, then hole punching
code kills its parent item (the idea of hole punching is that a
set of zeros is represented by nothing on disk). Thus, we need
to teach the flush code to handle that situation (absence of
parent) properly.

Unfortunately I exceeded time limits allocated for flush
modifications, so that task went to long-term TODO..

Edward.

Re: Reiser4 Upstream Git Repositories on GitHub

[Edward Shishkin]

On 09/27/2016 04:43 AM, Ivan Shapovalov wrote:
> On 2016-09-27 at 00:37 +0200, Edward Shishkin wrote:
>> On 09/27/2016 12:05 AM, Ivan Shapovalov wrote:
>>> On 2016-09-24 at 22:16 +0200, Edward Shishkin wrote:
>>>> Hello everyone,
>>>>
>>>> I have set up the updated Namesys repositories at my Github page.
>>>> Those repositories are supposed to contain the latest updates in
>>>> the (stable) master branch and in other (experimental) branches
>>>> that
>>>> I'll announce.
>>>>
>>>> 1) https://github.com/edward6/reiser4
>>>>
>>>> This is a "standalone" reiser4 tree, which doesn't include
>>>> specific
>>>> changes of Linux kernel needed for reiser4 port. Such changes can
>>>> be
>>>> found at the project's page on Sourceforge:
>>>> https://sourceforge.net/projects/reiser4/
>>>>
>>>> An example of work with the standalone reiser4 tree:
>>>>
>>>> . Patch the respective kernel with the latest available stuff
>>>> from
>>>>      Sourceforge;
>>>> . cd to the "fs" directory;
>>>> . delete the directory reiser4;
>>>> . instead of the deleted stuff clone the standalone reiser4
>>>>      repository from Github;
>>>> . build and install as usual.
>>>>
>>>> 2) Libaal and Reiser4progs:
>>>>
>>>> https://github.com/edward6/libaal
>>>> https://github.com/edward6/reiser4progs
>>>>
>>>> Before building Libaal and Reiser4progs execute the ./prepare
>>>> script,
>>>> which will create files needed for build process.
>>>>
>>>> Thanks,
>>>> Edward.
>>> Wow, finally.
>>>
>>> Maybe we could avoid that "all changes for 10 years" commit?
>> Hi Ivan,
>> Sorry, don't have a time to granulate it.
>>
>>> I tried to keep track of all patches since 3.2...
>> There will be "all changes for 6 years" commit.
>> Is it much better?
> So well, I finished splitting off all known diffs from that big commit.
> Tt was 12k(+)/8k(-), now it is 7k(+)/7k(-).
>
> The updated branch is here: https://github.com/intelfx/reiser4
> (unfortunately, not fast-forward).
>
> Moreover, my tree has accumulated quite a few differences from your
> one. I've dropped trivial discrepancies (comments, formatting etc.)
> and put the larger ones in separate branches:
>
> 1. https://github.com/intelfx/reiser4/tree/differences/enotty
>     (unsupported ioctls return -ENOTTY, not -ENOSYS)
>
> 2. https://github.com/intelfx/reiser4/tree/differences/migratepage
>     (the ->migratepage() implementation, which I still do not completely
>      understand, but it works)
>
> 3. https://github.com/intelfx/reiser4/tree/differences/renameat2
>     (renameat2(RENAME_NOREPLACE) implementation, which you haven't
>      merged somewhy)
>
> 4. https://github.com/intelfx/reiser4/tree/differences/adjust-to-3.15
>     (part of porting to 3.15 which, again, you haven't merged somewhy)
>
> These branches are on top of that granular "master".
> Anyway, please take a look.

It was definitely useful work,
I'll look at those differences..

Thanks!
Edward.

Re: Reiser4 Upstream Git Repositories on GitHub

[Ivan Shapovalov]

[-- Attachment #1: Type: text/plain, Size: 3621 bytes --]

On 2016-09-27 at 16:13 +0200, Edward Shishkin wrote:
> On 09/27/2016 04:43 AM, Ivan Shapovalov wrote:
> > 
> > On 2016-09-27 at 00:37 +0200, Edward Shishkin wrote:
> > > 
> > > On 09/27/2016 12:05 AM, Ivan Shapovalov wrote:
> > > > 
> > > > On 2016-09-24 at 22:16 +0200, Edward Shishkin wrote:
> > > > > 
> > > > > Hello everyone,
> > > > > 
> > > > > I have set up the updated Namesys repositories at my Github
> > > > > page.
> > > > > Those repositories are supposed to contain the latest updates
> > > > > in
> > > > > the (stable) master branch and in other (experimental)
> > > > > branches
> > > > > that
> > > > > I'll announce.
> > > > > 
> > > > > 1) https://github.com/edward6/reiser4
> > > > > 
> > > > > This is a "standalone" reiser4 tree, which doesn't include
> > > > > specific
> > > > > changes of Linux kernel needed for reiser4 port. Such changes
> > > > > can
> > > > > be
> > > > > found at the project's page on Sourceforge:
> > > > > https://sourceforge.net/projects/reiser4/
> > > > > 
> > > > > An example of work with the standalone reiser4 tree:
> > > > > 
> > > > > . Patch the respective kernel with the latest available stuff
> > > > > from
> > > > >      Sourceforge;
> > > > > . cd to the "fs" directory;
> > > > > . delete the directory reiser4;
> > > > > . instead of the deleted stuff clone the standalone reiser4
> > > > >      repository from Github;
> > > > > . build and install as usual.
> > > > > 
> > > > > 2) Libaal and Reiser4progs:
> > > > > 
> > > > > https://github.com/edward6/libaal
> > > > > https://github.com/edward6/reiser4progs
> > > > > 
> > > > > Before building Libaal and Reiser4progs execute the ./prepare
> > > > > script,
> > > > > which will create files needed for build process.
> > > > > 
> > > > > Thanks,
> > > > > Edward.
> > > > Wow, finally.
> > > > 
> > > > Maybe we could avoid that "all changes for 10 years" commit?
> > > Hi Ivan,
> > > Sorry, don't have a time to granulate it.
> > > 
> > > > 
> > > > I tried to keep track of all patches since 3.2...
> > > There will be "all changes for 6 years" commit.
> > > Is it much better?
> > So well, I finished splitting off all known diffs from that big
> > commit.
> > Tt was 12k(+)/8k(-), now it is 7k(+)/7k(-).
> > 
> > The updated branch is here: https://github.com/intelfx/reiser4
> > (unfortunately, not fast-forward).
> > 
> > Moreover, my tree has accumulated quite a few differences from your
> > one. I've dropped trivial discrepancies (comments, formatting etc.)
> > and put the larger ones in separate branches:
> > 
> > 1. https://github.com/intelfx/reiser4/tree/differences/enotty
> >     (unsupported ioctls return -ENOTTY, not -ENOSYS)
> > 
> > 2. https://github.com/intelfx/reiser4/tree/differences/migratepage
> >     (the ->migratepage() implementation, which I still do not
> > completely
> >      understand, but it works)
> > 
> > 3. https://github.com/intelfx/reiser4/tree/differences/renameat2
> >     (renameat2(RENAME_NOREPLACE) implementation, which you haven't
> >      merged somewhy)
> > 
> > 4. https://github.com/intelfx/reiser4/tree/differences/adjust-to-3.
> > 15
> >     (part of porting to 3.15 which, again, you haven't merged
> > somewhy)
> > 
> > These branches are on top of that granular "master".
> > Anyway, please take a look.
> 
> It was definitely useful work,
> I'll look at those differences..

Maybe you could also consider rebasing things on top of that extracted
granular history?

-- 
Ivan Shapovalov / intelfx /

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: Reiser4 Upstream Git Repositories on GitHub

[Edward Shishkin]

On 09/27/2016 08:36 PM, Ivan Shapovalov wrote:
> On 2016-09-27 at 16:13 +0200, Edward Shishkin wrote:
>> On 09/27/2016 04:43 AM, Ivan Shapovalov wrote:
>>> On 2016-09-27 at 00:37 +0200, Edward Shishkin wrote:
>>>> On 09/27/2016 12:05 AM, Ivan Shapovalov wrote:
>>>>> On 2016-09-24 at 22:16 +0200, Edward Shishkin wrote:
>>>>>> Hello everyone,
>>>>>>
>>>>>> I have set up the updated Namesys repositories at my Github
>>>>>> page.
>>>>>> Those repositories are supposed to contain the latest updates
>>>>>> in
>>>>>> the (stable) master branch and in other (experimental)
>>>>>> branches
>>>>>> that
>>>>>> I'll announce.
>>>>>>
>>>>>> 1) https://github.com/edward6/reiser4
>>>>>>
>>>>>> This is a "standalone" reiser4 tree, which doesn't include
>>>>>> specific
>>>>>> changes of Linux kernel needed for reiser4 port. Such changes
>>>>>> can
>>>>>> be
>>>>>> found at the project's page on Sourceforge:
>>>>>> https://sourceforge.net/projects/reiser4/
>>>>>>
>>>>>> An example of work with the standalone reiser4 tree:
>>>>>>
>>>>>> . Patch the respective kernel with the latest available stuff
>>>>>> from
>>>>>>       Sourceforge;
>>>>>> . cd to the "fs" directory;
>>>>>> . delete the directory reiser4;
>>>>>> . instead of the deleted stuff clone the standalone reiser4
>>>>>>       repository from Github;
>>>>>> . build and install as usual.
>>>>>>
>>>>>> 2) Libaal and Reiser4progs:
>>>>>>
>>>>>> https://github.com/edward6/libaal
>>>>>> https://github.com/edward6/reiser4progs
>>>>>>
>>>>>> Before building Libaal and Reiser4progs execute the ./prepare
>>>>>> script,
>>>>>> which will create files needed for build process.
>>>>>>
>>>>>> Thanks,
>>>>>> Edward.
>>>>> Wow, finally.
>>>>>
>>>>> Maybe we could avoid that "all changes for 10 years" commit?
>>>> Hi Ivan,
>>>> Sorry, don't have a time to granulate it.
>>>>
>>>>> I tried to keep track of all patches since 3.2...
>>>> There will be "all changes for 6 years" commit.
>>>> Is it much better?
>>> So well, I finished splitting off all known diffs from that big
>>> commit.
>>> Tt was 12k(+)/8k(-), now it is 7k(+)/7k(-).
>>>
>>> The updated branch is here: https://github.com/intelfx/reiser4
>>> (unfortunately, not fast-forward).
>>>
>>> Moreover, my tree has accumulated quite a few differences from your
>>> one. I've dropped trivial discrepancies (comments, formatting etc.)
>>> and put the larger ones in separate branches:
>>>
>>> 1. https://github.com/intelfx/reiser4/tree/differences/enotty
>>>      (unsupported ioctls return -ENOTTY, not -ENOSYS)
>>>
>>> 2. https://github.com/intelfx/reiser4/tree/differences/migratepage
>>>      (the ->migratepage() implementation, which I still do not
>>> completely
>>>       understand, but it works)
>>>
>>> 3. https://github.com/intelfx/reiser4/tree/differences/renameat2
>>>      (renameat2(RENAME_NOREPLACE) implementation, which you haven't
>>>       merged somewhy)
>>>
>>> 4. https://github.com/intelfx/reiser4/tree/differences/adjust-to-3.
>>> 15
>>>      (part of porting to 3.15 which, again, you haven't merged
>>> somewhy)
>>>
>>> These branches are on top of that granular "master".
>>> Anyway, please take a look.
>> It was definitely useful work,
>> I'll look at those differences..
> Maybe you could also consider rebasing things on top of that extracted
> granular history?
>

Interesting idea, but I am not able to estimate
complexity of such rebasing for now.

Re: Reiser4 Upstream Git Repositories on GitHub

[Ivan Shapovalov]

[-- Attachment #1: Type: text/plain, Size: 4960 bytes --]

On 2016-09-27 at 23:47 +0200, Edward Shishkin wrote:
> 
> On 09/27/2016 08:36 PM, Ivan Shapovalov wrote:
> > 
> > On 2016-09-27 at 16:13 +0200, Edward Shishkin wrote:
> > > 
> > > On 09/27/2016 04:43 AM, Ivan Shapovalov wrote:
> > > > 
> > > > On 2016-09-27 at 00:37 +0200, Edward Shishkin wrote:
> > > > > 
> > > > > On 09/27/2016 12:05 AM, Ivan Shapovalov wrote:
> > > > > > 
> > > > > > On 2016-09-24 at 22:16 +0200, Edward Shishkin wrote:
> > > > > > > 
> > > > > > > Hello everyone,
> > > > > > > 
> > > > > > > I have set up the updated Namesys repositories at my
> > > > > > > Github
> > > > > > > page.
> > > > > > > Those repositories are supposed to contain the latest
> > > > > > > updates
> > > > > > > in
> > > > > > > the (stable) master branch and in other (experimental)
> > > > > > > branches
> > > > > > > that
> > > > > > > I'll announce.
> > > > > > > 
> > > > > > > 1) https://github.com/edward6/reiser4
> > > > > > > 
> > > > > > > This is a "standalone" reiser4 tree, which doesn't
> > > > > > > include
> > > > > > > specific
> > > > > > > changes of Linux kernel needed for reiser4 port. Such
> > > > > > > changes
> > > > > > > can
> > > > > > > be
> > > > > > > found at the project's page on Sourceforge:
> > > > > > > https://sourceforge.net/projects/reiser4/
> > > > > > > 
> > > > > > > An example of work with the standalone reiser4 tree:
> > > > > > > 
> > > > > > > . Patch the respective kernel with the latest available
> > > > > > > stuff
> > > > > > > from
> > > > > > >       Sourceforge;
> > > > > > > . cd to the "fs" directory;
> > > > > > > . delete the directory reiser4;
> > > > > > > . instead of the deleted stuff clone the standalone
> > > > > > > reiser4
> > > > > > >       repository from Github;
> > > > > > > . build and install as usual.
> > > > > > > 
> > > > > > > 2) Libaal and Reiser4progs:
> > > > > > > 
> > > > > > > https://github.com/edward6/libaal
> > > > > > > https://github.com/edward6/reiser4progs
> > > > > > > 
> > > > > > > Before building Libaal and Reiser4progs execute the
> > > > > > > ./prepare
> > > > > > > script,
> > > > > > > which will create files needed for build process.
> > > > > > > 
> > > > > > > Thanks,
> > > > > > > Edward.
> > > > > > Wow, finally.
> > > > > > 
> > > > > > Maybe we could avoid that "all changes for 10 years"
> > > > > > commit?
> > > > > Hi Ivan,
> > > > > Sorry, don't have a time to granulate it.
> > > > > 
> > > > > > 
> > > > > > I tried to keep track of all patches since 3.2...
> > > > > There will be "all changes for 6 years" commit.
> > > > > Is it much better?
> > > > So well, I finished splitting off all known diffs from that big
> > > > commit.
> > > > Tt was 12k(+)/8k(-), now it is 7k(+)/7k(-).
> > > > 
> > > > The updated branch is here: https://github.com/intelfx/reiser4
> > > > (unfortunately, not fast-forward).
> > > > 
> > > > Moreover, my tree has accumulated quite a few differences from
> > > > your
> > > > one. I've dropped trivial discrepancies (comments, formatting
> > > > etc.)
> > > > and put the larger ones in separate branches:
> > > > 
> > > > 1. https://github.com/intelfx/reiser4/tree/differences/enotty
> > > >      (unsupported ioctls return -ENOTTY, not -ENOSYS)
> > > > 
> > > > 2. https://github.com/intelfx/reiser4/tree/differences/migratep
> > > > age
> > > >      (the ->migratepage() implementation, which I still do not
> > > > completely
> > > >       understand, but it works)
> > > > 
> > > > 3. https://github.com/intelfx/reiser4/tree/differences/renameat
> > > > 2
> > > >      (renameat2(RENAME_NOREPLACE) implementation, which you
> > > > haven't
> > > >       merged somewhy)
> > > > 
> > > > 4. https://github.com/intelfx/reiser4/tree/differences/adjust-t
> > > > o-3.
> > > > 15
> > > >      (part of porting to 3.15 which, again, you haven't merged
> > > > somewhy)
> > > > 
> > > > These branches are on top of that granular "master".
> > > > Anyway, please take a look.
> > > It was definitely useful work,
> > > I'll look at those differences..
> > Maybe you could also consider rebasing things on top of that
> > extracted
> > granular history?
> > 
> 
> Interesting idea, but I am not able to estimate
> complexity of such rebasing for now.
> 


While we do not have any forks and can afford non-fast-forward updates
of master, the complexity is almost nil.

To rebase your format41 branch, one can do this:

git rebase --preserve-merges --onto 3c7b3c5802e20381496f641fe64b6c1573228c6e 8a896fd48ed35c7dfa0188f9b7f4cbdfd469cacb format41

where 8a896fd is merge-base of format41 and master (that big commit),
and 3c7b3c5 is the corresponding commit of the synthesized history.

Both commits have identical file content (`git diff 8a896fd 3c7b3c5`
yields empty output).

-- 
Ivan Shapovalov / intelfx /

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: Reiser4 Upstream Git Repositories on GitHub

[Edward Shishkin]

On 09/27/2016 11:51 PM, Ivan Shapovalov wrote:
> On 2016-09-27 at 23:47 +0200, Edward Shishkin wrote:
>> On 09/27/2016 08:36 PM, Ivan Shapovalov wrote:
>>> On 2016-09-27 at 16:13 +0200, Edward Shishkin wrote:
>>>> On 09/27/2016 04:43 AM, Ivan Shapovalov wrote:
>>>>> On 2016-09-27 at 00:37 +0200, Edward Shishkin wrote:
>>>>>> On 09/27/2016 12:05 AM, Ivan Shapovalov wrote:
>>>>>>> On 2016-09-24 at 22:16 +0200, Edward Shishkin wrote:
>>>>>>>> Hello everyone,
>>>>>>>>
>>>>>>>> I have set up the updated Namesys repositories at my
>>>>>>>> Github
>>>>>>>> page.
>>>>>>>> Those repositories are supposed to contain the latest
>>>>>>>> updates
>>>>>>>> in
>>>>>>>> the (stable) master branch and in other (experimental)
>>>>>>>> branches
>>>>>>>> that
>>>>>>>> I'll announce.
>>>>>>>>
>>>>>>>> 1) https://github.com/edward6/reiser4
>>>>>>>>
>>>>>>>> This is a "standalone" reiser4 tree, which doesn't
>>>>>>>> include
>>>>>>>> specific
>>>>>>>> changes of Linux kernel needed for reiser4 port. Such
>>>>>>>> changes
>>>>>>>> can
>>>>>>>> be
>>>>>>>> found at the project's page on Sourceforge:
>>>>>>>> https://sourceforge.net/projects/reiser4/
>>>>>>>>
>>>>>>>> An example of work with the standalone reiser4 tree:
>>>>>>>>
>>>>>>>> . Patch the respective kernel with the latest available
>>>>>>>> stuff
>>>>>>>> from
>>>>>>>>        Sourceforge;
>>>>>>>> . cd to the "fs" directory;
>>>>>>>> . delete the directory reiser4;
>>>>>>>> . instead of the deleted stuff clone the standalone
>>>>>>>> reiser4
>>>>>>>>        repository from Github;
>>>>>>>> . build and install as usual.
>>>>>>>>
>>>>>>>> 2) Libaal and Reiser4progs:
>>>>>>>>
>>>>>>>> https://github.com/edward6/libaal
>>>>>>>> https://github.com/edward6/reiser4progs
>>>>>>>>
>>>>>>>> Before building Libaal and Reiser4progs execute the
>>>>>>>> ./prepare
>>>>>>>> script,
>>>>>>>> which will create files needed for build process.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Edward.
>>>>>>> Wow, finally.
>>>>>>>
>>>>>>> Maybe we could avoid that "all changes for 10 years"
>>>>>>> commit?
>>>>>> Hi Ivan,
>>>>>> Sorry, don't have a time to granulate it.
>>>>>>
>>>>>>> I tried to keep track of all patches since 3.2...
>>>>>> There will be "all changes for 6 years" commit.
>>>>>> Is it much better?
>>>>> So well, I finished splitting off all known diffs from that big
>>>>> commit.
>>>>> Tt was 12k(+)/8k(-), now it is 7k(+)/7k(-).
>>>>>
>>>>> The updated branch is here: https://github.com/intelfx/reiser4
>>>>> (unfortunately, not fast-forward).
>>>>>
>>>>> Moreover, my tree has accumulated quite a few differences from
>>>>> your
>>>>> one. I've dropped trivial discrepancies (comments, formatting
>>>>> etc.)
>>>>> and put the larger ones in separate branches:
>>>>>
>>>>> 1. https://github.com/intelfx/reiser4/tree/differences/enotty
>>>>>       (unsupported ioctls return -ENOTTY, not -ENOSYS)
>>>>>
>>>>> 2. https://github.com/intelfx/reiser4/tree/differences/migratep
>>>>> age
>>>>>       (the ->migratepage() implementation, which I still do not
>>>>> completely
>>>>>        understand, but it works)
>>>>>
>>>>> 3. https://github.com/intelfx/reiser4/tree/differences/renameat
>>>>> 2
>>>>>       (renameat2(RENAME_NOREPLACE) implementation, which you
>>>>> haven't
>>>>>        merged somewhy)
>>>>>
>>>>> 4. https://github.com/intelfx/reiser4/tree/differences/adjust-t
>>>>> o-3.
>>>>> 15
>>>>>       (part of porting to 3.15 which, again, you haven't merged
>>>>> somewhy)
>>>>>
>>>>> These branches are on top of that granular "master".
>>>>> Anyway, please take a look.
>>>> It was definitely useful work,
>>>> I'll look at those differences..
>>> Maybe you could also consider rebasing things on top of that
>>> extracted
>>> granular history?
>>>
>> Interesting idea, but I am not able to estimate
>> complexity of such rebasing for now.
>>
>
> While we do not have any forks and can afford non-fast-forward updates
> of master, the complexity is almost nil.
>
> To rebase your format41 branch, one can do this:
>
> git rebase --preserve-merges --onto 3c7b3c5802e20381496f641fe64b6c1573228c6e 8a896fd48ed35c7dfa0188f9b7f4cbdfd469cacb format41
>
> where 8a896fd is merge-base of format41 and master (that big commit),
> and 3c7b3c5 is the corresponding commit of the synthesized history.
>
> Both commits have identical file content (`git diff 8a896fd 3c7b3c5`
> yields empty output).

OK, everything went smoothly,
Thanks for scrupulously archiving things!

Edward.

Re: Reiser4 Upstream Git Repositories on GitHub

[Ivan Shapovalov]

[-- Attachment #1: Type: text/plain, Size: 6169 bytes --]

On 2016-09-28 at 12:17 +0200, Edward Shishkin wrote:
> On 09/27/2016 11:51 PM, Ivan Shapovalov wrote:
> > On 2016-09-27 at 23:47 +0200, Edward Shishkin wrote:
> > > On 09/27/2016 08:36 PM, Ivan Shapovalov wrote:
> > > > On 2016-09-27 at 16:13 +0200, Edward Shishkin wrote:
> > > > > On 09/27/2016 04:43 AM, Ivan Shapovalov wrote:
> > > > > > On 2016-09-27 at 00:37 +0200, Edward Shishkin wrote:
> > > > > > > On 09/27/2016 12:05 AM, Ivan Shapovalov wrote:
> > > > > > > > On 2016-09-24 at 22:16 +0200, Edward Shishkin wrote:
> > > > > > > > > Hello everyone,
> > > > > > > > > 
> > > > > > > > > I have set up the updated Namesys repositories at my
> > > > > > > > > Github
> > > > > > > > > page.
> > > > > > > > > Those repositories are supposed to contain the latest
> > > > > > > > > updates
> > > > > > > > > in
> > > > > > > > > the (stable) master branch and in other
> > > > > > > > > (experimental)
> > > > > > > > > branches
> > > > > > > > > that
> > > > > > > > > I'll announce.
> > > > > > > > > 
> > > > > > > > > 1) https://github.com/edward6/reiser4
> > > > > > > > > 
> > > > > > > > > This is a "standalone" reiser4 tree, which doesn't
> > > > > > > > > include
> > > > > > > > > specific
> > > > > > > > > changes of Linux kernel needed for reiser4 port. Such
> > > > > > > > > changes
> > > > > > > > > can
> > > > > > > > > be
> > > > > > > > > found at the project's page on Sourceforge:
> > > > > > > > > https://sourceforge.net/projects/reiser4/
> > > > > > > > > 
> > > > > > > > > An example of work with the standalone reiser4 tree:
> > > > > > > > > 
> > > > > > > > > . Patch the respective kernel with the latest
> > > > > > > > > available
> > > > > > > > > stuff
> > > > > > > > > from
> > > > > > > > >        Sourceforge;
> > > > > > > > > . cd to the "fs" directory;
> > > > > > > > > . delete the directory reiser4;
> > > > > > > > > . instead of the deleted stuff clone the standalone
> > > > > > > > > reiser4
> > > > > > > > >        repository from Github;
> > > > > > > > > . build and install as usual.
> > > > > > > > > 
> > > > > > > > > 2) Libaal and Reiser4progs:
> > > > > > > > > 
> > > > > > > > > https://github.com/edward6/libaal
> > > > > > > > > https://github.com/edward6/reiser4progs
> > > > > > > > > 
> > > > > > > > > Before building Libaal and Reiser4progs execute the
> > > > > > > > > ./prepare
> > > > > > > > > script,
> > > > > > > > > which will create files needed for build process.
> > > > > > > > > 
> > > > > > > > > Thanks,
> > > > > > > > > Edward.
> > > > > > > > 
> > > > > > > > Wow, finally.
> > > > > > > > 
> > > > > > > > Maybe we could avoid that "all changes for 10 years"
> > > > > > > > commit?
> > > > > > > 
> > > > > > > Hi Ivan,
> > > > > > > Sorry, don't have a time to granulate it.
> > > > > > > 
> > > > > > > > I tried to keep track of all patches since 3.2...
> > > > > > > 
> > > > > > > There will be "all changes for 6 years" commit.
> > > > > > > Is it much better?
> > > > > > 
> > > > > > So well, I finished splitting off all known diffs from that
> > > > > > big
> > > > > > commit.
> > > > > > Tt was 12k(+)/8k(-), now it is 7k(+)/7k(-).
> > > > > > 
> > > > > > The updated branch is here: https://github.com/intelfx/reis
> > > > > > er4
> > > > > > (unfortunately, not fast-forward).
> > > > > > 
> > > > > > Moreover, my tree has accumulated quite a few differences
> > > > > > from
> > > > > > your
> > > > > > one. I've dropped trivial discrepancies (comments,
> > > > > > formatting
> > > > > > etc.)
> > > > > > and put the larger ones in separate branches:
> > > > > > 
> > > > > > 1. https://github.com/intelfx/reiser4/tree/differences/enot
> > > > > > ty
> > > > > >       (unsupported ioctls return -ENOTTY, not -ENOSYS)
> > > > > > 
> > > > > > 2. https://github.com/intelfx/reiser4/tree/differences/migr
> > > > > > atep
> > > > > > age
> > > > > >       (the ->migratepage() implementation, which I still do
> > > > > > not
> > > > > > completely
> > > > > >        understand, but it works)
> > > > > > 
> > > > > > 3. https://github.com/intelfx/reiser4/tree/differences/rena
> > > > > > meat
> > > > > > 2
> > > > > >       (renameat2(RENAME_NOREPLACE) implementation, which
> > > > > > you
> > > > > > haven't
> > > > > >        merged somewhy)
> > > > > > 
> > > > > > 4. https://github.com/intelfx/reiser4/tree/differences/adju
> > > > > > st-t
> > > > > > o-3.
> > > > > > 15
> > > > > >       (part of porting to 3.15 which, again, you haven't
> > > > > > merged
> > > > > > somewhy)
> > > > > > 
> > > > > > These branches are on top of that granular "master".
> > > > > > Anyway, please take a look.
> > > > > 
> > > > > It was definitely useful work,
> > > > > I'll look at those differences..
> > > > 
> > > > Maybe you could also consider rebasing things on top of that
> > > > extracted
> > > > granular history?
> > > > 
> > > 
> > > Interesting idea, but I am not able to estimate
> > > complexity of such rebasing for now.
> > > 
> > 
> > While we do not have any forks and can afford non-fast-forward
> > updates
> > of master, the complexity is almost nil.
> > 
> > To rebase your format41 branch, one can do this:
> > 
> > git rebase --preserve-merges --onto
> > 3c7b3c5802e20381496f641fe64b6c1573228c6e
> > 8a896fd48ed35c7dfa0188f9b7f4cbdfd469cacb format41
> > 
> > where 8a896fd is merge-base of format41 and master (that big
> > commit),
> > and 3c7b3c5 is the corresponding commit of the synthesized history.
> > 
> > Both commits have identical file content (`git diff 8a896fd
> > 3c7b3c5`
> > yields empty output).
> 
> OK, everything went smoothly,
> Thanks for scrupulously archiving things!
> 
> Edward.

Great. (In fact, I intended this to be `git push -f`-ed, not `git
merge`-ed with original history, but well, git blame now does the right
thing, so it's good enough as it is.)

We do not use github pull requests and still send formatted patch
series to the ML, correct?

-- 
Ivan Shapovalov / intelfx /

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: Reiser4 Upstream Git Repositories on GitHub

[Edward Shishkin]

On 09/28/2016 12:36 PM, Ivan Shapovalov wrote:
> On 2016-09-28 at 12:17 +0200, Edward Shishkin wrote:
>> On 09/27/2016 11:51 PM, Ivan Shapovalov wrote:
>>> On 2016-09-27 at 23:47 +0200, Edward Shishkin wrote:
>>>> On 09/27/2016 08:36 PM, Ivan Shapovalov wrote:
>>>>> On 2016-09-27 at 16:13 +0200, Edward Shishkin wrote:
>>>>>> On 09/27/2016 04:43 AM, Ivan Shapovalov wrote:
>>>>>>> On 2016-09-27 at 00:37 +0200, Edward Shishkin wrote:
>>>>>>>> On 09/27/2016 12:05 AM, Ivan Shapovalov wrote:
>>>>>>>>> On 2016-09-24 at 22:16 +0200, Edward Shishkin wrote:
>>>>>>>>>> Hello everyone,
>>>>>>>>>>
>>>>>>>>>> I have set up the updated Namesys repositories at my
>>>>>>>>>> Github
>>>>>>>>>> page.
>>>>>>>>>> Those repositories are supposed to contain the latest
>>>>>>>>>> updates
>>>>>>>>>> in
>>>>>>>>>> the (stable) master branch and in other
>>>>>>>>>> (experimental)
>>>>>>>>>> branches
>>>>>>>>>> that
>>>>>>>>>> I'll announce.
>>>>>>>>>>
>>>>>>>>>> 1) https://github.com/edward6/reiser4
>>>>>>>>>>
>>>>>>>>>> This is a "standalone" reiser4 tree, which doesn't
>>>>>>>>>> include
>>>>>>>>>> specific
>>>>>>>>>> changes of Linux kernel needed for reiser4 port. Such
>>>>>>>>>> changes
>>>>>>>>>> can
>>>>>>>>>> be
>>>>>>>>>> found at the project's page on Sourceforge:
>>>>>>>>>> https://sourceforge.net/projects/reiser4/
>>>>>>>>>>
>>>>>>>>>> An example of work with the standalone reiser4 tree:
>>>>>>>>>>
>>>>>>>>>> . Patch the respective kernel with the latest
>>>>>>>>>> available
>>>>>>>>>> stuff
>>>>>>>>>> from
>>>>>>>>>>         Sourceforge;
>>>>>>>>>> . cd to the "fs" directory;
>>>>>>>>>> . delete the directory reiser4;
>>>>>>>>>> . instead of the deleted stuff clone the standalone
>>>>>>>>>> reiser4
>>>>>>>>>>         repository from Github;
>>>>>>>>>> . build and install as usual.
>>>>>>>>>>
>>>>>>>>>> 2) Libaal and Reiser4progs:
>>>>>>>>>>
>>>>>>>>>> https://github.com/edward6/libaal
>>>>>>>>>> https://github.com/edward6/reiser4progs
>>>>>>>>>>
>>>>>>>>>> Before building Libaal and Reiser4progs execute the
>>>>>>>>>> ./prepare
>>>>>>>>>> script,
>>>>>>>>>> which will create files needed for build process.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Edward.
>>>>>>>>> Wow, finally.
>>>>>>>>>
>>>>>>>>> Maybe we could avoid that "all changes for 10 years"
>>>>>>>>> commit?
>>>>>>>> Hi Ivan,
>>>>>>>> Sorry, don't have a time to granulate it.
>>>>>>>>
>>>>>>>>> I tried to keep track of all patches since 3.2...
>>>>>>>> There will be "all changes for 6 years" commit.
>>>>>>>> Is it much better?
>>>>>>> So well, I finished splitting off all known diffs from that
>>>>>>> big
>>>>>>> commit.
>>>>>>> Tt was 12k(+)/8k(-), now it is 7k(+)/7k(-).
>>>>>>>
>>>>>>> The updated branch is here: https://github.com/intelfx/reis
>>>>>>> er4
>>>>>>> (unfortunately, not fast-forward).
>>>>>>>
>>>>>>> Moreover, my tree has accumulated quite a few differences
>>>>>>> from
>>>>>>> your
>>>>>>> one. I've dropped trivial discrepancies (comments,
>>>>>>> formatting
>>>>>>> etc.)
>>>>>>> and put the larger ones in separate branches:
>>>>>>>
>>>>>>> 1. https://github.com/intelfx/reiser4/tree/differences/enot
>>>>>>> ty
>>>>>>>        (unsupported ioctls return -ENOTTY, not -ENOSYS)
>>>>>>>
>>>>>>> 2. https://github.com/intelfx/reiser4/tree/differences/migr
>>>>>>> atep
>>>>>>> age
>>>>>>>        (the ->migratepage() implementation, which I still do
>>>>>>> not
>>>>>>> completely
>>>>>>>         understand, but it works)
>>>>>>>
>>>>>>> 3. https://github.com/intelfx/reiser4/tree/differences/rena
>>>>>>> meat
>>>>>>> 2
>>>>>>>        (renameat2(RENAME_NOREPLACE) implementation, which
>>>>>>> you
>>>>>>> haven't
>>>>>>>         merged somewhy)
>>>>>>>
>>>>>>> 4. https://github.com/intelfx/reiser4/tree/differences/adju
>>>>>>> st-t
>>>>>>> o-3.
>>>>>>> 15
>>>>>>>        (part of porting to 3.15 which, again, you haven't
>>>>>>> merged
>>>>>>> somewhy)
>>>>>>>
>>>>>>> These branches are on top of that granular "master".
>>>>>>> Anyway, please take a look.
>>>>>> It was definitely useful work,
>>>>>> I'll look at those differences..
>>>>> Maybe you could also consider rebasing things on top of that
>>>>> extracted
>>>>> granular history?
>>>>>
>>>> Interesting idea, but I am not able to estimate
>>>> complexity of such rebasing for now.
>>>>
>>> While we do not have any forks and can afford non-fast-forward
>>> updates
>>> of master, the complexity is almost nil.
>>>
>>> To rebase your format41 branch, one can do this:
>>>
>>> git rebase --preserve-merges --onto
>>> 3c7b3c5802e20381496f641fe64b6c1573228c6e
>>> 8a896fd48ed35c7dfa0188f9b7f4cbdfd469cacb format41
>>>
>>> where 8a896fd is merge-base of format41 and master (that big
>>> commit),
>>> and 3c7b3c5 is the corresponding commit of the synthesized history.
>>>
>>> Both commits have identical file content (`git diff 8a896fd
>>> 3c7b3c5`
>>> yields empty output).
>> OK, everything went smoothly,
>> Thanks for scrupulously archiving things!
>>
>> Edward.
> Great. (In fact, I intended this to be `git push -f`-ed, not `git
> merge`-ed with original history, but well, git blame now does the right
> thing, so it's good enough as it is.)
>
> We do not use github pull requests and still send formatted patch
> series to the ML, correct?
>

Yup, everything to the list, as usual..

Edward.

Re: Reiser4 Upstream Git Repositories on GitHub

[Edward Shishkin]

On 09/28/2016 03:56 PM, Edward Shishkin wrote:
>
>
> On 09/28/2016 12:36 PM, Ivan Shapovalov wrote:
>> On 2016-09-28 at 12:17 +0200, Edward Shishkin wrote:
>>> On 09/27/2016 11:51 PM, Ivan Shapovalov wrote:
>>>> On 2016-09-27 at 23:47 +0200, Edward Shishkin wrote:
>>>>> On 09/27/2016 08:36 PM, Ivan Shapovalov wrote:
>>>>>> On 2016-09-27 at 16:13 +0200, Edward Shishkin wrote:
>>>>>>> On 09/27/2016 04:43 AM, Ivan Shapovalov wrote:
>>>>>>>> On 2016-09-27 at 00:37 +0200, Edward Shishkin wrote:
>>>>>>>>> On 09/27/2016 12:05 AM, Ivan Shapovalov wrote:
>>>>>>>>>> On 2016-09-24 at 22:16 +0200, Edward Shishkin wrote:
>>>>>>>>>>> Hello everyone,
>>>>>>>>>>>
>>>>>>>>>>> I have set up the updated Namesys repositories at my
>>>>>>>>>>> Github
>>>>>>>>>>> page.
>>>>>>>>>>> Those repositories are supposed to contain the latest
>>>>>>>>>>> updates
>>>>>>>>>>> in
>>>>>>>>>>> the (stable) master branch and in other
>>>>>>>>>>> (experimental)
>>>>>>>>>>> branches
>>>>>>>>>>> that
>>>>>>>>>>> I'll announce.
>>>>>>>>>>>
>>>>>>>>>>> 1) https://github.com/edward6/reiser4
>>>>>>>>>>>
>>>>>>>>>>> This is a "standalone" reiser4 tree, which doesn't
>>>>>>>>>>> include
>>>>>>>>>>> specific
>>>>>>>>>>> changes of Linux kernel needed for reiser4 port. Such
>>>>>>>>>>> changes
>>>>>>>>>>> can
>>>>>>>>>>> be
>>>>>>>>>>> found at the project's page on Sourceforge:
>>>>>>>>>>> https://sourceforge.net/projects/reiser4/
>>>>>>>>>>>
>>>>>>>>>>> An example of work with the standalone reiser4 tree:
>>>>>>>>>>>
>>>>>>>>>>> . Patch the respective kernel with the latest
>>>>>>>>>>> available
>>>>>>>>>>> stuff
>>>>>>>>>>> from
>>>>>>>>>>>         Sourceforge;
>>>>>>>>>>> . cd to the "fs" directory;
>>>>>>>>>>> . delete the directory reiser4;
>>>>>>>>>>> . instead of the deleted stuff clone the standalone
>>>>>>>>>>> reiser4
>>>>>>>>>>>         repository from Github;
>>>>>>>>>>> . build and install as usual.
>>>>>>>>>>>
>>>>>>>>>>> 2) Libaal and Reiser4progs:
>>>>>>>>>>>
>>>>>>>>>>> https://github.com/edward6/libaal
>>>>>>>>>>> https://github.com/edward6/reiser4progs
>>>>>>>>>>>
>>>>>>>>>>> Before building Libaal and Reiser4progs execute the
>>>>>>>>>>> ./prepare
>>>>>>>>>>> script,
>>>>>>>>>>> which will create files needed for build process.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Edward.
>>>>>>>>>> Wow, finally.
>>>>>>>>>>
>>>>>>>>>> Maybe we could avoid that "all changes for 10 years"
>>>>>>>>>> commit?
>>>>>>>>> Hi Ivan,
>>>>>>>>> Sorry, don't have a time to granulate it.
>>>>>>>>>
>>>>>>>>>> I tried to keep track of all patches since 3.2...
>>>>>>>>> There will be "all changes for 6 years" commit.
>>>>>>>>> Is it much better?
>>>>>>>> So well, I finished splitting off all known diffs from that
>>>>>>>> big
>>>>>>>> commit.
>>>>>>>> Tt was 12k(+)/8k(-), now it is 7k(+)/7k(-).
>>>>>>>>
>>>>>>>> The updated branch is here: https://github.com/intelfx/reis
>>>>>>>> er4
>>>>>>>> (unfortunately, not fast-forward).
>>>>>>>>
>>>>>>>> Moreover, my tree has accumulated quite a few differences
>>>>>>>> from
>>>>>>>> your
>>>>>>>> one. I've dropped trivial discrepancies (comments,
>>>>>>>> formatting
>>>>>>>> etc.)
>>>>>>>> and put the larger ones in separate branches:
>>>>>>>>
>>>>>>>> 1. https://github.com/intelfx/reiser4/tree/differences/enot
>>>>>>>> ty
>>>>>>>>        (unsupported ioctls return -ENOTTY, not -ENOSYS)
>>>>>>>>
>>>>>>>> 2. https://github.com/intelfx/reiser4/tree/differences/migr
>>>>>>>> atep
>>>>>>>> age
>>>>>>>>        (the ->migratepage() implementation, which I still do
>>>>>>>> not
>>>>>>>> completely
>>>>>>>>         understand, but it works)
>>>>>>>>
>>>>>>>> 3. https://github.com/intelfx/reiser4/tree/differences/rena
>>>>>>>> meat
>>>>>>>> 2
>>>>>>>>        (renameat2(RENAME_NOREPLACE) implementation, which
>>>>>>>> you
>>>>>>>> haven't
>>>>>>>>         merged somewhy)
>>>>>>>>
>>>>>>>> 4. https://github.com/intelfx/reiser4/tree/differences/adju
>>>>>>>> st-t
>>>>>>>> o-3.
>>>>>>>> 15
>>>>>>>>        (part of porting to 3.15 which, again, you haven't
>>>>>>>> merged
>>>>>>>> somewhy)
>>>>>>>>
>>>>>>>> These branches are on top of that granular "master".
>>>>>>>> Anyway, please take a look.
>>>>>>> It was definitely useful work,
>>>>>>> I'll look at those differences..
>>>>>> Maybe you could also consider rebasing things on top of that
>>>>>> extracted
>>>>>> granular history?
>>>>>>
>>>>> Interesting idea, but I am not able to estimate
>>>>> complexity of such rebasing for now.
>>>>>
>>>> While we do not have any forks and can afford non-fast-forward
>>>> updates
>>>> of master, the complexity is almost nil.
>>>>
>>>> To rebase your format41 branch, one can do this:
>>>>
>>>> git rebase --preserve-merges --onto
>>>> 3c7b3c5802e20381496f641fe64b6c1573228c6e
>>>> 8a896fd48ed35c7dfa0188f9b7f4cbdfd469cacb format41
>>>>
>>>> where 8a896fd is merge-base of format41 and master (that big
>>>> commit),
>>>> and 3c7b3c5 is the corresponding commit of the synthesized history.
>>>>
>>>> Both commits have identical file content (`git diff 8a896fd
>>>> 3c7b3c5`
>>>> yields empty output).
>>> OK, everything went smoothly,
>>> Thanks for scrupulously archiving things!
>>>
>>> Edward.
>> Great. (In fact, I intended this to be `git push -f`-ed, not `git
>> merge`-ed with original history, but well, git blame now does the right
>> thing, so it's good enough as it is.)
>>
>> We do not use github pull requests and still send formatted patch
>> series to the ML, correct?
>>
>
> Yup, everything to the list, as usual..

BTW, your fstrim-scanner is the first candidate to scrub ;)
Actually, I think about a common multi-functional scanner, with 3 modes:
1) discard only (handle only free blocks);
2) scrub only (handle only busy blocks);
3) combined (scan the whole partition; for free blocks call discard,
     for busy ones call scrub).
Any ideas?

Thanks,
Edward.
PS: We have an own ioctl number: 0xCD inherited from ReiserFS(v3).

Re: Reiser4 Upstream Git Repositories on GitHub

[Ivan Shapovalov]

[-- Attachment #1: Type: text/plain, Size: 8738 bytes --]

On 2016-09-28 at 16:44 +0200, Edward Shishkin wrote:
> 
> On 09/28/2016 03:56 PM, Edward Shishkin wrote:
> > 
> > 
> > On 09/28/2016 12:36 PM, Ivan Shapovalov wrote:
> > > On 2016-09-28 at 12:17 +0200, Edward Shishkin wrote:
> > > > On 09/27/2016 11:51 PM, Ivan Shapovalov wrote:
> > > > > On 2016-09-27 at 23:47 +0200, Edward Shishkin wrote:
> > > > > > On 09/27/2016 08:36 PM, Ivan Shapovalov wrote:
> > > > > > > On 2016-09-27 at 16:13 +0200, Edward Shishkin wrote:
> > > > > > > > On 09/27/2016 04:43 AM, Ivan Shapovalov wrote:
> > > > > > > > > On 2016-09-27 at 00:37 +0200, Edward Shishkin wrote:
> > > > > > > > > > On 09/27/2016 12:05 AM, Ivan Shapovalov wrote:
> > > > > > > > > > > On 2016-09-24 at 22:16 +0200, Edward Shishkin
> > > > > > > > > > > wrote:
> > > > > > > > > > > > Hello everyone,
> > > > > > > > > > > > 
> > > > > > > > > > > > I have set up the updated Namesys repositories
> > > > > > > > > > > > at my
> > > > > > > > > > > > Github
> > > > > > > > > > > > page.
> > > > > > > > > > > > Those repositories are supposed to contain the
> > > > > > > > > > > > latest
> > > > > > > > > > > > updates
> > > > > > > > > > > > in
> > > > > > > > > > > > the (stable) master branch and in other
> > > > > > > > > > > > (experimental)
> > > > > > > > > > > > branches
> > > > > > > > > > > > that
> > > > > > > > > > > > I'll announce.
> > > > > > > > > > > > 
> > > > > > > > > > > > 1) https://github.com/edward6/reiser4
> > > > > > > > > > > > 
> > > > > > > > > > > > This is a "standalone" reiser4 tree, which
> > > > > > > > > > > > doesn't
> > > > > > > > > > > > include
> > > > > > > > > > > > specific
> > > > > > > > > > > > changes of Linux kernel needed for reiser4
> > > > > > > > > > > > port. Such
> > > > > > > > > > > > changes
> > > > > > > > > > > > can
> > > > > > > > > > > > be
> > > > > > > > > > > > found at the project's page on Sourceforge:
> > > > > > > > > > > > https://sourceforge.net/projects/reiser4/
> > > > > > > > > > > > 
> > > > > > > > > > > > An example of work with the standalone reiser4
> > > > > > > > > > > > tree:
> > > > > > > > > > > > 
> > > > > > > > > > > > . Patch the respective kernel with the latest
> > > > > > > > > > > > available
> > > > > > > > > > > > stuff
> > > > > > > > > > > > from
> > > > > > > > > > > >         Sourceforge;
> > > > > > > > > > > > . cd to the "fs" directory;
> > > > > > > > > > > > . delete the directory reiser4;
> > > > > > > > > > > > . instead of the deleted stuff clone the
> > > > > > > > > > > > standalone
> > > > > > > > > > > > reiser4
> > > > > > > > > > > >         repository from Github;
> > > > > > > > > > > > . build and install as usual.
> > > > > > > > > > > > 
> > > > > > > > > > > > 2) Libaal and Reiser4progs:
> > > > > > > > > > > > 
> > > > > > > > > > > > https://github.com/edward6/libaal
> > > > > > > > > > > > https://github.com/edward6/reiser4progs
> > > > > > > > > > > > 
> > > > > > > > > > > > Before building Libaal and Reiser4progs execute
> > > > > > > > > > > > the
> > > > > > > > > > > > ./prepare
> > > > > > > > > > > > script,
> > > > > > > > > > > > which will create files needed for build
> > > > > > > > > > > > process.
> > > > > > > > > > > > 
> > > > > > > > > > > > Thanks,
> > > > > > > > > > > > Edward.
> > > > > > > > > > > 
> > > > > > > > > > > Wow, finally.
> > > > > > > > > > > 
> > > > > > > > > > > Maybe we could avoid that "all changes for 10
> > > > > > > > > > > years"
> > > > > > > > > > > commit?
> > > > > > > > > > 
> > > > > > > > > > Hi Ivan,
> > > > > > > > > > Sorry, don't have a time to granulate it.
> > > > > > > > > > 
> > > > > > > > > > > I tried to keep track of all patches since 3.2...
> > > > > > > > > > 
> > > > > > > > > > There will be "all changes for 6 years" commit.
> > > > > > > > > > Is it much better?
> > > > > > > > > 
> > > > > > > > > So well, I finished splitting off all known diffs
> > > > > > > > > from that
> > > > > > > > > big
> > > > > > > > > commit.
> > > > > > > > > Tt was 12k(+)/8k(-), now it is 7k(+)/7k(-).
> > > > > > > > > 
> > > > > > > > > The updated branch is here: https://github.com/intelf
> > > > > > > > > x/reis
> > > > > > > > > er4
> > > > > > > > > (unfortunately, not fast-forward).
> > > > > > > > > 
> > > > > > > > > Moreover, my tree has accumulated quite a few
> > > > > > > > > differences
> > > > > > > > > from
> > > > > > > > > your
> > > > > > > > > one. I've dropped trivial discrepancies (comments,
> > > > > > > > > formatting
> > > > > > > > > etc.)
> > > > > > > > > and put the larger ones in separate branches:
> > > > > > > > > 
> > > > > > > > > 1. https://github.com/intelfx/reiser4/tree/difference
> > > > > > > > > s/enot
> > > > > > > > > ty
> > > > > > > > >        (unsupported ioctls return -ENOTTY, not
> > > > > > > > > -ENOSYS)
> > > > > > > > > 
> > > > > > > > > 2. https://github.com/intelfx/reiser4/tree/difference
> > > > > > > > > s/migr
> > > > > > > > > atep
> > > > > > > > > age
> > > > > > > > >        (the ->migratepage() implementation, which I
> > > > > > > > > still do
> > > > > > > > > not
> > > > > > > > > completely
> > > > > > > > >         understand, but it works)
> > > > > > > > > 
> > > > > > > > > 3. https://github.com/intelfx/reiser4/tree/difference
> > > > > > > > > s/rena
> > > > > > > > > meat
> > > > > > > > > 2
> > > > > > > > >        (renameat2(RENAME_NOREPLACE) implementation,
> > > > > > > > > which
> > > > > > > > > you
> > > > > > > > > haven't
> > > > > > > > >         merged somewhy)
> > > > > > > > > 
> > > > > > > > > 4. https://github.com/intelfx/reiser4/tree/difference
> > > > > > > > > s/adju
> > > > > > > > > st-t
> > > > > > > > > o-3.
> > > > > > > > > 15
> > > > > > > > >        (part of porting to 3.15 which, again, you
> > > > > > > > > haven't
> > > > > > > > > merged
> > > > > > > > > somewhy)
> > > > > > > > > 
> > > > > > > > > These branches are on top of that granular "master".
> > > > > > > > > Anyway, please take a look.
> > > > > > > > 
> > > > > > > > It was definitely useful work,
> > > > > > > > I'll look at those differences..
> > > > > > > 
> > > > > > > Maybe you could also consider rebasing things on top of
> > > > > > > that
> > > > > > > extracted
> > > > > > > granular history?
> > > > > > > 
> > > > > > 
> > > > > > Interesting idea, but I am not able to estimate
> > > > > > complexity of such rebasing for now.
> > > > > > 
> > > > > 
> > > > > While we do not have any forks and can afford non-fast-
> > > > > forward
> > > > > updates
> > > > > of master, the complexity is almost nil.
> > > > > 
> > > > > To rebase your format41 branch, one can do this:
> > > > > 
> > > > > git rebase --preserve-merges --onto
> > > > > 3c7b3c5802e20381496f641fe64b6c1573228c6e
> > > > > 8a896fd48ed35c7dfa0188f9b7f4cbdfd469cacb format41
> > > > > 
> > > > > where 8a896fd is merge-base of format41 and master (that big
> > > > > commit),
> > > > > and 3c7b3c5 is the corresponding commit of the synthesized
> > > > > history.
> > > > > 
> > > > > Both commits have identical file content (`git diff 8a896fd
> > > > > 3c7b3c5`
> > > > > yields empty output).
> > > > 
> > > > OK, everything went smoothly,
> > > > Thanks for scrupulously archiving things!
> > > > 
> > > > Edward.
> > > 
> > > Great. (In fact, I intended this to be `git push -f`-ed, not `git
> > > merge`-ed with original history, but well, git blame now does the
> > > right
> > > thing, so it's good enough as it is.)
> > > 
> > > We do not use github pull requests and still send formatted patch
> > > series to the ML, correct?
> > > 
> > 
> > Yup, everything to the list, as usual..
> 
> BTW, your fstrim-scanner is the first candidate to scrub ;)
> Actually, I think about a common multi-functional scanner, with 3
> modes:
> 1) discard only (handle only free blocks);
> 2) scrub only (handle only busy blocks);
> 3) combined (scan the whole partition; for free blocks call discard,
>      for busy ones call scrub).
> Any ideas?
> 
> Thanks,
> Edward.
> PS: We have an own ioctl number: 0xCD inherited from ReiserFS(v3).

I still have to finish the erase unit detection (which has completely
stalled) to merge all this work. Moreover:

For the fstrim, we have dropped all locking and serialization issues
and declared that fstrim is best-effort: if it misses some blocks due
to concurrent transactions allocating and freeing blocks, it doesn't
matter.

For the scrub, this won't fly...

-- 
Ivan Shapovalov / intelfx /

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: Reiser4 Upstream Git Repositories on GitHub

[Edward Shishkin]

On 09/28/2016 05:03 PM, Ivan Shapovalov wrote:
> On 2016-09-28 at 16:44 +0200, Edward Shishkin wrote:
>> On 09/28/2016 03:56 PM, Edward Shishkin wrote:
>>>
>>> On 09/28/2016 12:36 PM, Ivan Shapovalov wrote:
>>>> On 2016-09-28 at 12:17 +0200, Edward Shishkin wrote:
>>>>> On 09/27/2016 11:51 PM, Ivan Shapovalov wrote:
>>>>>> On 2016-09-27 at 23:47 +0200, Edward Shishkin wrote:
>>>>>>> On 09/27/2016 08:36 PM, Ivan Shapovalov wrote:
>>>>>>>> On 2016-09-27 at 16:13 +0200, Edward Shishkin wrote:
>>>>>>>>> On 09/27/2016 04:43 AM, Ivan Shapovalov wrote:
>>>>>>>>>> On 2016-09-27 at 00:37 +0200, Edward Shishkin wrote:
>>>>>>>>>>> On 09/27/2016 12:05 AM, Ivan Shapovalov wrote:
>>>>>>>>>>>> On 2016-09-24 at 22:16 +0200, Edward Shishkin
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> Hello everyone,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have set up the updated Namesys repositories
>>>>>>>>>>>>> at my
>>>>>>>>>>>>> Github
>>>>>>>>>>>>> page.
>>>>>>>>>>>>> Those repositories are supposed to contain the
>>>>>>>>>>>>> latest
>>>>>>>>>>>>> updates
>>>>>>>>>>>>> in
>>>>>>>>>>>>> the (stable) master branch and in other
>>>>>>>>>>>>> (experimental)
>>>>>>>>>>>>> branches
>>>>>>>>>>>>> that
>>>>>>>>>>>>> I'll announce.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1) https://github.com/edward6/reiser4
>>>>>>>>>>>>>
>>>>>>>>>>>>> This is a "standalone" reiser4 tree, which
>>>>>>>>>>>>> doesn't
>>>>>>>>>>>>> include
>>>>>>>>>>>>> specific
>>>>>>>>>>>>> changes of Linux kernel needed for reiser4
>>>>>>>>>>>>> port. Such
>>>>>>>>>>>>> changes
>>>>>>>>>>>>> can
>>>>>>>>>>>>> be
>>>>>>>>>>>>> found at the project's page on Sourceforge:
>>>>>>>>>>>>> https://sourceforge.net/projects/reiser4/
>>>>>>>>>>>>>
>>>>>>>>>>>>> An example of work with the standalone reiser4
>>>>>>>>>>>>> tree:
>>>>>>>>>>>>>
>>>>>>>>>>>>> . Patch the respective kernel with the latest
>>>>>>>>>>>>> available
>>>>>>>>>>>>> stuff
>>>>>>>>>>>>> from
>>>>>>>>>>>>>          Sourceforge;
>>>>>>>>>>>>> . cd to the "fs" directory;
>>>>>>>>>>>>> . delete the directory reiser4;
>>>>>>>>>>>>> . instead of the deleted stuff clone the
>>>>>>>>>>>>> standalone
>>>>>>>>>>>>> reiser4
>>>>>>>>>>>>>          repository from Github;
>>>>>>>>>>>>> . build and install as usual.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2) Libaal and Reiser4progs:
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://github.com/edward6/libaal
>>>>>>>>>>>>> https://github.com/edward6/reiser4progs
>>>>>>>>>>>>>
>>>>>>>>>>>>> Before building Libaal and Reiser4progs execute
>>>>>>>>>>>>> the
>>>>>>>>>>>>> ./prepare
>>>>>>>>>>>>> script,
>>>>>>>>>>>>> which will create files needed for build
>>>>>>>>>>>>> process.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Edward.
>>>>>>>>>>>> Wow, finally.
>>>>>>>>>>>>
>>>>>>>>>>>> Maybe we could avoid that "all changes for 10
>>>>>>>>>>>> years"
>>>>>>>>>>>> commit?
>>>>>>>>>>> Hi Ivan,
>>>>>>>>>>> Sorry, don't have a time to granulate it.
>>>>>>>>>>>
>>>>>>>>>>>> I tried to keep track of all patches since 3.2...
>>>>>>>>>>> There will be "all changes for 6 years" commit.
>>>>>>>>>>> Is it much better?
>>>>>>>>>> So well, I finished splitting off all known diffs
>>>>>>>>>> from that
>>>>>>>>>> big
>>>>>>>>>> commit.
>>>>>>>>>> Tt was 12k(+)/8k(-), now it is 7k(+)/7k(-).
>>>>>>>>>>
>>>>>>>>>> The updated branch is here: https://github.com/intelf
>>>>>>>>>> x/reis
>>>>>>>>>> er4
>>>>>>>>>> (unfortunately, not fast-forward).
>>>>>>>>>>
>>>>>>>>>> Moreover, my tree has accumulated quite a few
>>>>>>>>>> differences
>>>>>>>>>> from
>>>>>>>>>> your
>>>>>>>>>> one. I've dropped trivial discrepancies (comments,
>>>>>>>>>> formatting
>>>>>>>>>> etc.)
>>>>>>>>>> and put the larger ones in separate branches:
>>>>>>>>>>
>>>>>>>>>> 1. https://github.com/intelfx/reiser4/tree/difference
>>>>>>>>>> s/enot
>>>>>>>>>> ty
>>>>>>>>>>         (unsupported ioctls return -ENOTTY, not
>>>>>>>>>> -ENOSYS)
>>>>>>>>>>
>>>>>>>>>> 2. https://github.com/intelfx/reiser4/tree/difference
>>>>>>>>>> s/migr
>>>>>>>>>> atep
>>>>>>>>>> age
>>>>>>>>>>         (the ->migratepage() implementation, which I
>>>>>>>>>> still do
>>>>>>>>>> not
>>>>>>>>>> completely
>>>>>>>>>>          understand, but it works)
>>>>>>>>>>
>>>>>>>>>> 3. https://github.com/intelfx/reiser4/tree/difference
>>>>>>>>>> s/rena
>>>>>>>>>> meat
>>>>>>>>>> 2
>>>>>>>>>>         (renameat2(RENAME_NOREPLACE) implementation,
>>>>>>>>>> which
>>>>>>>>>> you
>>>>>>>>>> haven't
>>>>>>>>>>          merged somewhy)
>>>>>>>>>>
>>>>>>>>>> 4. https://github.com/intelfx/reiser4/tree/difference
>>>>>>>>>> s/adju
>>>>>>>>>> st-t
>>>>>>>>>> o-3.
>>>>>>>>>> 15
>>>>>>>>>>         (part of porting to 3.15 which, again, you
>>>>>>>>>> haven't
>>>>>>>>>> merged
>>>>>>>>>> somewhy)
>>>>>>>>>>
>>>>>>>>>> These branches are on top of that granular "master".
>>>>>>>>>> Anyway, please take a look.
>>>>>>>>> It was definitely useful work,
>>>>>>>>> I'll look at those differences..
>>>>>>>> Maybe you could also consider rebasing things on top of
>>>>>>>> that
>>>>>>>> extracted
>>>>>>>> granular history?
>>>>>>>>
>>>>>>> Interesting idea, but I am not able to estimate
>>>>>>> complexity of such rebasing for now.
>>>>>>>
>>>>>> While we do not have any forks and can afford non-fast-
>>>>>> forward
>>>>>> updates
>>>>>> of master, the complexity is almost nil.
>>>>>>
>>>>>> To rebase your format41 branch, one can do this:
>>>>>>
>>>>>> git rebase --preserve-merges --onto
>>>>>> 3c7b3c5802e20381496f641fe64b6c1573228c6e
>>>>>> 8a896fd48ed35c7dfa0188f9b7f4cbdfd469cacb format41
>>>>>>
>>>>>> where 8a896fd is merge-base of format41 and master (that big
>>>>>> commit),
>>>>>> and 3c7b3c5 is the corresponding commit of the synthesized
>>>>>> history.
>>>>>>
>>>>>> Both commits have identical file content (`git diff 8a896fd
>>>>>> 3c7b3c5`
>>>>>> yields empty output).
>>>>> OK, everything went smoothly,
>>>>> Thanks for scrupulously archiving things!
>>>>>
>>>>> Edward.
>>>> Great. (In fact, I intended this to be `git push -f`-ed, not `git
>>>> merge`-ed with original history, but well, git blame now does the
>>>> right
>>>> thing, so it's good enough as it is.)
>>>>
>>>> We do not use github pull requests and still send formatted patch
>>>> series to the ML, correct?
>>>>
>>> Yup, everything to the list, as usual..
>> BTW, your fstrim-scanner is the first candidate to scrub ;)
>> Actually, I think about a common multi-functional scanner, with 3
>> modes:
>> 1) discard only (handle only free blocks);
>> 2) scrub only (handle only busy blocks);
>> 3) combined (scan the whole partition; for free blocks call discard,
>>       for busy ones call scrub).
>> Any ideas?
>>
>> Thanks,
>> Edward.
>> PS: We have an own ioctl number: 0xCD inherited from ReiserFS(v3).
> I still have to finish the erase unit detection (which has completely
> stalled) to merge all this work. Moreover:
>
> For the fstrim, we have dropped all locking and serialization issues
> and declared that fstrim is best-effort: if it misses some blocks due
> to concurrent transactions allocating and freeing blocks, it doesn't
> matter.
>
> For the scrub, this won't fly...

Indeed, the requirements to fstrim and scrub are different,
but, as I remember, the last decision was to not miss:
http://marc.info/?l=reiserfs-devel&m=141391883022745&w=2
so everything will fly just perfectly..

Edward.

Re: Reiser4 Upstream Git Repositories on GitHub

[Ivan Shapovalov]

[-- Attachment #1: Type: text/plain, Size: 10902 bytes --]

On 2016-09-28 at 21:58 +0200, Edward Shishkin wrote:
> 
> On 09/28/2016 05:03 PM, Ivan Shapovalov wrote:
> > On 2016-09-28 at 16:44 +0200, Edward Shishkin wrote:
> > > On 09/28/2016 03:56 PM, Edward Shishkin wrote:
> > > > 
> > > > On 09/28/2016 12:36 PM, Ivan Shapovalov wrote:
> > > > > On 2016-09-28 at 12:17 +0200, Edward Shishkin wrote:
> > > > > > On 09/27/2016 11:51 PM, Ivan Shapovalov wrote:
> > > > > > > On 2016-09-27 at 23:47 +0200, Edward Shishkin wrote:
> > > > > > > > On 09/27/2016 08:36 PM, Ivan Shapovalov wrote:
> > > > > > > > > On 2016-09-27 at 16:13 +0200, Edward Shishkin wrote:
> > > > > > > > > > On 09/27/2016 04:43 AM, Ivan Shapovalov wrote:
> > > > > > > > > > > On 2016-09-27 at 00:37 +0200, Edward Shishkin
> > > > > > > > > > > wrote:
> > > > > > > > > > > > On 09/27/2016 12:05 AM, Ivan Shapovalov wrote:
> > > > > > > > > > > > > On 2016-09-24 at 22:16 +0200, Edward Shishkin
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > Hello everyone,
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > I have set up the updated Namesys
> > > > > > > > > > > > > > repositories
> > > > > > > > > > > > > > at my
> > > > > > > > > > > > > > Github
> > > > > > > > > > > > > > page.
> > > > > > > > > > > > > > Those repositories are supposed to contain
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > latest
> > > > > > > > > > > > > > updates
> > > > > > > > > > > > > > in
> > > > > > > > > > > > > > the (stable) master branch and in other
> > > > > > > > > > > > > > (experimental)
> > > > > > > > > > > > > > branches
> > > > > > > > > > > > > > that
> > > > > > > > > > > > > > I'll announce.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > 1) https://github.com/edward6/reiser4
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > This is a "standalone" reiser4 tree, which
> > > > > > > > > > > > > > doesn't
> > > > > > > > > > > > > > include
> > > > > > > > > > > > > > specific
> > > > > > > > > > > > > > changes of Linux kernel needed for reiser4
> > > > > > > > > > > > > > port. Such
> > > > > > > > > > > > > > changes
> > > > > > > > > > > > > > can
> > > > > > > > > > > > > > be
> > > > > > > > > > > > > > found at the project's page on Sourceforge:
> > > > > > > > > > > > > > https://sourceforge.net/projects/reiser4/
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > An example of work with the standalone
> > > > > > > > > > > > > > reiser4
> > > > > > > > > > > > > > tree:
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > . Patch the respective kernel with the
> > > > > > > > > > > > > > latest
> > > > > > > > > > > > > > available
> > > > > > > > > > > > > > stuff
> > > > > > > > > > > > > > from
> > > > > > > > > > > > > >          Sourceforge;
> > > > > > > > > > > > > > . cd to the "fs" directory;
> > > > > > > > > > > > > > . delete the directory reiser4;
> > > > > > > > > > > > > > . instead of the deleted stuff clone the
> > > > > > > > > > > > > > standalone
> > > > > > > > > > > > > > reiser4
> > > > > > > > > > > > > >          repository from Github;
> > > > > > > > > > > > > > . build and install as usual.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > 2) Libaal and Reiser4progs:
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > https://github.com/edward6/libaal
> > > > > > > > > > > > > > https://github.com/edward6/reiser4progs
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Before building Libaal and Reiser4progs
> > > > > > > > > > > > > > execute
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > ./prepare
> > > > > > > > > > > > > > script,
> > > > > > > > > > > > > > which will create files needed for build
> > > > > > > > > > > > > > process.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > Edward.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Wow, finally.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Maybe we could avoid that "all changes for 10
> > > > > > > > > > > > > years"
> > > > > > > > > > > > > commit?
> > > > > > > > > > > > 
> > > > > > > > > > > > Hi Ivan,
> > > > > > > > > > > > Sorry, don't have a time to granulate it.
> > > > > > > > > > > > 
> > > > > > > > > > > > > I tried to keep track of all patches since
> > > > > > > > > > > > > 3.2...
> > > > > > > > > > > > 
> > > > > > > > > > > > There will be "all changes for 6 years" commit.
> > > > > > > > > > > > Is it much better?
> > > > > > > > > > > 
> > > > > > > > > > > So well, I finished splitting off all known diffs
> > > > > > > > > > > from that
> > > > > > > > > > > big
> > > > > > > > > > > commit.
> > > > > > > > > > > Tt was 12k(+)/8k(-), now it is 7k(+)/7k(-).
> > > > > > > > > > > 
> > > > > > > > > > > The updated branch is here: https://github.com/in
> > > > > > > > > > > telf
> > > > > > > > > > > x/reis
> > > > > > > > > > > er4
> > > > > > > > > > > (unfortunately, not fast-forward).
> > > > > > > > > > > 
> > > > > > > > > > > Moreover, my tree has accumulated quite a few
> > > > > > > > > > > differences
> > > > > > > > > > > from
> > > > > > > > > > > your
> > > > > > > > > > > one. I've dropped trivial discrepancies
> > > > > > > > > > > (comments,
> > > > > > > > > > > formatting
> > > > > > > > > > > etc.)
> > > > > > > > > > > and put the larger ones in separate branches:
> > > > > > > > > > > 
> > > > > > > > > > > 1. https://github.com/intelfx/reiser4/tree/differ
> > > > > > > > > > > ence
> > > > > > > > > > > s/enot
> > > > > > > > > > > ty
> > > > > > > > > > >         (unsupported ioctls return -ENOTTY, not
> > > > > > > > > > > -ENOSYS)
> > > > > > > > > > > 
> > > > > > > > > > > 2. https://github.com/intelfx/reiser4/tree/differ
> > > > > > > > > > > ence
> > > > > > > > > > > s/migr
> > > > > > > > > > > atep
> > > > > > > > > > > age
> > > > > > > > > > >         (the ->migratepage() implementation,
> > > > > > > > > > > which I
> > > > > > > > > > > still do
> > > > > > > > > > > not
> > > > > > > > > > > completely
> > > > > > > > > > >          understand, but it works)
> > > > > > > > > > > 
> > > > > > > > > > > 3. https://github.com/intelfx/reiser4/tree/differ
> > > > > > > > > > > ence
> > > > > > > > > > > s/rena
> > > > > > > > > > > meat
> > > > > > > > > > > 2
> > > > > > > > > > >         (renameat2(RENAME_NOREPLACE)
> > > > > > > > > > > implementation,
> > > > > > > > > > > which
> > > > > > > > > > > you
> > > > > > > > > > > haven't
> > > > > > > > > > >          merged somewhy)
> > > > > > > > > > > 
> > > > > > > > > > > 4. https://github.com/intelfx/reiser4/tree/differ
> > > > > > > > > > > ence
> > > > > > > > > > > s/adju
> > > > > > > > > > > st-t
> > > > > > > > > > > o-3.
> > > > > > > > > > > 15
> > > > > > > > > > >         (part of porting to 3.15 which, again,
> > > > > > > > > > > you
> > > > > > > > > > > haven't
> > > > > > > > > > > merged
> > > > > > > > > > > somewhy)
> > > > > > > > > > > 
> > > > > > > > > > > These branches are on top of that granular
> > > > > > > > > > > "master".
> > > > > > > > > > > Anyway, please take a look.
> > > > > > > > > > 
> > > > > > > > > > It was definitely useful work,
> > > > > > > > > > I'll look at those differences..
> > > > > > > > > 
> > > > > > > > > Maybe you could also consider rebasing things on top
> > > > > > > > > of
> > > > > > > > > that
> > > > > > > > > extracted
> > > > > > > > > granular history?
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > Interesting idea, but I am not able to estimate
> > > > > > > > complexity of such rebasing for now.
> > > > > > > > 
> > > > > > > 
> > > > > > > While we do not have any forks and can afford non-fast-
> > > > > > > forward
> > > > > > > updates
> > > > > > > of master, the complexity is almost nil.
> > > > > > > 
> > > > > > > To rebase your format41 branch, one can do this:
> > > > > > > 
> > > > > > > git rebase --preserve-merges --onto
> > > > > > > 3c7b3c5802e20381496f641fe64b6c1573228c6e
> > > > > > > 8a896fd48ed35c7dfa0188f9b7f4cbdfd469cacb format41
> > > > > > > 
> > > > > > > where 8a896fd is merge-base of format41 and master (that
> > > > > > > big
> > > > > > > commit),
> > > > > > > and 3c7b3c5 is the corresponding commit of the
> > > > > > > synthesized
> > > > > > > history.
> > > > > > > 
> > > > > > > Both commits have identical file content (`git diff
> > > > > > > 8a896fd
> > > > > > > 3c7b3c5`
> > > > > > > yields empty output).
> > > > > > 
> > > > > > OK, everything went smoothly,
> > > > > > Thanks for scrupulously archiving things!
> > > > > > 
> > > > > > Edward.
> > > > > 
> > > > > Great. (In fact, I intended this to be `git push -f`-ed, not
> > > > > `git
> > > > > merge`-ed with original history, but well, git blame now does
> > > > > the
> > > > > right
> > > > > thing, so it's good enough as it is.)
> > > > > 
> > > > > We do not use github pull requests and still send formatted
> > > > > patch
> > > > > series to the ML, correct?
> > > > > 
> > > > 
> > > > Yup, everything to the list, as usual..
> > > 
> > > BTW, your fstrim-scanner is the first candidate to scrub ;)
> > > Actually, I think about a common multi-functional scanner, with 3
> > > modes:
> > > 1) discard only (handle only free blocks);
> > > 2) scrub only (handle only busy blocks);
> > > 3) combined (scan the whole partition; for free blocks call
> > > discard,
> > >       for busy ones call scrub).
> > > Any ideas?
> > > 
> > > Thanks,
> > > Edward.
> > > PS: We have an own ioctl number: 0xCD inherited from
> > > ReiserFS(v3).
> > 
> > I still have to finish the erase unit detection (which has
> > completely
> > stalled) to merge all this work. Moreover:
> > 
> > For the fstrim, we have dropped all locking and serialization
> > issues
> > and declared that fstrim is best-effort: if it misses some blocks
> > due
> > to concurrent transactions allocating and freeing blocks, it
> > doesn't
> > matter.
> > 
> > For the scrub, this won't fly...
> 
> Indeed, the requirements to fstrim and scrub are different,
> but, as I remember, the last decision was to not miss:
> http://marc.info/?l=reiserfs-devel&m=141391883022745&w=2
> so everything will fly just perfectly..
> 
> Edward.

This is different thing, it's about grabbing space in bigger chunks...
If a concurrent transaction allocates some space and frees some space,
we don't care, because it will then be discarded "online".

But in case of the scrub, how do we protect from the storage tree
changing right beneath us?

How is it solved in btrfs? Do they take a temporary snapshot?

-- 
Ivan Shapovalov / intelfx /

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: Reiser4 Upstream Git Repositories on GitHub

[Edward Shishkin]

On 09/28/2016 11:50 PM, Ivan Shapovalov wrote:
> On 2016-09-28 at 21:58 +0200, Edward Shishkin wrote:
>> On 09/28/2016 05:03 PM, Ivan Shapovalov wrote:
>>> On 2016-09-28 at 16:44 +0200, Edward Shishkin wrote:
>>>> On 09/28/2016 03:56 PM, Edward Shishkin wrote:
>>>>> On 09/28/2016 12:36 PM, Ivan Shapovalov wrote:
>>>>>> On 2016-09-28 at 12:17 +0200, Edward Shishkin wrote:
>>>>>>> On 09/27/2016 11:51 PM, Ivan Shapovalov wrote:
>>>>>>>> On 2016-09-27 at 23:47 +0200, Edward Shishkin wrote:
>>>>>>>>> On 09/27/2016 08:36 PM, Ivan Shapovalov wrote:
>>>>>>>>>> On 2016-09-27 at 16:13 +0200, Edward Shishkin wrote:
>>>>>>>>>>> On 09/27/2016 04:43 AM, Ivan Shapovalov wrote:
>>>>>>>>>>>> On 2016-09-27 at 00:37 +0200, Edward Shishkin
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> On 09/27/2016 12:05 AM, Ivan Shapovalov wrote:
>>>>>>>>>>>>>> On 2016-09-24 at 22:16 +0200, Edward Shishkin
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> Hello everyone,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I have set up the updated Namesys
>>>>>>>>>>>>>>> repositories
>>>>>>>>>>>>>>> at my
>>>>>>>>>>>>>>> Github
>>>>>>>>>>>>>>> page.
>>>>>>>>>>>>>>> Those repositories are supposed to contain
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> latest
>>>>>>>>>>>>>>> updates
>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>> the (stable) master branch and in other
>>>>>>>>>>>>>>> (experimental)
>>>>>>>>>>>>>>> branches
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> I'll announce.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 1) https://github.com/edward6/reiser4
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This is a "standalone" reiser4 tree, which
>>>>>>>>>>>>>>> doesn't
>>>>>>>>>>>>>>> include
>>>>>>>>>>>>>>> specific
>>>>>>>>>>>>>>> changes of Linux kernel needed for reiser4
>>>>>>>>>>>>>>> port. Such
>>>>>>>>>>>>>>> changes
>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>> found at the project's page on Sourceforge:
>>>>>>>>>>>>>>> https://sourceforge.net/projects/reiser4/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> An example of work with the standalone
>>>>>>>>>>>>>>> reiser4
>>>>>>>>>>>>>>> tree:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> . Patch the respective kernel with the
>>>>>>>>>>>>>>> latest
>>>>>>>>>>>>>>> available
>>>>>>>>>>>>>>> stuff
>>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>>           Sourceforge;
>>>>>>>>>>>>>>> . cd to the "fs" directory;
>>>>>>>>>>>>>>> . delete the directory reiser4;
>>>>>>>>>>>>>>> . instead of the deleted stuff clone the
>>>>>>>>>>>>>>> standalone
>>>>>>>>>>>>>>> reiser4
>>>>>>>>>>>>>>>           repository from Github;
>>>>>>>>>>>>>>> . build and install as usual.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2) Libaal and Reiser4progs:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> https://github.com/edward6/libaal
>>>>>>>>>>>>>>> https://github.com/edward6/reiser4progs
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Before building Libaal and Reiser4progs
>>>>>>>>>>>>>>> execute
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> ./prepare
>>>>>>>>>>>>>>> script,
>>>>>>>>>>>>>>> which will create files needed for build
>>>>>>>>>>>>>>> process.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> Edward.
>>>>>>>>>>>>>> Wow, finally.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Maybe we could avoid that "all changes for 10
>>>>>>>>>>>>>> years"
>>>>>>>>>>>>>> commit?
>>>>>>>>>>>>> Hi Ivan,
>>>>>>>>>>>>> Sorry, don't have a time to granulate it.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I tried to keep track of all patches since
>>>>>>>>>>>>>> 3.2...
>>>>>>>>>>>>> There will be "all changes for 6 years" commit.
>>>>>>>>>>>>> Is it much better?
>>>>>>>>>>>> So well, I finished splitting off all known diffs
>>>>>>>>>>>> from that
>>>>>>>>>>>> big
>>>>>>>>>>>> commit.
>>>>>>>>>>>> Tt was 12k(+)/8k(-), now it is 7k(+)/7k(-).
>>>>>>>>>>>>
>>>>>>>>>>>> The updated branch is here: https://github.com/in
>>>>>>>>>>>> telf
>>>>>>>>>>>> x/reis
>>>>>>>>>>>> er4
>>>>>>>>>>>> (unfortunately, not fast-forward).
>>>>>>>>>>>>
>>>>>>>>>>>> Moreover, my tree has accumulated quite a few
>>>>>>>>>>>> differences
>>>>>>>>>>>> from
>>>>>>>>>>>> your
>>>>>>>>>>>> one. I've dropped trivial discrepancies
>>>>>>>>>>>> (comments,
>>>>>>>>>>>> formatting
>>>>>>>>>>>> etc.)
>>>>>>>>>>>> and put the larger ones in separate branches:
>>>>>>>>>>>>
>>>>>>>>>>>> 1. https://github.com/intelfx/reiser4/tree/differ
>>>>>>>>>>>> ence
>>>>>>>>>>>> s/enot
>>>>>>>>>>>> ty
>>>>>>>>>>>>          (unsupported ioctls return -ENOTTY, not
>>>>>>>>>>>> -ENOSYS)
>>>>>>>>>>>>
>>>>>>>>>>>> 2. https://github.com/intelfx/reiser4/tree/differ
>>>>>>>>>>>> ence
>>>>>>>>>>>> s/migr
>>>>>>>>>>>> atep
>>>>>>>>>>>> age
>>>>>>>>>>>>          (the ->migratepage() implementation,
>>>>>>>>>>>> which I
>>>>>>>>>>>> still do
>>>>>>>>>>>> not
>>>>>>>>>>>> completely
>>>>>>>>>>>>           understand, but it works)
>>>>>>>>>>>>
>>>>>>>>>>>> 3. https://github.com/intelfx/reiser4/tree/differ
>>>>>>>>>>>> ence
>>>>>>>>>>>> s/rena
>>>>>>>>>>>> meat
>>>>>>>>>>>> 2
>>>>>>>>>>>>          (renameat2(RENAME_NOREPLACE)
>>>>>>>>>>>> implementation,
>>>>>>>>>>>> which
>>>>>>>>>>>> you
>>>>>>>>>>>> haven't
>>>>>>>>>>>>           merged somewhy)
>>>>>>>>>>>>
>>>>>>>>>>>> 4. https://github.com/intelfx/reiser4/tree/differ
>>>>>>>>>>>> ence
>>>>>>>>>>>> s/adju
>>>>>>>>>>>> st-t
>>>>>>>>>>>> o-3.
>>>>>>>>>>>> 15
>>>>>>>>>>>>          (part of porting to 3.15 which, again,
>>>>>>>>>>>> you
>>>>>>>>>>>> haven't
>>>>>>>>>>>> merged
>>>>>>>>>>>> somewhy)
>>>>>>>>>>>>
>>>>>>>>>>>> These branches are on top of that granular
>>>>>>>>>>>> "master".
>>>>>>>>>>>> Anyway, please take a look.
>>>>>>>>>>> It was definitely useful work,
>>>>>>>>>>> I'll look at those differences..
>>>>>>>>>> Maybe you could also consider rebasing things on top
>>>>>>>>>> of
>>>>>>>>>> that
>>>>>>>>>> extracted
>>>>>>>>>> granular history?
>>>>>>>>>>
>>>>>>>>> Interesting idea, but I am not able to estimate
>>>>>>>>> complexity of such rebasing for now.
>>>>>>>>>
>>>>>>>> While we do not have any forks and can afford non-fast-
>>>>>>>> forward
>>>>>>>> updates
>>>>>>>> of master, the complexity is almost nil.
>>>>>>>>
>>>>>>>> To rebase your format41 branch, one can do this:
>>>>>>>>
>>>>>>>> git rebase --preserve-merges --onto
>>>>>>>> 3c7b3c5802e20381496f641fe64b6c1573228c6e
>>>>>>>> 8a896fd48ed35c7dfa0188f9b7f4cbdfd469cacb format41
>>>>>>>>
>>>>>>>> where 8a896fd is merge-base of format41 and master (that
>>>>>>>> big
>>>>>>>> commit),
>>>>>>>> and 3c7b3c5 is the corresponding commit of the
>>>>>>>> synthesized
>>>>>>>> history.
>>>>>>>>
>>>>>>>> Both commits have identical file content (`git diff
>>>>>>>> 8a896fd
>>>>>>>> 3c7b3c5`
>>>>>>>> yields empty output).
>>>>>>> OK, everything went smoothly,
>>>>>>> Thanks for scrupulously archiving things!
>>>>>>>
>>>>>>> Edward.
>>>>>> Great. (In fact, I intended this to be `git push -f`-ed, not
>>>>>> `git
>>>>>> merge`-ed with original history, but well, git blame now does
>>>>>> the
>>>>>> right
>>>>>> thing, so it's good enough as it is.)
>>>>>>
>>>>>> We do not use github pull requests and still send formatted
>>>>>> patch
>>>>>> series to the ML, correct?
>>>>>>
>>>>> Yup, everything to the list, as usual..
>>>> BTW, your fstrim-scanner is the first candidate to scrub ;)
>>>> Actually, I think about a common multi-functional scanner, with 3
>>>> modes:
>>>> 1) discard only (handle only free blocks);
>>>> 2) scrub only (handle only busy blocks);
>>>> 3) combined (scan the whole partition; for free blocks call
>>>> discard,
>>>>        for busy ones call scrub).
>>>> Any ideas?
>>>>
>>>> Thanks,
>>>> Edward.
>>>> PS: We have an own ioctl number: 0xCD inherited from
>>>> ReiserFS(v3).
>>> I still have to finish the erase unit detection (which has
>>> completely
>>> stalled) to merge all this work. Moreover:
>>>
>>> For the fstrim, we have dropped all locking and serialization
>>> issues
>>> and declared that fstrim is best-effort: if it misses some blocks
>>> due
>>> to concurrent transactions allocating and freeing blocks, it
>>> doesn't
>>> matter.
>>>
>>> For the scrub, this won't fly...
>> Indeed, the requirements to fstrim and scrub are different,
>> but, as I remember, the last decision was to not miss:
>> http://marc.info/?l=reiserfs-devel&m=141391883022745&w=2
>> so everything will fly just perfectly..
>>
>> Edward.
> This is different thing, it's about grabbing space in bigger chunks...
> If a concurrent transaction allocates some space and frees some space,
> we don't care, because it will then be discarded "online".
>
> But in case of the scrub, how do we protect from the storage tree
> changing right beneath us?

Yup, it seems that the idea of common scanner is dead.
It should be an independent tool. I think, we need to simply scan the
storage tree, do whatever is needed for each node, and make it dirty.

Edward.

Re: Reiser4 Upstream Git Repositories on GitHub

[Ivan Shapovalov]

[-- Attachment #1: Type: text/plain, Size: 2455 bytes --]

On 2016-09-29 at 17:07 +0200, Edward Shishkin wrote:
> 
> On 09/28/2016 11:50 PM, Ivan Shapovalov wrote:
> > On 2016-09-28 at 21:58 +0200, Edward Shishkin wrote:
> > > On 09/28/2016 05:03 PM, Ivan Shapovalov wrote:
> > > > On 2016-09-28 at 16:44 +0200, Edward Shishkin wrote:
> > > > > [...]
> > > > > 
> > > > > BTW, your fstrim-scanner is the first candidate to scrub ;)
> > > > > Actually, I think about a common multi-functional scanner,
> > > > > with 3
> > > > > modes:
> > > > > 1) discard only (handle only free blocks);
> > > > > 2) scrub only (handle only busy blocks);
> > > > > 3) combined (scan the whole partition; for free blocks call
> > > > > discard,
> > > > >        for busy ones call scrub).
> > > > > Any ideas?
> > > > > 
> > > > > Thanks,
> > > > > Edward.
> > > > > PS: We have an own ioctl number: 0xCD inherited from
> > > > > ReiserFS(v3).
> > > > 
> > > > I still have to finish the erase unit detection (which has
> > > > completely
> > > > stalled) to merge all this work. Moreover:
> > > > 
> > > > For the fstrim, we have dropped all locking and serialization
> > > > issues
> > > > and declared that fstrim is best-effort: if it misses some
> > > > blocks
> > > > due
> > > > to concurrent transactions allocating and freeing blocks, it
> > > > doesn't
> > > > matter.
> > > > 
> > > > For the scrub, this won't fly...
> > > 
> > > Indeed, the requirements to fstrim and scrub are different,
> > > but, as I remember, the last decision was to not miss:
> > > http://marc.info/?l=reiserfs-devel&m=141391883022745&w=2
> > > so everything will fly just perfectly..
> > > 
> > > Edward.
> > 
> > This is different thing, it's about grabbing space in bigger
> > chunks...
> > If a concurrent transaction allocates some space and frees some
> > space,
> > we don't care, because it will then be discarded "online".
> > 
> > But in case of the scrub, how do we protect from the storage tree
> > changing right beneath us?
> 
> Yup, it seems that the idea of common scanner is dead.
> It should be an independent tool. I think, we need to simply scan the
> storage tree, do whatever is needed for each node, and make it dirty.
> 
> Edward.

How does it work in btrfs? They have their "allocation group"
equivalents ("chunks", IIRC), so I suppose they just walk them
sequentially and lock each one completely for processing?

-- 
Ivan Shapovalov / intelfx /

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: Reiser4 Upstream Git Repositories on GitHub

[Ivan Shapovalov]

[-- Attachment #1: Type: text/plain, Size: 6109 bytes --]

On 2016-09-28 at 12:17 +0200, Edward Shishkin wrote:
> On 09/27/2016 11:51 PM, Ivan Shapovalov wrote:
> > On 2016-09-27 at 23:47 +0200, Edward Shishkin wrote:
> > > On 09/27/2016 08:36 PM, Ivan Shapovalov wrote:
> > > > On 2016-09-27 at 16:13 +0200, Edward Shishkin wrote:
> > > > > On 09/27/2016 04:43 AM, Ivan Shapovalov wrote:
> > > > > > On 2016-09-27 at 00:37 +0200, Edward Shishkin wrote:
> > > > > > > On 09/27/2016 12:05 AM, Ivan Shapovalov wrote:
> > > > > > > > On 2016-09-24 at 22:16 +0200, Edward Shishkin wrote:
> > > > > > > > > Hello everyone,
> > > > > > > > > 
> > > > > > > > > I have set up the updated Namesys repositories at my
> > > > > > > > > Github
> > > > > > > > > page.
> > > > > > > > > Those repositories are supposed to contain the latest
> > > > > > > > > updates
> > > > > > > > > in
> > > > > > > > > the (stable) master branch and in other
> > > > > > > > > (experimental)
> > > > > > > > > branches
> > > > > > > > > that
> > > > > > > > > I'll announce.
> > > > > > > > > 
> > > > > > > > > 1) https://github.com/edward6/reiser4
> > > > > > > > > 
> > > > > > > > > This is a "standalone" reiser4 tree, which doesn't
> > > > > > > > > include
> > > > > > > > > specific
> > > > > > > > > changes of Linux kernel needed for reiser4 port. Such
> > > > > > > > > changes
> > > > > > > > > can
> > > > > > > > > be
> > > > > > > > > found at the project's page on Sourceforge:
> > > > > > > > > https://sourceforge.net/projects/reiser4/
> > > > > > > > > 
> > > > > > > > > An example of work with the standalone reiser4 tree:
> > > > > > > > > 
> > > > > > > > > . Patch the respective kernel with the latest
> > > > > > > > > available
> > > > > > > > > stuff
> > > > > > > > > from
> > > > > > > > >        Sourceforge;
> > > > > > > > > . cd to the "fs" directory;
> > > > > > > > > . delete the directory reiser4;
> > > > > > > > > . instead of the deleted stuff clone the standalone
> > > > > > > > > reiser4
> > > > > > > > >        repository from Github;
> > > > > > > > > . build and install as usual.
> > > > > > > > > 
> > > > > > > > > 2) Libaal and Reiser4progs:
> > > > > > > > > 
> > > > > > > > > https://github.com/edward6/libaal
> > > > > > > > > https://github.com/edward6/reiser4progs
> > > > > > > > > 
> > > > > > > > > Before building Libaal and Reiser4progs execute the
> > > > > > > > > ./prepare
> > > > > > > > > script,
> > > > > > > > > which will create files needed for build process.
> > > > > > > > > 
> > > > > > > > > Thanks,
> > > > > > > > > Edward.
> > > > > > > > 
> > > > > > > > Wow, finally.
> > > > > > > > 
> > > > > > > > Maybe we could avoid that "all changes for 10 years"
> > > > > > > > commit?
> > > > > > > 
> > > > > > > Hi Ivan,
> > > > > > > Sorry, don't have a time to granulate it.
> > > > > > > 
> > > > > > > > I tried to keep track of all patches since 3.2...
> > > > > > > 
> > > > > > > There will be "all changes for 6 years" commit.
> > > > > > > Is it much better?
> > > > > > 
> > > > > > So well, I finished splitting off all known diffs from that
> > > > > > big
> > > > > > commit.
> > > > > > Tt was 12k(+)/8k(-), now it is 7k(+)/7k(-).
> > > > > > 
> > > > > > The updated branch is here: https://github.com/intelfx/reis
> > > > > > er4
> > > > > > (unfortunately, not fast-forward).
> > > > > > 
> > > > > > Moreover, my tree has accumulated quite a few differences
> > > > > > from
> > > > > > your
> > > > > > one. I've dropped trivial discrepancies (comments,
> > > > > > formatting
> > > > > > etc.)
> > > > > > and put the larger ones in separate branches:
> > > > > > 
> > > > > > 1. https://github.com/intelfx/reiser4/tree/differences/enot
> > > > > > ty
> > > > > >       (unsupported ioctls return -ENOTTY, not -ENOSYS)
> > > > > > 
> > > > > > 2. https://github.com/intelfx/reiser4/tree/differences/migr
> > > > > > atep
> > > > > > age
> > > > > >       (the ->migratepage() implementation, which I still do
> > > > > > not
> > > > > > completely
> > > > > >        understand, but it works)
> > > > > > 
> > > > > > 3. https://github.com/intelfx/reiser4/tree/differences/rena
> > > > > > meat
> > > > > > 2
> > > > > >       (renameat2(RENAME_NOREPLACE) implementation, which
> > > > > > you
> > > > > > haven't
> > > > > >        merged somewhy)
> > > > > > 
> > > > > > 4. https://github.com/intelfx/reiser4/tree/differences/adju
> > > > > > st-t
> > > > > > o-3.
> > > > > > 15
> > > > > >       (part of porting to 3.15 which, again, you haven't
> > > > > > merged
> > > > > > somewhy)
> > > > > > 
> > > > > > These branches are on top of that granular "master".
> > > > > > Anyway, please take a look.
> > > > > 
> > > > > It was definitely useful work,
> > > > > I'll look at those differences..
> > > > 
> > > > Maybe you could also consider rebasing things on top of that
> > > > extracted
> > > > granular history?
> > > > 
> > > 
> > > Interesting idea, but I am not able to estimate
> > > complexity of such rebasing for now.
> > > 
> > 
> > While we do not have any forks and can afford non-fast-forward
> > updates
> > of master, the complexity is almost nil.
> > 
> > To rebase your format41 branch, one can do this:
> > 
> > git rebase --preserve-merges --onto
> > 3c7b3c5802e20381496f641fe64b6c1573228c6e
> > 8a896fd48ed35c7dfa0188f9b7f4cbdfd469cacb format41
> > 
> > where 8a896fd is merge-base of format41 and master (that big
> > commit),
> > and 3c7b3c5 is the corresponding commit of the synthesized history.
> > 
> > Both commits have identical file content (`git diff 8a896fd
> > 3c7b3c5`
> > yields empty output).
> 
> OK, everything went smoothly,
> Thanks for scrupulously archiving things!
> 
> Edward.

In meantime, I have also generated a history of the kernel side changes
(again, starting with 3.2). They are pretty small.
Do I understand correctly that the kernel folks are reluctant to merge
these ~150 lines?

-- 
Ivan Shapovalov / intelfx /

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: Reiser4 Upstream Git Repositories on GitHub

[Edward Shishkin]

On 09/30/2016 08:56 AM, Ivan Shapovalov wrote:
> On 2016-09-28 at 12:17 +0200, Edward Shishkin wrote:
>> On 09/27/2016 11:51 PM, Ivan Shapovalov wrote:
>>> On 2016-09-27 at 23:47 +0200, Edward Shishkin wrote:
>>>> On 09/27/2016 08:36 PM, Ivan Shapovalov wrote:
>>>>> On 2016-09-27 at 16:13 +0200, Edward Shishkin wrote:
>>>>>> On 09/27/2016 04:43 AM, Ivan Shapovalov wrote:
>>>>>>> On 2016-09-27 at 00:37 +0200, Edward Shishkin wrote:
>>>>>>>> On 09/27/2016 12:05 AM, Ivan Shapovalov wrote:
>>>>>>>>> On 2016-09-24 at 22:16 +0200, Edward Shishkin wrote:
>>>>>>>>>> Hello everyone,
>>>>>>>>>>
>>>>>>>>>> I have set up the updated Namesys repositories at my
>>>>>>>>>> Github
>>>>>>>>>> page.
>>>>>>>>>> Those repositories are supposed to contain the latest
>>>>>>>>>> updates
>>>>>>>>>> in
>>>>>>>>>> the (stable) master branch and in other
>>>>>>>>>> (experimental)
>>>>>>>>>> branches
>>>>>>>>>> that
>>>>>>>>>> I'll announce.
>>>>>>>>>>
>>>>>>>>>> 1) https://github.com/edward6/reiser4
>>>>>>>>>>
>>>>>>>>>> This is a "standalone" reiser4 tree, which doesn't
>>>>>>>>>> include
>>>>>>>>>> specific
>>>>>>>>>> changes of Linux kernel needed for reiser4 port. Such
>>>>>>>>>> changes
>>>>>>>>>> can
>>>>>>>>>> be
>>>>>>>>>> found at the project's page on Sourceforge:
>>>>>>>>>> https://sourceforge.net/projects/reiser4/
>>>>>>>>>>
>>>>>>>>>> An example of work with the standalone reiser4 tree:
>>>>>>>>>>
>>>>>>>>>> . Patch the respective kernel with the latest
>>>>>>>>>> available
>>>>>>>>>> stuff
>>>>>>>>>> from
>>>>>>>>>>         Sourceforge;
>>>>>>>>>> . cd to the "fs" directory;
>>>>>>>>>> . delete the directory reiser4;
>>>>>>>>>> . instead of the deleted stuff clone the standalone
>>>>>>>>>> reiser4
>>>>>>>>>>         repository from Github;
>>>>>>>>>> . build and install as usual.
>>>>>>>>>>
>>>>>>>>>> 2) Libaal and Reiser4progs:
>>>>>>>>>>
>>>>>>>>>> https://github.com/edward6/libaal
>>>>>>>>>> https://github.com/edward6/reiser4progs
>>>>>>>>>>
>>>>>>>>>> Before building Libaal and Reiser4progs execute the
>>>>>>>>>> ./prepare
>>>>>>>>>> script,
>>>>>>>>>> which will create files needed for build process.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Edward.
>>>>>>>>> Wow, finally.
>>>>>>>>>
>>>>>>>>> Maybe we could avoid that "all changes for 10 years"
>>>>>>>>> commit?
>>>>>>>> Hi Ivan,
>>>>>>>> Sorry, don't have a time to granulate it.
>>>>>>>>
>>>>>>>>> I tried to keep track of all patches since 3.2...
>>>>>>>> There will be "all changes for 6 years" commit.
>>>>>>>> Is it much better?
>>>>>>> So well, I finished splitting off all known diffs from that
>>>>>>> big
>>>>>>> commit.
>>>>>>> Tt was 12k(+)/8k(-), now it is 7k(+)/7k(-).
>>>>>>>
>>>>>>> The updated branch is here: https://github.com/intelfx/reis
>>>>>>> er4
>>>>>>> (unfortunately, not fast-forward).
>>>>>>>
>>>>>>> Moreover, my tree has accumulated quite a few differences
>>>>>>> from
>>>>>>> your
>>>>>>> one. I've dropped trivial discrepancies (comments,
>>>>>>> formatting
>>>>>>> etc.)
>>>>>>> and put the larger ones in separate branches:
>>>>>>>
>>>>>>> 1. https://github.com/intelfx/reiser4/tree/differences/enot
>>>>>>> ty
>>>>>>>        (unsupported ioctls return -ENOTTY, not -ENOSYS)
>>>>>>>
>>>>>>> 2. https://github.com/intelfx/reiser4/tree/differences/migr
>>>>>>> atep
>>>>>>> age
>>>>>>>        (the ->migratepage() implementation, which I still do
>>>>>>> not
>>>>>>> completely
>>>>>>>         understand, but it works)
>>>>>>>
>>>>>>> 3. https://github.com/intelfx/reiser4/tree/differences/rena
>>>>>>> meat
>>>>>>> 2
>>>>>>>        (renameat2(RENAME_NOREPLACE) implementation, which
>>>>>>> you
>>>>>>> haven't
>>>>>>>         merged somewhy)
>>>>>>>
>>>>>>> 4. https://github.com/intelfx/reiser4/tree/differences/adju
>>>>>>> st-t
>>>>>>> o-3.
>>>>>>> 15
>>>>>>>        (part of porting to 3.15 which, again, you haven't
>>>>>>> merged
>>>>>>> somewhy)
>>>>>>>
>>>>>>> These branches are on top of that granular "master".
>>>>>>> Anyway, please take a look.
>>>>>> It was definitely useful work,
>>>>>> I'll look at those differences..
>>>>> Maybe you could also consider rebasing things on top of that
>>>>> extracted
>>>>> granular history?
>>>>>
>>>> Interesting idea, but I am not able to estimate
>>>> complexity of such rebasing for now.
>>>>
>>> While we do not have any forks and can afford non-fast-forward
>>> updates
>>> of master, the complexity is almost nil.
>>>
>>> To rebase your format41 branch, one can do this:
>>>
>>> git rebase --preserve-merges --onto
>>> 3c7b3c5802e20381496f641fe64b6c1573228c6e
>>> 8a896fd48ed35c7dfa0188f9b7f4cbdfd469cacb format41
>>>
>>> where 8a896fd is merge-base of format41 and master (that big
>>> commit),
>>> and 3c7b3c5 is the corresponding commit of the synthesized history.
>>>
>>> Both commits have identical file content (`git diff 8a896fd
>>> 3c7b3c5`
>>> yields empty output).
>> OK, everything went smoothly,
>> Thanks for scrupulously archiving things!
>>
>> Edward.
> In meantime, I have also generated a history of the kernel side changes
> (again, starting with 3.2). They are pretty small.
> Do I understand correctly that the kernel folks are reluctant to merge
> these ~150 lines?

They are reluctant to merge stuff, which is not used by any subsystem
of upstream kernel.

Edward.

Re: Reiser4 Upstream Git Repositories on GitHub

[Edward Shishkin]

On 09/29/2016 05:07 PM, Edward Shishkin wrote:
[...]
> BTW, your fstrim-scanner is the first candidate to scrub ;)
>>>>> Actually, I think about a common multi-functional scanner, with 3
>>>>> modes:
>>>>> 1) discard only (handle only free blocks);
>>>>> 2) scrub only (handle only busy blocks);
>>>>> 3) combined (scan the whole partition; for free blocks call
>>>>> discard,
>>>>>        for busy ones call scrub).
>>>>> Any ideas?
>>>>>
>>>>> Thanks,
>>>>> Edward.
>>>>> PS: We have an own ioctl number: 0xCD inherited from
>>>>> ReiserFS(v3).
>>>> I still have to finish the erase unit detection (which has
>>>> completely
>>>> stalled) to merge all this work. Moreover:
>>>>
>>>> For the fstrim, we have dropped all locking and serialization
>>>> issues
>>>> and declared that fstrim is best-effort: if it misses some blocks
>>>> due
>>>> to concurrent transactions allocating and freeing blocks, it
>>>> doesn't
>>>> matter.
>>>>
>>>> For the scrub, this won't fly...
>>> Indeed, the requirements to fstrim and scrub are different,
>>> but, as I remember, the last decision was to not miss:
>>> http://marc.info/?l=reiserfs-devel&m=141391883022745&w=2
>>> so everything will fly just perfectly..
>>>
>>> Edward.
>> This is different thing, it's about grabbing space in bigger chunks...
>> If a concurrent transaction allocates some space and frees some space,
>> we don't care, because it will then be discarded "online".
>>
>> But in case of the scrub, how do we protect from the storage tree
>> changing right beneath us?
>
> Yup, it seems that the idea of common scanner is dead.
> It should be an independent tool. I think, we need to simply scan the
> storage tree, do whatever is needed for each node, and make it dirty.

My last thought is that online scrub is not needed.

Global synchronization issues can not happen online. They can happen
only offline (after fsck-ing). Respectively, I suggest to move the
global synchronization stuff to user-space, where it will be extremely
simple (a sort of dd-ing partitions in parallel, plus we'll need a
user-space version of init_volume.c to collect all mirrors properly).

What can happen online is only(*) local fixable problems (when after
IO completion page is uptodate, but checksum verification failed).
There are 2 approaches:

1) Fix those local problems online: if __jparse() detects a local
    problem, then simply issue a "correction" - a write request for the
    original subvolume, and wait for its completion _before_ marking
    jnode parsed (to prevent "rollbacks").

2) In the case of local problem mark status block of the volume to
    indicate that global synchronization is required before fsck-ing.
    Then we forget about all local problems in that mount session.
    I didn't calculate the probability of simultaneous corruption of
    original and replica blocks with the same blocknumbers (don't have
    any input numbers), but I suspect that it is vanishingly small.

So, we need either pre- and post-fsck global offline synchronizations,
or global post-fsck one plus online local self-healing.

----
(*) I don't consider non-fixable IO errors (including death of one or
more mirrors) that you can handle online with block layer's RAID-1.
However, we also can implement such kind of failover in reiser4.
Downgrading arrays is simple to implement. Upgrading ones will again
require global online synchronization (scrub).

Edward.