Re: Reiser4 Upstream Git Repositories on GitHub

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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).
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux File System Development]     [Linux BTRFS]     [Linux NFS]     [Linux Filesystems]     [Ext4 Filesystem]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Resources]

  Powered by Linux