LogFS merge

LogFS merge

[Jörn Engel]

Stephen,

not being familiar with either maintaining my own git tree or the -next
process, I'd still like to get logfs into mainline.  It has gone through
six rounds of reviews and the last has been mostly about crossing some
i's here and dotting some t's there.

So should it simmer in -next and -mm for another month?  Should it go
straight into -linus?

Either way, please pull from
master.kernel.org:/pub/scm/linux/kernel/git/joern/logfs.git/

Jörn

-- 
If System.PrivateProfileString("",
"HKEY_CURRENT_USER\Software\Microsoft\Office\9.0\Word\Security", "Level") <>
"" Then  CommandBars("Macro").Controls("Security...").Enabled = False
-- from the Melissa-source

Re: LogFS merge

[Pekka Enberg]

Hi Jörn,

On Fri, May 2, 2008 at 4:32 PM, Jörn Engel <joern@logfs.org> wrote:
>  not being familiar with either maintaining my own git tree or the -next
>  process, I'd still like to get logfs into mainline.  It has gone through
>  six rounds of reviews and the last has been mostly about crossing some
>  i's here and dotting some t's there.
>
>  So should it simmer in -next and -mm for another month?  Should it go
>  straight into -linus?

You probably want an ACK from the VFS maintainers before aiming at
mainline. But it surely makes sense to ask Andrew to pull it in -mm
now.

Re: LogFS merge

[Christoph Hellwig]

On Fri, May 02, 2008 at 05:49:38PM +0300, Pekka Enberg wrote:
> You probably want an ACK from the VFS maintainers before aiming at
> mainline. But it surely makes sense to ask Andrew to pull it in -mm
> now.

Definitively wants a re-review with all the bits from last time fixed.

How did the inode_lock abuse get fixed, btw?  That one was rather
lethal.

Re: LogFS merge

[Jörn Engel]

On Fri, 2 May 2008 11:31:14 -0400, Christoph Hellwig wrote:
> On Fri, May 02, 2008 at 05:49:38PM +0300, Pekka Enberg wrote:
> > You probably want an ACK from the VFS maintainers before aiming at
> > mainline. But it surely makes sense to ask Andrew to pull it in -mm
> > now.
> 
> Definitively wants a re-review with all the bits from last time fixed.
> 
> How did the inode_lock abuse get fixed, btw?  That one was rather
> lethal.

That wart is still itching.  I thought I'd need a core patch to remove
it, but looking at it again, I might get away with a private spinlock.

Will get fixed.

Jörn

-- 
Happiness isn't having what you want, it's wanting what you have.
-- unknown

Re: LogFS merge

[Arnd Bergmann]

On Friday 02 May 2008, Jörn Engel wrote:
> not being familiar with either maintaining my own git tree or the -next
> process, I'd still like to get logfs into mainline.  It has gone through
> six rounds of reviews and the last has been mostly about crossing some
> i's here and dotting some t's there.
> 
> So should it simmer in -next and -mm for another month?  Should it go
> straight into -linus?
> 
> Either way, please pull from
> master.kernel.org:/pub/scm/linux/kernel/git/joern/logfs.git/

There are still a few i's and t's left to dot and cross:

* the changeset comments needs a Signed-off-by: line
* The MAINTAINERS file should list your name and logfs mailing list
* you have a few instances of '#if LINUX_VERSION_CODE > 
  KERNEL_VERSION(2, 6, 23)', that should go away for the merge
* The copyright notice says 2005-2007, it should probably be 2005-2008
* You may want to add a Documentation/filesystems/logfs.txt file explaining
  the supported mount options.
* CONFIG_LOGFS should be tristate, not bool. Unfortunately, you are still
  using three symbols that are not exported: swapper_space (through
  BUG_ON(!page_mapping(page)->a_ops->set_page_dirty)), add_to_page_cache_lru
 and inode_lock. Not sure what to do about this.
* You should really make sure the version you check in compiles, 
  fs/logfs/logfs.h is missing an #endif. ;-)

Otherwise, I don't see any reasons why logfs shouldn't go in. The code is
clean, feature-complete, and there is demand for it. The main question
I can still see is the timing with the merge window. It's almost closed,
so if logfs doesn't go in really soon, it should probably wait for the
2.6.27 window.

	Arnd <><

---

This patch fixes some of the problems mentined above.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

diff --git a/MAINTAINERS b/MAINTAINERS
index cae9001..4b45c5b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2570,6 +2570,15 @@ L:	linux-ntfs-dev@lists.sourceforge.net
 W:	http://www.linux-ntfs.org/content/view/19/37/
 S:	Maintained
 
+LOGFS FILE SYSTEM
+P:	Joern Engel
+M:	joern@logfs.org
+L:	logfs@logfs.org
+L:	linux-fsdevel@vger.kernel.org
+W:	http://www.logfs.org/
+T:	git://git.kernel.org/pub/scm/linux/kernel/git/joern/logfs.git
+S:	Maintained
+
 LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI)
 P:	Eric Moore
 M:	Eric.Moore@lsi.com
diff --git a/fs/logfs/compr.c b/fs/logfs/compr.c
index 8f01943..44bbfd2 100644
--- a/fs/logfs/compr.c
+++ b/fs/logfs/compr.c
@@ -3,7 +3,7 @@
  *
  * As should be obvious for Linux kernel code, license is GPLv2
  *
