lkml.org 
[lkml]   [2014]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PULL for 3.18] overlay filesystem v24
Date

Miklos Szeredi:
> It would be good to have an inode based union as well. I suggest (as
> I suggested many times) to try slimming aufs to a bare minimum and
> submit that. It may be easier to just start from scratch instead
> trying to drop features from the existing codebase. I'd be happy to
> review and generally help with such an effort.

??
In 2009, I have posted the "feature-reduced" version of aufs2 as
following your advice. Also a git-branch called "aufs2-tmp-ro" was
created whose size was a half of aufs2's. Have you ever posted your
review comments about them?

It was 2005 when I got an idea of aufs. Its history is almost a decade.
In my current local aufs3 develpment branch, I got about 350
commits. And 680 and 1120 commits for aufs2 and aufs1 individually.

aufs3-linux.git#aufs3.x-rcN/25lktr$ git log1 --no-merges fs/aufs/*.c | wc -l
348
aufs2-2.6.git#aufs2.2-stdalone-38-lktr$ git log1 --no-merges fs/aufs/*.c | wc -l
685
aufs1.git#master$ git log1 --no-merges aufs/fs/aufs/*.c | wc -l
1126

Of cource it won't be 2000 commits to create the patch series you
wrote. I don't know how large the number will be but I am sure this is
incredibly tough work both in commiting and reviewing. Is it still
helpful and really meaningful for you to review? Don't you think it will
be easier to review the resulted code?
For example, this branch was created for linux-3.9 when Al Viro wrote
about the dir mutex lock in copy-up. It has only 20 commits.

aufs3-linux.git#mainline-v3.9-rc8-20130428$ git log1 --no-merges fs/aufs/*.c | wc -l
20


J. R. Okajima


\
 
 \ /
  Last update: 2014-09-30 15:41    [W:0.045 / U:0.360 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site