Re: [Patch 02/18] include/linux/logfs.h

2007-08-09 Thread Jörn Engel
On Thu, 9 August 2007 00:56:29 +0200, Arnd Bergmann wrote:
 On Wednesday 08 August 2007, Jörn Engel wrote:
  +++ linux-2.6.21logfs/include/linux/logfs.h 2007-08-08 
  02:57:37.0 +0200
  @@ -0,0 +1,500 @@
  +/*
  + * fs/logfs/logfs.h
  + *
 
 The comment does not match the file name. Better remove the file names
 entirely from introduction comments.

Maybe.  This file needs to get moved again anyway.

Jörn

-- 
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it.
-- Brian W. Kernighan
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Patch 02/18] include/linux/logfs.h

2007-08-08 Thread Jörn Engel
--- /dev/null   2007-08-05 21:14:35.622844160 +0200
+++ linux-2.6.21logfs/include/linux/logfs.h 2007-08-08 02:57:37.0 
+0200
@@ -0,0 +1,500 @@
+/*
+ * fs/logfs/logfs.h
+ *
+ * As should be obvious for Linux kernel code, license is GPLv2
+ *
+ * Copyright (c) 2005-2007 Joern Engel [EMAIL PROTECTED]
+ *
+ * Public header for logfs.
+ */
+#ifndef linux_logfs_h
+#define linux_logfs_h
+
+
+/*
+ * Throughout the logfs code, we're constantly dealing with blocks at
+ * various positions or offsets.  To remove confusion, we stricly
+ * distinguish between a position - the logical position within a
+ * file and an offset - the physical location within the device.
+ *
+ * Any usage of the term offset for a logical location or position for
+ * a physical one is a bug and should get fixed.
+ */
+
+/*
+ * Block are allocated in one of several segments depending on their
+ * level.  The following levels are used:
+ *  0  - regular data block
+ *  1  - i1 indirect blocks
+ *  2  - i2 indirect blocks
+ *  3  - i3 indirect blocks
+ *  4  - i4 indirect blocks
+ *  5  - i5 indirect blocks
+ *  6  - ifile data blocks
+ *  7  - ifile i1 indirect blocks
+ *  8  - ifile i2 indirect blocks
+ *  9  - ifile i3 indirect blocks
+ * 10  - ifile i4 indirect blocks
+ * 11  - ifile i5 indirect blocks
+ * Potential levels to be used in the future:
+ * 12  - gc recycled blocks, long-lived data
+ * 13  - replacement blocks, short-lived data
+ *
+ * Levels 1-11 are necessary for robust gc operations and help seperate
+ * short-lived metadata from longer-lived file data.  In the future,
+ * file data should get seperated into several segments based on simple
+ * heuristics.  Old data recycled during gc operation is expected to be
+ * long-lived.  New data is of uncertain life expectancy.  New data
+ * used to replace older blocks in existing files is expected to be
+ * short-lived.
+ */
+
+
+/* Magic numbers.  64bit for superblock, 32bit for statfs f_type */
+#define LOGFS_MAGIC0xb21f205ac97e8168ull
+#define LOGFS_MAGIC_U320xc97e8168u
+
+/*
+ * Various blocksize related macros.  Blocksize is currently fixed at 4KiB.
+ * Sooner or later that should become configurable and the macros replaced
+ * by something superblock-dependent.  Pointers in indirect blocks are and
+ * will remain 64bit.
+ *
+ * LOGFS_BLOCKSIZE - self-explaining
+ * LOGFS_BLOCK_FACTOR  - number of pointers per indirect block
+ * LOGFS_BLOCK_BITS- log2 of LOGFS_BLOCK_FACTOR, used for shifts
+ */
+#define LOGFS_BLOCKSIZE(4096ull)
+#define LOGFS_BLOCK_FACTOR (LOGFS_BLOCKSIZE / sizeof(u64))
+#define LOGFS_BLOCK_BITS   (9)
+
+/*
+ * Number of blocks at various levels of indirection.  Each inode originally
+ * had 9 block pointers.  Later the inode size was doubled and there are now
+ * 9+16 pointers - the notation is just historical.
+ *
+ * I0_BLOCKS is the number of direct block pointer in each inode.  The
+ * remaining five pointers are for indirect pointers, up to 5x indirect.
+ * Only 3x is tested and supported at the moment.  5x would allow for truly
+ * humongous files if the need ever arises.
+ * I1_BLOCKS is the number of blocks behind a 1x indirect block,
+ * I2_BLOCKS is the number of blocks behind a 2x indirect block, not counting
+ * the 1x indirect blocks.  etc.
+ */
+#define I0_BLOCKS  (4+16)
+#define I1_BLOCKS  LOGFS_BLOCK_FACTOR
+#define I2_BLOCKS  (LOGFS_BLOCK_FACTOR * I1_BLOCKS)
+#define I3_BLOCKS  (LOGFS_BLOCK_FACTOR * I2_BLOCKS)
+#define I4_BLOCKS  (LOGFS_BLOCK_FACTOR * I3_BLOCKS)
+#define I5_BLOCKS  (LOGFS_BLOCK_FACTOR * I4_BLOCKS)
+
+/* The indices in the block array where the Nx indirect block pointers reside 
*/
+#define I1_INDEX   (4+16)
+#define I2_INDEX   (5+16)
+#define I3_INDEX   (6+16)
+#define I4_INDEX   (7+16)
+#define I5_INDEX   (8+16)
+
+/* The total number of block pointers in each inode */
+#define LOGFS_EMBEDDED_FIELDS  (9+16)
+
+/*
+ * Sizes at which files require another level of indirection.  Files smaller
+ * than LOGFS_EMBEDDED_SIZE can be completely stored in the inode itself,
+ * similar like ext2 fast symlinks.
+ *
+ * Data at a position smaller than LOGFS_I0_SIZE is accessed through the
+ * direct pointers, else through the 1x indirect pointer and so forth.
+ */
+#define LOGFS_EMBEDDED_SIZE(LOGFS_EMBEDDED_FIELDS * sizeof(u64))
+#define LOGFS_I0_SIZE  (I0_BLOCKS * LOGFS_BLOCKSIZE)
+#define LOGFS_I1_SIZE  (I1_BLOCKS * LOGFS_BLOCKSIZE)
+#define LOGFS_I2_SIZE  (I2_BLOCKS * LOGFS_BLOCKSIZE)
+#define LOGFS_I3_SIZE  (I3_BLOCKS * LOGFS_BLOCKSIZE)
+#define LOGFS_I4_SIZE  (I4_BLOCKS * LOGFS_BLOCKSIZE)
+#define LOGFS_I5_SIZE  (I5_BLOCKS * LOGFS_BLOCKSIZE)
+
+/*
+ * LogFS needs to seperate data into levels.  Each level is defined as the
+ * maximal possible distance from the master inode (inode 

Re: [Patch 02/18] include/linux/logfs.h

2007-08-08 Thread Arnd Bergmann
On Wednesday 08 August 2007, Jörn Engel wrote:
 +++ linux-2.6.21logfs/include/linux/logfs.h 2007-08-08 02:57:37.0 
 +0200
 @@ -0,0 +1,500 @@
 +/*
 + * fs/logfs/logfs.h
 + *

The comment does not match the file name. Better remove the file names
entirely from introduction comments.

Arnd 
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html