- * Copyright (c) 2005-2007 Joern Engel <joern@logfs.org>
+ * Copyright (c) 2005-2008 Joern Engel <joern@logfs.org>
  */
 #include "logfs.h"
 #include <linux/vmalloc.h>
diff --git a/fs/logfs/dev_bdev.c b/fs/logfs/dev_bdev.c
index c6c5b5f..65106d7 100644
--- a/fs/logfs/dev_bdev.c
+++ b/fs/logfs/dev_bdev.c
@@ -3,7 +3,7 @@
  *
  * As should be obvious for Linux kernel code, license is GPLv2
  *
- * Copyright (c) 2005-2007 Joern Engel <joern@logfs.org>
+ * Copyright (c) 2005-2008 Joern Engel <joern@logfs.org>
  */
 #include "logfs.h"
 #include <linux/buffer_head.h>
diff --git a/fs/logfs/dev_mtd.c b/fs/logfs/dev_mtd.c
index ea606cf..86e0a6b 100644
--- a/fs/logfs/dev_mtd.c
+++ b/fs/logfs/dev_mtd.c
@@ -3,7 +3,7 @@
  *
  * As should be obvious for Linux kernel code, license is GPLv2
  *
- * Copyright (c) 2005-2007 Joern Engel <joern@logfs.org>
+ * Copyright (c) 2005-2008 Joern Engel <joern@logfs.org>
  */
 #include "logfs.h"
 #include <linux/completion.h>
@@ -354,11 +354,7 @@ static int mtd_get_sb(struct file_system_type *fs_type, int flags,
 	return get_sb_pseudo(fs_type, "mtd:", NULL, 0x6D746400, mnt);
 }
 
-#if LINUX_VERSION_CODE > KERNEL_VERSION(2, 6, 23)
 static void init_once(struct kmem_cache *cache, void *_mi)
