Re: Reiser4 Upstream Git Repositories on GitHub

[Edward Shishkin <edward.shishkin@gmail.com>]

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).