Logfs has been around a couple of times. Linus last word was "go and
don't come back until all format changes are done". Or something
along those lines at least.
Format changes are done. And I don't even intend to break git-bisect
for anyone crazy enough to use logfs for /. But then again, logfs
doesn't have the hype of btrfs, nor does it deserve it.
Most controversial bit (for me, at least) is the btree code. It is
generic enough to be used by others as well, but last time I checked,
rbtree performed better. So unless someone (me?) spends some time to
see what's going on, a short-term option would be to move it all under
fs/logfs/, making it unavailable for others and remove it completely
unless good arguments are found in favor.
Patch 18 is a bonus for anyone lucky enough to have a decent device.
For those not too familiar with mtd - all mtd operations are
synchronous. Which makes the interface horribly slow on devices that
support asynchronous operations, queueing or even parallel operations
on multiple chips. I have a prototype device that shows promise,
along with the usual problems of prototypes. So together with the
paper-thin infrastructure patch [1] and a decent device, that patch
allows logfs to make several thousand IO/s.
Mails are purely for review and comments. If this is deemed
merge-ready, please the git tree at
http://git.kernel.org/?p=linux/kernel/git/joern/logfs.git
instead.
[1] http://lists.infradead.org/pipermail/linux-mtd/2009-November/028065.html
Documentation/filesystems/00-INDEX | 2 +
Documentation/filesystems/logfs.txt | 241 ++++
fs/Kconfig | 1 +
fs/Makefile | 1 +
fs/logfs/Kconfig | 17 +
fs/logfs/Makefile | 13 +
fs/logfs/compr.c | 95 ++
fs/logfs/dev_bdev.c | 263 ++++
fs/logfs/dev_mtd.c | 253 ++++
fs/logfs/dir.c | 818 +++++++++++++
fs/logfs/file.c | 263 ++++
fs/logfs/gc.c | 730 ++++++++++++
fs/logfs/inode.c | 417 +++++++
fs/logfs/journal.c | 879 ++++++++++++++
fs/logfs/logfs.h | 722 +++++++++++
fs/logfs/logfs_abi.h | 627 ++++++++++
fs/logfs/readwrite.c | 2246 +++++++++++++++++++++++++++++++++++
fs/logfs/segment.c | 924 ++++++++++++++
fs/logfs/super.c | 634 ++++++++++
include/linux/btree-128.h | 109 ++
include/linux/btree-type.h | 147 +++
include/linux/btree.h | 243 ++++
lib/Kconfig | 3 +
lib/Makefile | 1 +
lib/btree.c | 797 +++++++++++++
25 files changed, 10446 insertions(+), 0 deletions(-)
On Friday 20 November 2009, Joern Engel wrote:
> Mails are purely for review and comments. If this is deemed
> merge-ready, please the git tree at
> http://git.kernel.org/?p=linux/kernel/git/joern/logfs.git
> instead.
I think merging is overdue, the code looks great and if you're
happy with it to go in, it's hard for anyone to argue with
that.
It should definitely be included in linux-next, and I guess it
should have been in there for some time, to get better
compile-time coverage across architectures, and some
more testing.
I can't find it in linux-next right now, but I could be
looking at the wrong stuff again, as I have before.
Arnd <><
On Mon, 23 November 2009 13:18:39 +0100, Arnd Bergmann wrote:
> On Friday 20 November 2009, Joern Engel wrote:
> > Mails are purely for review and comments. If this is deemed
> > merge-ready, please the git tree at
> > http://git.kernel.org/?p=linux/kernel/git/joern/logfs.git
> > instead.
>
> I think merging is overdue, the code looks great and if you're
> happy with it to go in, it's hard for anyone to argue with
> that.
>
> It should definitely be included in linux-next, and I guess it
> should have been in there for some time, to get better
> compile-time coverage across architectures, and some
> more testing.
>
> I can't find it in linux-next right now, but I could be
> looking at the wrong stuff again, as I have before.
Stephen,
do you have a reason not to add logfs to linux-next?
Jörn
--
Mundie uses a textbook tactic of manipulation: start with some
reasonable talk, and lead the audience to an unreasonable conclusion.
-- Bruce Perens
Hi Jörn,
On Wed, 25 Nov 2009 16:55:11 +0100 Jörn Engel <[email protected]> wrote:
>
> On Mon, 23 November 2009 13:18:39 +0100, Arnd Bergmann wrote:
> >
> > It should definitely be included in linux-next, and I guess it
> > should have been in there for some time, to get better
> > compile-time coverage across architectures, and some
> > more testing.
> >
> > I can't find it in linux-next right now, but I could be
> > looking at the wrong stuff again, as I have before.
>
> do you have a reason not to add logfs to linux-next?
Apart from not having been asked to do so, no ;-)
i.e. send me a request with the git url and I will add it.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
On Thu, 26 November 2009 10:51:03 +1100, Stephen Rothwell wrote:
> On Wed, 25 Nov 2009 16:55:11 +0100 Jörn Engel <[email protected]> wrote:
> >
> > do you have a reason not to add logfs to linux-next?
>
> Apart from not having been asked to do so, no ;-)
>
> i.e. send me a request with the git url and I will add it.
Being of sound state of mind, I hereby request that you add
git://git.kernel.org/pub/scm/linux/kernel/git/joern/logfs.git
to linux-next.
Something like that? Or would you doubt my state of mind if I willing
accept the risk of breaking others' compile and suffering the angry
emails that inevitably follow?
Jörn
--
A quarrel is quickly settled when deserted by one party; there is
no battle unless there be two.
-- Seneca
Hi Jörn,
On Thu, 26 Nov 2009 09:36:15 +0100 Jörn Engel <[email protected]> wrote:
>
> Being of sound state of mind, I hereby request that you add
:-)
> git://git.kernel.org/pub/scm/linux/kernel/git/joern/logfs.git
> to linux-next.
>
> Something like that? Or would you doubt my state of mind if I willing
> accept the risk of breaking others' compile and suffering the angry
> emails that inevitably follow?
Sometimes I question my own state of mind :-)
I have added the master branch of the above tree from today.
Thanks for adding your subsystem tree as a participant of linux-next. As
you may know, this is not a judgment of your code. The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window.
You will need to ensure that the patches/commits in your tree/series have
been:
* submitted under GPL v2 (or later) and include the Contributor's
Signed-off-by,
* posted to the relevant mailing list,
* reviewed by you (or another maintainer of your subsystem tree),
* successfully unit tested, and
* destined for the current or next Linux merge window.
Basically, this should be just what you would send to Linus (or ask him
to fetch). It is allowed to be rebased if you deem it necessary.
--
Cheers,
Stephen Rothwell
[email protected]
Legal Stuff:
By participating in linux-next, your subsystem tree contributions are
public and will be included in the linux-next trees. You may be sent
e-mail messages indicating errors or other issues when the
patches/commits from your subsystem tree are merged and tested in
linux-next. These messages may also be cross-posted to the linux-next
mailing list, the linux-kernel mailing list, etc. The linux-next tree
project and IBM (my employer) make no warranties regarding the linux-next
project, the testing procedures, the results, the e-mails, etc. If you
don't agree to these ground rules, let me know and I'll remove your tree
from participation in linux-next.