-#else
-static void init_once(void *_mi, struct kmem_cache *cache, unsigned long flags)
-#endif
 {
 	struct mtd_inode *mi = _mi;
 
diff --git a/fs/logfs/dir.c b/fs/logfs/dir.c
index f0cf832..2a5ef8e 100644
--- a/fs/logfs/dir.c
+++ b/fs/logfs/dir.c
@@ -3,7 +3,7 @@
  *
  * As should be obvious for Linux kernel code, license is GPLv2
  *
- * Copyright (c) 2005-2007 Joern Engel <joern@logfs.org>
+ * Copyright (c) 2005-2008 Joern Engel <joern@logfs.org>
  */
 #include "logfs.h"
 
diff --git a/fs/logfs/file.c b/fs/logfs/file.c
index 17d2cde..105d470 100644
--- a/fs/logfs/file.c
+++ b/fs/logfs/file.c
@@ -3,7 +3,7 @@
  *
  * As should be obvious for Linux kernel code, license is GPLv2
  *
- * Copyright (c) 2005-2007 Joern Engel <joern@logfs.org>
+ * Copyright (c) 2005-2008 Joern Engel <joern@logfs.org>
  */
 #include "logfs.h"
 #include <linux/sched.h>
diff --git a/fs/logfs/gc.c b/fs/logfs/gc.c
index 0767345..ee1c448 100644
--- a/fs/logfs/gc.c
+++ b/fs/logfs/gc.c
@@ -3,7 +3,7 @@
  *
  * As should be obvious for Linux kernel code, license is GPLv2
  *
- * Copyright (c) 2005-2007 Joern Engel <joern@logfs.org>
+ * Copyright (c) 2005-2008 Joern Engel <joern@logfs.org>
  *
  * GC design as it should be (and isn't, as of 15.3.07):
  * 1. Pick a good candidate for GC, constrained by the number of currently
diff --git a/fs/logfs/inode.c b/fs/logfs/inode.c
index 0d2b9be..d8f7b66 100644
--- a/fs/logfs/inode.c
+++ b/fs/logfs/inode.c
@@ -3,7 +3,7 @@
  *
  * As should be obvious for Linux kernel code, license is GPLv2
  *
- * Copyright (c) 2005-2007 Joern Engel <joern@logfs.org>
+ * Copyright (c) 2005-2008 Joern Engel <joern@logfs.org>
  */
 #include "logfs.h"
 #include <linux/writeback.h>
@@ -539,12 +539,7 @@ struct inode *logfs_new_inode(struct inode *dir, int mode)
 	return inode;
 }
 
-#if LINUX_VERSION_CODE > KERNEL_VERSION(2, 6, 23)
 static void logfs_init_once(struct kmem_cache *cachep, void *_li)
-#else
-static void logfs_init_once(void *_li, struct kmem_cache *cachep,
-		unsigned long flags)
-#endif
 {
 	struct logfs_inode *li = _li;
 	int i;
diff --git a/fs/logfs/journal.c b/fs/logfs/journal.c
index a4cde56..cf07646 100644
--- a/fs/logfs/journal.c
+++ b/fs/logfs/journal.c
@@ -3,7 +3,7 @@
  *
  * As should be obvious for Linux kernel code, license is GPLv2
  *
- * Copyright (c) 2005-2007 Joern Engel <joern@logfs.org>
+ * Copyright (c) 2005-2008 Joern Engel <joern@logfs.org>
  */
 #include "logfs.h"
 
diff --git a/fs/logfs/logfs.h b/fs/logfs/logfs.h
index 471497f..48622b1 100644
--- a/fs/logfs/logfs.h
+++ b/fs/logfs/logfs.h
@@ -3,7 +3,7 @@
  *
  * As should be obvious for Linux kernel code, license is GPLv2
  *
- * Copyright (c) 2005-2007 Joern Engel <joern@logfs.org>
+ * Copyright (c) 2005-2008 Joern Engel <joern@logfs.org>
  *
  * Private header for logfs.
  */
@@ -552,3 +552,4 @@ static inline struct logfs_block *logfs_block(struct page *page)
 {
 	return (void *)page->private;
 }
+#endif /* FS_LOGFS_LOGFS_H */
diff --git a/fs/logfs/logfs_abi.h b/fs/logfs/logfs_abi.h
index 1cfd588..ae8548f 100644
--- a/fs/logfs/logfs_abi.h
+++ b/fs/logfs/logfs_abi.h
@@ -3,7 +3,7 @@
  *
  * As should be obvious for Linux kernel code, license is GPLv2
  *
- * Copyright (c) 2005-2007 Joern Engel <joern@logfs.org>
+ * Copyright (c) 2005-2008 Joern Engel <joern@logfs.org>
  *
  * Public header for logfs.
  */
diff --git a/fs/logfs/memtree.c b/fs/logfs/memtree.c
index 68fe7ce..604eea4 100644
--- a/fs/logfs/memtree.c
+++ b/fs/logfs/memtree.c
@@ -3,7 +3,7 @@
  *
  * As should be obvious for Linux kernel code, license is GPLv2
  *
- * Copyright (c) 2007 Joern Engel <joern@logfs.org>
+ * Copyright (c) 2007-2008 Joern Engel <joern@logfs.org>
  *
  *
  * This could possibly get moved to lib/.
diff --git a/fs/logfs/readwrite.c b/fs/logfs/readwrite.c
index ed1226f..b35c3dc 100644
--- a/fs/logfs/readwrite.c
+++ b/fs/logfs/readwrite.c
@@ -3,7 +3,7 @@
  *
  * As should be obvious for Linux kernel code, license is GPLv2
  *
- * Copyright (c) 2005-2007 Joern Engel <joern@logfs.org>
+ * Copyright (c) 2005-2008 Joern Engel <joern@logfs.org>
  *
  *
  * Actually contains five sets of very similar functions:
diff --git a/fs/logfs/segment.c b/fs/logfs/segment.c
index 13d4301..77defd2 100644
--- a/fs/logfs/segment.c
+++ b/fs/logfs/segment.c
@@ -3,7 +3,7 @@
  *
  * As should be obvious for Linux kernel code, license is GPLv2
  *
- * Copyright (c) 2005-2007 Joern Engel <joern@logfs.org>
+ * Copyright (c) 2005-2008 Joern Engel <joern@logfs.org>
  *
  * Object store or ostore makes up the complete device with exception of
  * the superblock and journal areas.  Apart from its own metadata it stores
diff --git a/fs/logfs/super.c b/fs/logfs/super.c
index 1f64494..d138a76 100644
--- a/fs/logfs/super.c
+++ b/fs/logfs/super.c
@@ -3,7 +3,7 @@
  *
  * As should be obvious for Linux kernel code, license is GPLv2
  *
- * Copyright (c) 2005-2007 Joern Engel <joern@logfs.org>
+ * Copyright (c) 2005-2008 Joern Engel <joern@logfs.org>
  *
  * Generally contains mount/umount code and also serves as a dump area for
  * any functions that don't fit elsewhere and neither justify a file of their

Re: LogFS merge

[Jörn Engel]

On Fri, 2 May 2008 18:52:21 +0200, Arnd Bergmann wrote:
> 
> There are still a few i's and t's left to dot and cross:
> 
> * the changeset comments needs a Signed-off-by: line

Doh!  When sending patches that happens automatically.  I should teach
git the same trick.

> * The MAINTAINERS file should list your name and logfs mailing list

Definitely.

> * you have a few instances of '#if LINUX_VERSION_CODE > 
>   KERNEL_VERSION(2, 6, 23)', that should go away for the merge

Yes.  I would like to keep the merge version roughly in sync with the
external patch, at least for a while.  Not sure how to deal with one
needing the multi-version hackery and the other not wanting it.

> * The copyright notice says 2005-2007, it should probably be 2005-2008

On most files, yes.

> * You may want to add a Documentation/filesystems/logfs.txt file explaining
>   the supported mount options.

Sure.  I don't have any logfs-specific ones yet, but even that fact
should be made explicit.

> * CONFIG_LOGFS should be tristate, not bool. Unfortunately, you are still
>   using three symbols that are not exported: swapper_space (through
>   BUG_ON(!page_mapping(page)->a_ops->set_page_dirty)), add_to_page_cache_lru
>  and inode_lock. Not sure what to do about this.

inode_lock will get fixed.  The BUG_ON could get removed.  Not sure
about add_to_page_cache_lru yet.

> * You should really make sure the version you check in compiles, 
>   fs/logfs/logfs.h is missing an #endif. ;-)

Making a merge dash whilst moving is not always the wisest choice. ;)

> Otherwise, I don't see any reasons why logfs shouldn't go in. The code is
> clean, feature-complete, and there is demand for it. The main question
> I can still see is the timing with the merge window. It's almost closed,
> so if logfs doesn't go in really soon, it should probably wait for the
> 2.6.27 window.

2.6.27 appears to make more sense, yes.

> This patch fixes some of the problems mentined above.

Excellent!  Thanks a bunch!

> +L:	logfs@logfs.org

I believe it is currently subscribers-only with the usual bounces
everyone holds so dear.  I should change that and add a spam filter to
make it bearable.

Jörn

-- 
The only real mistake is the one from which we learn nothing.
-- John Powell

Re: LogFS merge

[Linus Torvalds]

On Fri, 2 May 2008, Jörn Engel wrote:
> 
> not being familiar with either maintaining my own git tree or the -next
> process, I'd still like to get logfs into mainline.  It has gone through
> six rounds of reviews and the last has been mostly about crossing some
> i's here and dotting some t's there.

The thing I'd like to see is:

 - a more recent description of file system layout

   I've read the original paper, and I assume things have changed when 
   implementing stuff. They always do.

 - some benchmarks and/or comments about regular usage (ie fragmentation 
   etc). Yeah, it doesn't need to be all that extensive, but quite 
   frankly, it sounds like this is meant to be at least a partial 
   replacement for a GP filesystem (considering that seek/rotational 
   delay are going away) and people are working on it with USB memory 
   sticks etc, wouldn't it make sense to talk about disk usage (how much 
   the GC wants free etc) and everyday performance?

Hmm?

		Linus

Re: LogFS merge

[Jörn Engel]

On Fri, 2 May 2008 10:17:28 -0700, Linus Torvalds wrote:
> On Fri, 2 May 2008, Jörn Engel wrote:
> > 
> > not being familiar with either maintaining my own git tree or the -next
> > process, I'd still like to get logfs into mainline.  It has gone through
> > six rounds of reviews and the last has been mostly about crossing some
> > i's here and dotting some t's there.
> 
> The thing I'd like to see is:
> 
>  - a more recent description of file system layout
> 
>    I've read the original paper, and I assume things have changed when 
>    implementing stuff. They always do.

The big picture has largely stayed the same, but many details haven't.
Will do.

>  - some benchmarks and/or comments about regular usage (ie fragmentation 
>    etc). Yeah, it doesn't need to be all that extensive, but quite 
>    frankly, it sounds like this is meant to be at least a partial 
>    replacement for a GP filesystem (considering that seek/rotational 
>    delay are going away) and people are working on it with USB memory 
>    sticks etc, wouldn't it make sense to talk about disk usage (how much 
>    the GC wants free etc) and everyday performance?

Currently performance sucks badly on block device flashes (usb stick,
etc.) when creating/removing/renaming files.  The combination of logfs
and the built-in logic can result in 1-2MB of data written to create a
single empty file.  Yuck!

"Real" block devices or real flash suffer a lot less and writing large
amounts of data to existing files doesn't have this problem either.

Fragmentation is neither actively avoided nor actively enforced.  If the
workload writes files single-threaded, it will initially be fairly good.
Over time GC will stir the soup and fragmentation grows.  Several
parallel writers give a pretty bad result for seek-bound devices, even
initially.

GC wants 4095 + 28 bytes per segment (128KiB by default) to deal with
not-quite-100% filled segments plus one free segment per level (12 by
default, could become an mkfs option).  Add the journal and superblock
for about 2MiB minimum overhead.  Some embedded people with 32MiB
devices worry about that, although arguably they should still use jffs2
if minimal space overhead is a big issue.

I guess the above could go into Documentation/filesystems/logfs.txt.
And some more.

Jörn

-- 
Fancy algorithms are slow when n is small, and n is usually small.
Fancy algorithms have big constants. Until you know that n is
frequently going to be big, don't get fancy.
-- Rob Pike

Re: LogFS merge

[Linus Torvalds]

On Fri, 2 May 2008, Jörn Engel wrote:
> 
> Currently performance sucks badly on block device flashes (usb stick,
> etc.) when creating/removing/renaming files.  The combination of logfs
> and the built-in logic can result in 1-2MB of data written to create a
> single empty file.  Yuck!

Can you talk about why, and describe these kinds of things? Is it just 
because of deep directory trees and having to rebuild the tree from the 
root up, or is it something else going on?

> Fragmentation is neither actively avoided nor actively enforced.

I was more thinking about the fragmentation in terms of how much free 
space you need for reasonable performance behavior - these kinds of things 
tend to easily start behaving really badly when the disk fills up and you 
need to GC all the time just to make room for new erase blocks for the 
trivial inode mtime/atime updates etc.

Maybe logfs doesn't have that problem for some reason, but in many cases 
there are rules like "we will consider the filesystem full when it goes 
over 90% theoretical fill", and it's interesting to know.

> I guess the above could go into Documentation/filesystems/logfs.txt.
> And some more.

I did try looking at gitweb to see if I could find some documentation 
file. I didn't find anything.

		Linus

Re: LogFS merge

[Jörn Engel]

On Fri, 2 May 2008 13:33:12 -0700, Linus Torvalds wrote:
> On Fri, 2 May 2008, Jörn Engel wrote:
> > 
> > Currently performance sucks badly on block device flashes (usb stick,
> > etc.) when creating/removing/renaming files.  The combination of logfs
> > and the built-in logic can result in 1-2MB of data written to create a
> > single empty file.  Yuck!
> 
> Can you talk about why, and describe these kinds of things? Is it just 
> because of deep directory trees and having to rebuild the tree from the 
> root up, or is it something else going on?

Logfs has the concept of "levels".  Level 0 contains file data.  Level 1
has indirect blocks, level 2 doubly indirect blocks, etc.  Inodes are
stored in an inode file, which is on level 6 for the inodes, 7 for
indirect blocks, etc.

GC requires that data for each level is kept seperate from data for
other levels.  It is the only make deadlocks impossible, any alternative
will just reduce deadlock likelyhood afaiks.  Both regular files and the
inode file can currently go up to 3x indirect, so you have up to 8
levels open for writing at any given time.

Writing data synchronously requires wandering the entire tree, i.e.
writing a block on level 0, then one on level 1, 2 and 3 if indirect
blocks are required, write the inode at level 6 and again writing blocks
on levels 7, 8 and 9 if the inode number is high.  When creating a file,
both the dentry and the created inode are written synchronously.

So on a block device level, all this translates to several writes, none
of them being adjacent.  Each write is fairly small by itself.  But the
FTL inside your favorite type of consumer flash media will turn any
small write into a write of the complete eraseblock.  So somewhere on an
internal bus, megabytes of data are happily shuffled around.


I have a solution for this, but it would require an incompatible change
to the format.  And right now I have fairly good confidence in the
format wrt. ensuring correctness.  So the plan is to merge logfs as-is
(modulo bugfixes, review fallout, etc.) and handle the changes for this
and other performance problems with compat flags.  And someday rename
the whole mess to log2fs and remove some support for old format
variants.

> > Fragmentation is neither actively avoided nor actively enforced.
> 
> I was more thinking about the fragmentation in terms of how much free 
> space you need for reasonable performance behavior - these kinds of things 
> tend to easily start behaving really badly when the disk fills up and you 
> need to GC all the time just to make room for new erase blocks for the 
> trivial inode mtime/atime updates etc.
> 
> Maybe logfs doesn't have that problem for some reason, but in many cases 
> there are rules like "we will consider the filesystem full when it goes 
> over 90% theoretical fill", and it's interesting to know.

For any flash filesystem there is what I call the "evil workload".  Fill
the filesystem 100% and randomly replace data.  In the best case (jffs2)
the filesystem has to GC one segment worth of free space to write one
block, then GC another segment for the next block, etc.  Non-compressed
log-structured filesystems can cheat their way around that by avoiding
GC and doing hole-plugging instead.  Not sure if any actually do that.

Logfs tries hard to behave the same way on any medium - if only to
increase test coverage and fix bugs for everyone when possible.  And it
has to write indirect blocks, which makes the evil workload worse yet.
However, with just 1-2MiB free, it gets back to jffs2 behaviour or at
least close, as it can GC a couple of segments and collect dirty
indirect blocks, combining updates to those.

So in effect, the question is how fill the filesystem is and how random
the write pattern.  50% full and completely random means on average
logfs has to GC one segment to write one and performance is down to 50%.
90% full and completely random means GC 9 to write 1, so we're at 10%.
90% full, 85% of which remain untouched means 5% get written and 10% are
full, so on average GC 1 to write 2.

I cannot give you a hard limit, but the math is simple enough.

> I did try looking at gitweb to see if I could find some documentation 
> file. I didn't find anything.

Noone else has asked for one before, I believe.

Jörn

-- 
Joern's library part 3:
http://inst.eecs.berkeley.edu/~cs152/fa05/handouts/clark-test.pdf

Re: LogFS merge

[Linus Torvalds]

On Fri, 2 May 2008, Jörn Engel wrote:
>
> I have a solution for this, but it would require an incompatible change
> to the format.  And right now I have fairly good confidence in the
> format wrt. ensuring correctness.  So the plan is to merge logfs as-is
> (modulo bugfixes, review fallout, etc.) and handle the changes for this
> and other performance problems with compat flags.  And someday rename
> the whole mess to log2fs and remove some support for old format
> variants.

Quite frankly, if that's the case, I'd *much* rather see that worked on 
first, so that there aren't any format changes that are already known to 
be pending before it even gets merged.

Would it be at all possible to try to do that, or is it just "too far 
out"?

		Linus

Re: LogFS merge

[Jörn Engel]

On Fri, 2 May 2008 14:39:23 -0700, Linus Torvalds wrote:
> 
> Quite frankly, if that's the case, I'd *much* rather see that worked on 
> first, so that there aren't any format changes that are already known to 
> be pending before it even gets merged.
> 
> Would it be at all possible to try to do that, or is it just "too far 
> out"?

Definitely possible.  The last similar change happened in December and
took until March until I ran out of stupid regressions from it.  Most
likely there are still some I just haven't found yet.

The question is when to draw the line and say "This is useful as-is for
a sufficient number of users."  I don't have a good answer to it.  I
certainly expect more changes in the future, including format changes.
And if we wait for them all to happen, it won't get merged this decade.

Not sure.

Jörn

-- 
The only good bug is a dead bug.
-- Starship Troopers

Re: LogFS merge

[Willy Tarreau]

On Fri, May 02, 2008 at 11:58:33PM +0200, Jörn Engel wrote:
> On Fri, 2 May 2008 14:39:23 -0700, Linus Torvalds wrote:
> > 
> > Quite frankly, if that's the case, I'd *much* rather see that worked on 
> > first, so that there aren't any format changes that are already known to 
> > be pending before it even gets merged.
> > 
> > Would it be at all possible to try to do that, or is it just "too far 
> > out"?
> 
> Definitely possible.  The last similar change happened in December and
> took until March until I ran out of stupid regressions from it.  Most
> likely there are still some I just haven't found yet.
> 
> The question is when to draw the line and say "This is useful as-is for
> a sufficient number of users."  I don't have a good answer to it.  I
> certainly expect more changes in the future, including format changes.
> And if we wait for them all to happen, it won't get merged this decade.

Why not merge it and mark it experimental then ? In fact, this is about
what you're looking for : reduced merge hassle and more testers.

Willy

Re: LogFS merge

[Adrian Bunk]

On Sat, May 03, 2008 at 09:03:18AM +0200, Willy Tarreau wrote:
> On Fri, May 02, 2008 at 11:58:33PM +0200, Jörn Engel wrote:
> > On Fri, 2 May 2008 14:39:23 -0700, Linus Torvalds wrote:
> > > 
> > > Quite frankly, if that's the case, I'd *much* rather see that worked on 
> > > first, so that there aren't any format changes that are already known to 
> > > be pending before it even gets merged.
> > > 
> > > Would it be at all possible to try to do that, or is it just "too far 
> > > out"?
> > 
> > Definitely possible.  The last similar change happened in December and
> > took until March until I ran out of stupid regressions from it.  Most
> > likely there are still some I just haven't found yet.
> > 
> > The question is when to draw the line and say "This is useful as-is for
> > a sufficient number of users."  I don't have a good answer to it.  I
> > certainly expect more changes in the future, including format changes.
> > And if we wait for them all to happen, it won't get merged this decade.
> 
> Why not merge it and mark it experimental then ? In fact, this is about
> what you're looking for : reduced merge hassle and more testers.

Andi already answered that one:
"Merging file systems too early can quickly ruin their name and that 
 taint is hard to ever get rid again then (e.g. happened to JFS)"


And a stable kernel shouldn't be something for getting "more testers", 
it should be for tested code ready to be used in production.
What you call "more testers" would be people who try it in production
(e.g. to overcome shortcomings of JFFS2) thinking it was stable.

And no, EXPERIMENTAL in the kernel is not usable for keeping people from 
trying known-whacky code.


> Willy


cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: LogFS merge

[Willy Tarreau]

On Sat, May 03, 2008 at 12:11:11PM +0300, Adrian Bunk wrote:
> On Sat, May 03, 2008 at 09:03:18AM +0200, Willy Tarreau wrote:
> > On Fri, May 02, 2008 at 11:58:33PM +0200, Jörn Engel wrote:
> > > On Fri, 2 May 2008 14:39:23 -0700, Linus Torvalds wrote:
> > > > 
> > > > Quite frankly, if that's the case, I'd *much* rather see that worked on 
> > > > first, so that there aren't any format changes that are already known to 
> > > > be pending before it even gets merged.
> > > > 
> > > > Would it be at all possible to try to do that, or is it just "too far 
> > > > out"?
> > > 
> > > Definitely possible.  The last similar change happened in December and
> > > took until March until I ran out of stupid regressions from it.  Most
> > > likely there are still some I just haven't found yet.
> > > 
> > > The question is when to draw the line and say "This is useful as-is for
> > > a sufficient number of users."  I don't have a good answer to it.  I
> > > certainly expect more changes in the future, including format changes.
> > > And if we wait for them all to happen, it won't get merged this decade.
> > 
> > Why not merge it and mark it experimental then ? In fact, this is about
> > what you're looking for : reduced merge hassle and more testers.
> 
> Andi already answered that one:
> "Merging file systems too early can quickly ruin their name and that 
>  taint is hard to ever get rid again then (e.g. happened to JFS)"
> 
> 
> And a stable kernel shouldn't be something for getting "more testers", 
> it should be for tested code ready to be used in production.

OK, -mm is generally more suited for this usage then.

> What you call "more testers" would be people who try it in production
> (e.g. to overcome shortcomings of JFFS2) thinking it was stable.

No, it is just to gain more exposure by easing tester's job. People
packaging distros for embedded systems do a lot of R&D, and having
new features to experiment with is very important to them. And no,
that does not mean they'll immediately use it in production. And
even if some did, they would know why they did it and it's their
problem.

Willy

Re: LogFS merge

[Adrian Bunk]

On Sat, May 03, 2008 at 11:18:13AM +0200, Willy Tarreau wrote:
> On Sat, May 03, 2008 at 12:11:11PM +0300, Adrian Bunk wrote:
>...
> > What you call "more testers" would be people who try it in production
> > (e.g. to overcome shortcomings of JFFS2) thinking it was stable.
> 
> No, it is just to gain more exposure by easing tester's job. People
> packaging distros for embedded systems do a lot of R&D, and having
> new features to experiment with is very important to them. And no,
> that does not mean they'll immediately use it in production.

If it's in the kernel it will end in distribution kernels.

And people will then use it.

You might be right, they might not immediately use it in production. 
They might use the current version one year later in the then one year 
old kernel they will then be using. Or the one year old version plus 
some random set of vendor patches.

> And
> even if some did, they would know why they did it and it's their
> problem.

You want to put experimental code into stable kernels and then blame 
people using it that they shouldn't have used it?

> Willy

cu
Adrian

BTW: This is not meant against the LogFS merge.

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: LogFS merge

[Pekka Enberg]

Hi Adrian,

On Sat, May 3, 2008 at 12:11 PM, Adrian Bunk <bunk@kernel.org> wrote:
> > Why not merge it and mark it experimental then ? In fact, this is about
> > what you're looking for : reduced merge hassle and more testers.
>
>  Andi already answered that one:
>
> "Merging file systems too early can quickly ruin their name and that
>   taint is hard to ever get rid again then (e.g. happened to JFS)"
>
>  And a stable kernel shouldn't be something for getting "more testers",
>  it should be for tested code ready to be used in production.
>  What you call "more testers" would be people who try it in production
>  (e.g. to overcome shortcomings of JFFS2) thinking it was stable.
>
>  And no, EXPERIMENTAL in the kernel is not usable for keeping people from
>  trying known-whacky code.

I think ext4 already set the precedent that you _can_ do development
within the 2.6 series, no?

Re: LogFS merge

[Adrian Bunk]

On Sat, May 03, 2008 at 12:44:12PM +0300, Pekka Enberg wrote:
> Hi Adrian,
> 
> On Sat, May 3, 2008 at 12:11 PM, Adrian Bunk <bunk@kernel.org> wrote:
> > > Why not merge it and mark it experimental then ? In fact, this is about
> > > what you're looking for : reduced merge hassle and more testers.
> >
> >  Andi already answered that one:
> >
> > "Merging file systems too early can quickly ruin their name and that
> >   taint is hard to ever get rid again then (e.g. happened to JFS)"
> >
> >  And a stable kernel shouldn't be something for getting "more testers",
> >  it should be for tested code ready to be used in production.
> >  What you call "more testers" would be people who try it in production
> >  (e.g. to overcome shortcomings of JFFS2) thinking it was stable.
> >
> >  And no, EXPERIMENTAL in the kernel is not usable for keeping people from
> >  trying known-whacky code.
> 
> I think ext4 already set the precedent that you _can_ do development
> within the 2.6 series, no?

I'd call the ext4 case a mistake we shouldn't repeat.

It's available in the kernel since 2006.

I've seen people using ext4 on their computers running with a corrupted 
filesystem since fsck was at that point not yet capable of fixing 
whatever was corrupted.

At least one distribution already has ext4 enabled in their kernels.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: LogFS merge

[Linus Torvalds]

On Sat, 3 May 2008, Willy Tarreau wrote:
> 
> Why not merge it and mark it experimental then ? In fact, this is about
> what you're looking for : reduced merge hassle and more testers.

The real issue for me wrt a filesystem is the on-disk layout.

If we know that on-disk structures need change, we shouldn't merge it. It 
doesn't matter if that can be worked around with some backwards- 
compatibiltiy flag: we should simply not encourage that kind of behaviour. 
It would be much much better to just get a layout that is as final as 
possible and avoid the "there are two different formats, because the first 
format was known to be broken" issue.

Will extensions happen and add features anyway? Probably. But that's 
different from merging something knowing that the on-disk format will 
change.

		Linus

Offtopic to: LogFS merge

[David Collier-Brown]

Linus Torvalds wrote:
> The real issue for me wrt a filesystem is the on-disk layout.
> 
> If we know that on-disk structures need change, we shouldn't merge it. It 
> doesn't matter if that can be worked around with some backwards- 
> compatibiltiy flag: we should simply not encourage that kind of behaviour.

  I agree in particular, but not in principle (;-))

  Changing the filesystem format was something that happened at
least twice on Multics, on production machines. I happened to be
on during one of the changes and didn't even know it was happening
until there was a broadcast message warning of poor performance.

  I always thought that was cool, and got permission recently to
post a colleague's paper on it at http://www.multicians.org/stachour.html

  It would be cool if data could change at run-time on Linux, just
like security-sensitive code.

--dave
-- 
David Collier-Brown            | Always do right. This will gratify
Sun Microsystems, Toronto      | some people and astonish the rest
davecb@sun.com                 |                      -- Mark Twain
(905) 943-1983, cell: (647) 833-9377, (800) 555-9786 x56583
bridge: (877) 385-4099 code: 506 9191#

Re: LogFS merge

[Andi Kleen]

Jörn Engel <joern@logfs.org> writes:
>
> So should it simmer in -next and -mm for another month?  Should it go
> straight into -linus?

The main criteria for it going to Linus should be if you would really
trust your data to it now. Would you put your $HOME on it? Merging file 
systems too early can quickly ruin their name and that taint is hard
to ever get rid again then (e.g. happened to JFS) 

-Andi

Re: LogFS merge

[Jörn Engel]

On Fri, 2 May 2008 19:29:07 +0200, Andi Kleen wrote:
> Jörn Engel <joern@logfs.org> writes:
> >
> > So should it simmer in -next and -mm for another month?  Should it go
> > straight into -linus?
> 
> The main criteria for it going to Linus should be if you would really
> trust your data to it now. Would you put your $HOME on it? Merging file 
> systems too early can quickly ruin their name and that taint is hard
> to ever get rid again then (e.g. happened to JFS) 

Right now I don't, mainly because file creat performance is still too
bad on the devices I can buy and attach to my notebook.  But something
like bittorrent would be an excellent testbed where few large files are
created and performance should actually be good enough.  Time to eat my
dogfood.

Jörn

-- 
All art is but imitation of nature.
-- Lucius Annaeus Seneca

Re: LogFS merge

[Andrew Morton]

On Fri, 2 May 2008 15:32:34 +0200
J__rn Engel <joern@logfs.org> wrote:

> master.kernel.org:/pub/scm/linux/kernel/git/joern/logfs.git/

I added this to the -mm pile.

Thank you for not putting your Makefile and Kconfig changes right at the
end of the file like everyone else always does.  It actually merges.

Re: LogFS merge

[matthieu castet]

Hi,

On Fri, May 2, 2008 at 4:32 PM, Jörn Engel <joern@logfs.org> wrote:
 >  not being familiar with either maintaining my own git tree or the -next
 >  process, I'd still like to get logfs into mainline.  It has gone through
 >  six rounds of reviews and the last has been mostly about crossing some
 >  i's here and dotting some t's there.
 >
 >  So should it simmer in -next and -mm for another month?  Should it go
 >  straight into -linus?
Shouldn't this get review by mtd guys first ?

Also for info, there have been some issue raised by the ubifs developer [1].

Matthieu

[1] http://thread.gmane.org/gmane.linux.kernel/658740/focus=660392

Re: LogFS merge

[Jörn Engel]

On Sat, 3 May 2008 11:29:43 +0200, matthieu castet wrote:
>
> Shouldn't this get review by mtd guys first ?

They were on Cc: on most of the review rounds.

> Also for info, there have been some issue raised by the ubifs developer [1].

I am aware of them.  When ignoring FUD and personal things (Artem and I
have a history), it should come down to roughly this:

1.
Ubifs takes the easy approach and uses ubi for wear leveling, bad block
handling, ets.  Saves a ton of work, gives quick results and is limited
by ubi scan time, which is O(n).

Logfs ignores ubi and does wear leveling, bad block handling, etc.
itself.  Bad block handling in particular is not too robust yet.  If you
expect blocks to rot away after mkfs time, logfs is a bad choice.

2.
Logfs still scans the medium.  It currently does not store free space
maps and has to search for free space the hard way.  I still have a
patch to keep the map in-memory, which will avoid any rescans.  But the
real deal is to store it in a file with some additional tricks to make
things work in a log-structured fashion.  Not done yet.

Ubifs has a seperate region to store its free space map, which has its
own GC.  Wear leveling is dealt with through ubi.  Again, ubi makes life
easier.

3. Code size.

4. Mount time.  I don't see any numbers I could quote, but I believe
ubifs is somewhere close to a second.  Does anyone know?  Logfs is in
the 10-60ms range.

5.
Ubifs has write-back caching for file data.  Their benchmarks blow jffs2
or logfs out of the water, which isn't surprising when comparing DRAM to
flash.

Logfs has write-back caching for metadata (indirect blocks, etc.) but
immediatly writes normal data.  Some embedded folks actually prefer this
approach, as it is more deterministic.  For most uses it simply throws
away some performance.  Extending caching to normal data isn't too hard
and fairly high on my list.

6.
"Logfs isn't finished yet."
My usual answer to that is that Linux isn't finished yet either.  We're
still improving performance, adding hardware support and fixing bugs
some 15 years after people started using it.  The question is not
whether there are improvements left, but whether it is good enough
already.

Jörn

-- 
I've never met a human being who would want to read 17,000 pages of
documentation, and if there was, I'd kill him to get him out of the
gene pool.
-- Joseph Costello

Re: LogFS merge

[Thomas Gleixner]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 708 bytes --]

On Sat, 3 May 2008, Jörn Engel wrote:
> 1.
> Ubifs takes the easy approach and uses ubi for wear leveling, bad block
> handling, ets.  Saves a ton of work, gives quick results and is limited
> by ubi scan time, which is O(n).

Which is easy enough to fix.

> Logfs ignores ubi and does wear leveling, bad block handling, etc.
> itself.  Bad block handling in particular is not too robust yet.  If you
> expect blocks to rot away after mkfs time, logfs is a bad choice.

It's a matter of fact that especially on NAND flash blocks become bad
over time, i.e. after mkfs. So that's a pretty crucial feature which
needs to be complete and robust before it's declared to be usable on
such devices.

Thanks,
	tglx

Re: LogFS merge

[Josh Boyer]

On Sun, 4 May 2008 18:20:23 +0200 (CEST)
Thomas Gleixner <tglx@linutronix.de> wrote:

> > Logfs ignores ubi and does wear leveling, bad block handling, etc.
> > itself.  Bad block handling in particular is not too robust yet.  If you
> > expect blocks to rot away after mkfs time, logfs is a bad choice.
> 
> It's a matter of fact that especially on NAND flash blocks become bad
> over time, i.e. after mkfs. So that's a pretty crucial feature which
> needs to be complete and robust before it's declared to be usable on
> such devices.

I agree.  LogFS seems quite impressive in its performance, however I'm
wondering how much redesign and rewrite would be needed in the code to
fix the bad block handling.  Maybe it's not so much and I'm overly
paranoid, but having at least some idea of what it would take might
help.  You could add it to Documentation/filesystems/LogFS.txt as a
TODO.

josh