On Tue, 26 February 2008 20:16:11 +1100, Nick Piggin wrote:
Yeah, sync_file_range has slightly unusual semantics and introduce
the new concept, writeout, to userspace (does writeout include
in drive cache? the kernel doesn't think so, but the only way to
make sync_file_range safe is if you
On Tue, 26 February 2008 15:28:10 +, Jamie Lokier wrote:
One interesting aspect of this comes with COW filesystems like btrfs or
logfs. Writing out data pages is not sufficient, because those will get
lost unless their referencing metadata is written as well. So either we
have to
On Tue, 26 February 2008 17:29:13 +, Jamie Lokier wrote:
You're right. Though, doesn't normal page writeback enqueue the COW
metadata changes? If not, how do they get written in a timely
fashion?
It does. But this is not sufficient to guarantee that the pages in
question have been
On Thu, 6 December 2007 17:27:26 +0100, Andi Drebes wrote:
[...]
static inline u32 cramfs_offset(struct cramfs_inode *inode)
{
return le32_to_cpu(node-namelen_offset)
CRAMFS_NAMELEN_WIDTH;
}
This requires changing the on-disk-structure (even the current little
On Wed, 5 December 2007 14:21:02 -0800, Linus Torvalds wrote:
No, no, what I meant about not having any #ifdef __LITTLE_ENDIAN was to do
the code do the same thing *regardless* of endianness. In other words, a
simple:
struct cramfs_inode {
__le32 mode_uid;/*
On Tue, 4 December 2007 13:01:26 +0100, Andi Drebes wrote:
+#ifdef __BIG_ENDIAN
+/* Converts a cramfs_info from little endian to big endian. */
+static inline void cramfs_convert_info_letobe(struct cramfs_info* info)
+{
+ info-crc = swab32(info-crc);
+ info-edition =
On Wed, 28 November 2007 16:39:59 -0700, Andreas Dilger wrote:
On Nov 28, 2007 14:56 -0800, Nicholas Miell wrote:
type: one of EXTENT_TYPE_HOLE, EXTENT_TYPE_DATA, EXTENT_TYPE_EXTENTS,
EXTENT_TYPE_COMPRESSED, EXTENT_TYPE_UNCOMPRESSED etc.
This is what FIEMAP is supposed to do. We wrote
On Wed, 28 November 2007 16:06:25 -0800, Nicholas Miell wrote:
I'd have to reread the original proposal, but I remember FIEMAP as being
a generalized way of getting information about a files extents. I think
the original proposal only dealt with mapping file offsets to physical
extents, but
On Wed, 28 November 2007 20:27:11 -0700, Andreas Dilger wrote:
On Nov 29, 2007 00:48 +0100, Jörn Engel wrote:
I didn't follow the discussion much, since it didn't appear to suit
logfs too well. In a nutshell, logfs is purely block-based, prepends
every block with a header, may compress
On Wed, 14 November 2007 13:56:53 +, David Howells wrote:
Are we ever going to have PAGE_CACHE_SIZE != PAGE_SIZE? If not, why not
discard PAGE_CACHE_SIZE as it's then redundant.
I did some digging. The code was merged between 28.4.1999 and
11.5.1999, as it first appears in 2.2.8 and
On Thu, 15 November 2007 21:35:16 +0100, Andi Drebes wrote:
+ /* Caching is disabled if the filesystem's
+and the machine's endianness differ. */
+ if(likely(CRAMFS_SB(sb)-endian))
+ {
Codingstyle: extra space after if, keep brace on the same line.
Same goes for most of
On Thu, 15 November 2007 18:59:19 -0800, Andrew Morton wrote:
On Fri, 16 Nov 2007 11:47:27 +0900 Hisashi Hifumi [EMAIL PROTECTED] wrote:
Currently fdatasync is identical to fsync in ext3,4.
I think fdatasync should skip journal flush in data=ordered and
data=writeback mode
because this
.
This is wrong. If I_DIRTY_DATASYNC is set, the inode needs to be
written even for datasync.
How about the patch below?
Jörn
--
Audacity augments courage; hesitation, fear.
-- Publilius Syrus
Signed-off-by: Jörn Engel [EMAIL PROTECTED]
---
fs/ext3/fsync.c |3 ++-
fs/ext4/fsync.c |3 ++-
2 files
On Tue, 6 November 2007 10:11:49 +0100, Jan Blunck wrote:
On Mon, Nov 05, Jörn Engel wrote:
This patch changes some 400 lines, most if not all of which get longer
and more complicated to read. 23 get sufficiently longer to require an
additional linebreak. I can't remember complexity
On Tue, 6 November 2007 13:59:03 +0100, Jan Blunck wrote:
Coming back to the mental stuff: the savings of the first bunch of patches
that already hit -mm:
Textsize without patches: 0x20e572
Textsize with patches:0x20e042
--
On Mon, 5 November 2007 13:01:25 -0800, [EMAIL PROTECTED] wrote:
The patch titled
Embed a struct path into struct nameidata instead of nd-{dentry,mnt}
has been added to the -mm tree. Its filename is
embed-a-struct-path-into-struct-nameidata-instead-of-nd-dentrymnt.patch
***
On Tue, 30 October 2007 18:35:08 +0900, Dongjun Shin wrote:
On 10/30/07, Greg Banks [EMAIL PROTECTED] wrote:
BIO_HINT_RELEASE
The bio's block extent is no longer in use by the filesystem
and will not be read in the future. Any storage used to back
the extent may be released
On Tue, 30 October 2007 23:19:48 +0900, Dongjun Shin wrote:
On 10/30/07, Arnd Bergmann [EMAIL PROTECTED] wrote:
Not sure. Why shouldn't you be able to reorder the hints provided that
they don't overlap with read/write bios for the same block?
You're right. The bios can be reordered if
On Tue, 18 September 2007 11:00:40 +0100, Mel Gorman wrote:
We still lack data on what sort of workloads really benefit from large
blocks
Compressing filesystems like jffs2 and logfs gain better compression
ratio with larger blocks. Going from 4KiB to 64KiB gave somewhere
around 10% benefit
On Sun, 16 September 2007 00:30:32 +0200, Andrea Arcangeli wrote:
Movable? I rather assume all slab allocations aren't movable. Then
slab defrag can try to tackle on users like dcache and inodes. Keep in
mind that with the exception of updatedb, those inodes/dentries will
be pinned and you
On Sat, 15 September 2007 01:44:49 -0700, Andrew Morton wrote:
On Tue, 11 Sep 2007 14:12:26 +0200 Jörn Engel [EMAIL PROTECTED] wrote:
While I agree with your concern, those numbers are quite silly. The
chances of 99.8% of pages being free and the remaining 0.2% being
perfectly spread
On Sun, 16 September 2007 11:15:36 -0700, Linus Torvalds wrote:
On Sun, 16 Sep 2007, Jörn Engel wrote:
I have been toying with the idea of having seperate caches for pinned
and movable dentries. Downside of such a patch would be the number of
memcpy() operations when moving dentries
On Mon, 17 September 2007 00:06:24 +0200, Goswin von Brederlow wrote:
How probable is it that the dentry is needed again? If you copy it and
it is not needed then you wasted time. If you throw it out and it is
needed then you wasted time too. Depending on the probability one of
the two is
On Tue, 11 September 2007 04:52:19 +1000, Nick Piggin wrote:
On Tuesday 11 September 2007 16:03, Christoph Lameter wrote:
5. VM scalability
Large block sizes mean less state keeping for the information being
transferred. For a 1TB file one needs to handle 256 million page
On Tue, 11 September 2007 13:07:06 -0700, Christoph Lameter wrote:
You may want to consider Mel's antifrag approaches which certainly
decreases the chance of this occurring. Reclaim can open up the needed
linear memory hole in a intentional way. The memory compaction approach
can even
On Fri, 31 August 2007 18:41:07 -0700, Christoph Lameter wrote:
The trouble with this patchset is that it is difficult to validate.
Activities are only performed when special load situations are encountered.
Are there any tests that could give meaningful information about
the effectiveness
On Fri, 31 August 2007 08:22:45 -0700, Christoph Lameter wrote:
What do you mean by moving things around? Creation binds a filesystem to a
device.
Create the filesystem on a usb key, then move it to the next machine,
i suppose.
Or on any other movable medium, including disks, nbd, iSCSI,...
On Tue, 28 August 2007 12:05:58 -0700, [EMAIL PROTECTED] wrote:
- index = *ppos PAGE_CACHE_SHIFT;
- offset = *ppos ~PAGE_CACHE_MASK;
+ index = page_cache_index(mapping, *ppos);
+ offset = page_cache_offset(mapping, *ppos);
Part of me feels inclined to marge this patch now
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
.
In principle it is possible to achieve better performance with a flash
filesystem than with the current emulated approach. In practice our
current flash filesystems are not even near that theoretical goal.
LogFS in its current state is already closer.
Signed-off-by: Jörn Engel [EMAIL PROTECTED]
fs/Kconfig
--- /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
--- /dev/null 2007-08-05 21:14:35.622844160 +0200
+++ linux-2.6.21logfs/fs/logfs/logfs.h 2007-08-08 03:02:00.0 +0200
@@ -0,0 +1,445 @@
+/*
+ * fs/logfs/logfs.h
+ *
+ * As should be obvious for Linux kernel code, license is GPLv2
+ *
+ * Copyright (c) 2005-2007 Joern Engel [EMAIL
--- /dev/null 2007-08-05 21:14:35.622844160 +0200
+++ linux-2.6.21logfs/fs/logfs/compr.c 2007-08-08 02:57:37.0 +0200
@@ -0,0 +1,95 @@
+/*
+ * fs/logfs/compr.c- compression routines
+ *
+ * As should be obvious for Linux kernel code, license is GPLv2
+ *
+ * Copyright (c) 2005-2007
--- /dev/null 2007-08-05 21:14:35.622844160 +0200
+++ linux-2.6.21logfs/fs/logfs/dir.c2007-08-08 02:57:37.0 +0200
@@ -0,0 +1,761 @@
+/*
+ * fs/logfs/dir.c - directory-related code
+ *
+ * As should be obvious for Linux kernel code, license is GPLv2
+ *
+ * Copyright (c)
--- /dev/null 2007-08-05 21:14:35.622844160 +0200
+++ linux-2.6.21logfs/fs/logfs/gc.c 2007-08-08 02:57:37.0 +0200
@@ -0,0 +1,404 @@
+/*
+ * fs/logfs/gc.c - garbage collection code
+ *
+ * As should be obvious for Linux kernel code, license is GPLv2
+ *
+ * Copyright (c)
--- /dev/null 2007-08-05 21:14:35.622844160 +0200
+++ linux-2.6.21logfs/fs/logfs/inode.c 2007-08-08 02:57:37.0 +0200
@@ -0,0 +1,514 @@
+/*
+ * fs/logfs/inode.c- inode handling code
+ *
+ * As should be obvious for Linux kernel code, license is GPLv2
+ *
+ * Copyright (c) 2005-2007
--- /dev/null 2007-08-05 21:14:35.622844160 +0200
+++ linux-2.6.21logfs/fs/logfs/journal.c2007-08-08 02:57:37.0
+0200
@@ -0,0 +1,737 @@
+/*
+ * fs/logfs/journal.c - journal handling code
+ *
+ * As should be obvious for Linux kernel code, license is GPLv2
+ *
+ * Copyright (c)
--- /dev/null 2007-08-05 21:14:35.622844160 +0200
+++ linux-2.6.21logfs/fs/logfs/readwrite.c 2007-08-08 03:05:29.0
+0200
@@ -0,0 +1,1185 @@
+/*
+ * fs/logfs/readwrite.c
+ *
+ * As should be obvious for Linux kernel code, license is GPLv2
+ *
+ * Copyright (c) 2005-2007 Joern Engel
--- /dev/null 2007-08-05 21:14:35.622844160 +0200
+++ linux-2.6.21logfs/fs/logfs/segment.c2007-08-08 03:09:41.0
+0200
@@ -0,0 +1,602 @@
+/*
+ * fs/logfs/segment.c - Handling the Object Store
+ *
+ * As should be obvious for Linux kernel code, license is GPLv2
+ *
+ * Copyright
--- /dev/null 2007-08-05 21:14:35.622844160 +0200
+++ linux-2.6.21logfs/fs/logfs/Locking 2007-08-08 02:57:37.0 +0200
@@ -0,0 +1,48 @@
+Locks:
+
+s_victim_mutex
+Protects victim inode for create, unlink, mkdir, rmdir, mknod, link,
+symlink and one variant of rename. Only one victim
--- linux-2.6.21logfs/fs/Kconfig~logfs 2007-08-08 02:57:37.0 +0200
+++ linux-2.6.21logfs/fs/Kconfig2007-08-08 02:57:37.0 +0200
@@ -1351,6 +1351,32 @@ config JFFS2_CMODE_SIZE
endchoice
+config LOGFS
+ bool Log Filesystem (EXPERIMENTAL)
+ depends on MTD
--- linux-2.6.21logfs/include/linux/Kbuild~logfs2007-08-08
02:57:37.0 +0200
+++ linux-2.6.21logfs/include/linux/Kbuild 2007-08-08 02:57:37.0
+0200
@@ -101,6 +101,7 @@ header-y += jffs2.h
header-y += keyctl.h
header-y += limits.h
header-y += lock_dlm_plock.h
On Wed, 8 August 2007 20:07:34 +0300, Artem Bityutskiy wrote:
On Wed, 2007-08-08 at 18:16 +0200, Jörn Engel wrote:
+static inline void logfs_inc_count(struct inode *inode)
+{
+ inode-i_nlink++;
+ mark_inode_dirty_sync(inode);
+}
+
+static inline void logfs_dec_count(struct inode
On Wed, 8 August 2007 20:34:34 +0300, Artem Bityutskiy wrote:
On Wed, 2007-08-08 at 19:15 +0200, Jörn Engel wrote:
On Wed, 8 August 2007 20:07:34 +0300, Artem Bityutskiy wrote:
On Wed, 2007-08-08 at 18:16 +0200, Jörn Engel wrote:
+static inline void logfs_inc_count(struct inode *inode
On Thu, 9 August 2007 01:19:13 +0100, Christoph Hellwig wrote:
On Wed, Aug 08, 2007 at 06:24:47PM +0200, J??rn Engel wrote:
--- linux-2.6.21logfs/include/linux/Kbuild~logfs2007-08-08
02:57:37.0 +0200
+++ linux-2.6.21logfs/include/linux/Kbuild 2007-08-08 02:57:37.0
On Wed, 1 August 2007 15:33:30 -0400, Josef Sipek wrote:
This brings up an very interesting (but painful) question...which makes more
sense? Allowing the modifications in only the top-most branch, or any branch
(given the user allows it at mount-time)?
This is really question to the
On Mon, 16 July 2007 22:14:41 +0530, Satyam Sharma wrote:
On 7/16/07, Al Boldi [EMAIL PROTECTED] wrote:
Satyam Sharma wrote:
Or just cp -al to create multiple trees at (almost) no disk cost
that won't interfere with each other in any way, and makes the
development process / generating
On Mon, 16 July 2007 20:23:04 +0300, Al Boldi wrote:
Jörn Engel wrote:
The only place that can ensure to always break the
link is the kernel. Which is why I wrote the cowlink patches some years
back.
Can you post a patch against 2.6.22?
I can and probably will.
The still need
On Mon, 9 July 2007 08:11:22 +0400, Alexey Dobriyan wrote:
If CONFIG_EXT2_FS_POSIX_ACL is not configured, ext2_clear_inode() will be
empty
function. However, there still will be call and immediate return which can be
avoided.
[...]
+#ifdef CONFIG_EXT2_FS_POSIX_ACL
static void
On Mon, 9 July 2007 22:01:48 +0400, Alexey Dobriyan wrote:
Yes. Note that ext2_clear_inode() is referenced from ext2_sops, so even
empty, it leaves traces in resulting kernel.
Is that your opinion or have you actually measured a difference?
I strongly suspect that compilers are smart enough
On Mon, 9 July 2007 17:02:20 -0500, Dave Kleikamp wrote:
It's not a direct call to a static function. It is called as a
super_ops method. I don't think the overhead is very significant, but
it doesn't look like it could do any harm.
Ah, I missed that fact. Yep, looks fine to me.
Jörn
--
On Mon, 9 July 2007 09:29:38 +1000, David Chinner wrote:
On Sat, Jul 07, 2007 at 12:45:35PM +0200, Jörn Engel wrote:
Oh certainly! I should dust off my dcache_static patch. Some dentries
are hands-off for the shrinker, basically mountpoints and tmpfs. The
patch moves those to a
On Fri, 6 July 2007 13:40:03 -0700, Christoph Lameter wrote:
An interesting topic is certainly
1. Large buffer support
2. icache/dentry/buffer_head defragmentation.
Oh certainly! I should dust off my dcache_static patch. Some dentries
are hands-off for the shrinker, basically
On Fri, 6 July 2007 20:01:10 +1000, David Chinner wrote:
On Fri, Jul 06, 2007 at 04:26:51AM +0200, Nick Piggin wrote:
Keep in mind that the way to get the most out of this meeting
is for the fs people to have topics of the form we'd really
like to do X, can we get some help from the VM?
On Fri, 6 July 2007 09:52:14 -0400, Chris Mason wrote:
On Fri, 6 Jul 2007 23:42:01 +1000 David Chinner [EMAIL PROTECTED] wrote:
Hmmm - I guess you could use it for writeback ordering. I hadn't
really thought about that. Doesn't seem a particularly efficient way
of doing it, though. Why
On Mon, 2 July 2007 17:46:40 -0700, Jared Hulbert wrote:
Right, the solution to swap problem is identical to the rw XIP
filesystem problem.Jörn, that's why you're the self-appointed
subject matter expert!
All right. I'll try to make an important face whenever the subject
comes up.
On Mon, 2 July 2007 10:44:00 -0700, Jared Hulbert wrote:
So what you mean is swap on flash ? Defintively sounds like an
interesting topic, although I'm not too sure it's all that
filesystem-related.
Maybe not. Yet, it would be a very useful place to store data from a
file as a
On Mon, 2 July 2007 08:19:44 +0200, Nick Piggin wrote:
Regarding numbers, there are about a dozen so far which is good
but not as many filesystem maintainers as I had hoped (do they
tend not to get invited to KS?). We may get a few more people yet
so I think if we try to get a room to fit
On Mon, 18 June 2007 03:45:24 -0600, Andreas Dilger wrote:
Too bad everyone is spending time on 10 similar-but-slightly-different
filesystems. This will likely end up with a bunch of filesystems that
implement some easy subset of features, but will not get polished for
users or have a full
On Mon, 18 June 2007 13:50:00 +0900, [EMAIL PROTECTED] wrote:
We will hold a BOF session in Linux Symposium Ottawa June, 2007,
titled Filesystem support for continuous snapshotting. Please join
to discuss you're interested in snapshotting.
I'd like to join, however I won't be in Ottawa. Any
On Mon, 18 June 2007 18:10:21 -0400, Theodore Tso wrote:
On Mon, Jun 18, 2007 at 02:31:14PM -0700, H. Peter Anvin wrote:
And that makes them different from extended attributes, how?
Both of these really are nothing but ad hocky syntactic sugar for
directories, sometimes combined with
On Sun, 17 June 2007 20:35:20 +0200, Andi Kleen wrote:
more intended for research? Does it avoid the long mount
time problem the other Linux log file system have?
Which ones have a mount time problem? Only JFFS{2} or were there others
as well?
Jörn
--
When in doubt, use brute force.
--
On Fri, 15 June 2007 15:51:07 -0700, alan wrote:
Thus, in the end it turns out that this stuff is better handled by
explicit version-control systems (which require explicit operations to
manage revisions) and atomic snapshots (for backup.)
ZFS is the cool new thing in that space. Too bad
On Fri, 15 June 2007 13:03:57 +0400, Evgeniy Polyakov wrote:
On Sun, Jun 03, 2007 at 08:46:04PM +0200, Jörn Engel ([EMAIL PROTECTED])
wrote:
--- /dev/null 2007-03-13 19:15:28.862769062 +0100
+++ linux-2.6.21logfs/fs/logfs/gc.c 2007-06-03 19:18:57.0 +0200
Number of bugs
On Fri, 15 June 2007 12:37:32 +0400, Evgeniy Polyakov wrote:
On Sun, Jun 03, 2007 at 08:38:46PM +0200, Jörn Engel ([EMAIL PROTECTED])
wrote:
This round the patch is split into file-sized hunks. There actually
seem to be kernel developers not manly enough to digest 6000+ lines of
code
On Sun, 10 June 2007 19:24:28 +0200, Arnd Bergmann wrote:
I think this is missing code that sets the initial i_uid/i_gid,
but there may be more missing. Changing the uid value works,
but creating files as non-root user doesn't.
Fixed in patch 557, see
http://logfs.org/logfs/patches
The
On Tue, 12 June 2007 01:51:34 +0200, Arnd Bergmann wrote:
On Tuesday 12 June 2007, Jörn Engel wrote:
The initial storm of review comments has calmed down. I get the
impression that people either lose interest or run out of simple things
to point out. Maybe I should wait a bit before
On Sun, 10 June 2007 18:27:49 +0200, Arnd Bergmann wrote:
On Sunday 03 June 2007, Jörn Engel wrote:
+static int mtdwrite(struct super_block *sb, loff_t ofs, size_t len, void
*buf)
+{
+ struct logfs_super *super = logfs_super(sb);
+ struct mtd_info *mtd = super-s_mtd;
+ struct
On Sun, 10 June 2007 19:24:28 +0200, Arnd Bergmann wrote:
On Sunday 03 June 2007, Jörn Engel wrote:
+struct inode *logfs_new_inode(struct inode *dir, int mode)
+{
+ struct super_block *sb = dir-i_sb;
+ struct inode *inode;
+
+ inode = new_inode(sb
On Sun, 10 June 2007 20:33:05 +0200, Arnd Bergmann wrote:
Then maybe the submit_bio logic should only be done for the -write
path, not for -read. The data that gets written out should already
be present in the page cache for the files, so there is not much point
having again, while you can
On Wed, 6 June 2007 12:29:13 +0100, Paulo Marques wrote:
Jörn Engel wrote:
--- /dev/null2007-03-13 19:15:28.862769062 +0100
+++ linux-2.6.21logfs/fs/logfs/logfs.h 2007-06-03
19:34:07.0 +0200
@@ -0,0 +1,398 @@
+/*
+ * fs/logfs/logfs.h
+ *
+ * As should be obvious
On Sun, 3 June 2007 23:58:43 +0200, Arnd Bergmann wrote:
On Sunday 03 June 2007, Jörn Engel wrote:
+#define COMPR_LEVEL 3
+
+static DEFINE_MUTEX(compr_mutex);
+static struct z_stream_s stream;
Is there a particular reason to choose '3' as the only compression
level? Should
On Mon, 4 June 2007 00:07:36 +0200, Arnd Bergmann wrote:
On Sunday 03 June 2007, Jörn Engel wrote:
+static long decay(long t0, long t, long theta)
+{
+ long shift, fac;
+
+ if (t = 32*theta)
+ return 0;
+
+ shift = t/theta;
+ fac = theta
On Mon, 4 June 2007 00:18:21 +0200, Arnd Bergmann wrote:
On Sunday 03 June 2007, Jörn Engel wrote:
Unchanged:
o error handling
...
Won't happen (unless I get convinced to do otherwise):
o Change LOGFS_BUG() and LOGFS_BUG_ON() to inline functions
These are macros for very much
On Mon, 4 June 2007 00:21:41 +0200, Arnd Bergmann wrote:
On Sunday 03 June 2007, Jörn Engel wrote:
+static DEFINE_MUTEX(compr_mutex);
+
It seems you define a static compre_mutex in both segment.c and in compr.c,
and always lock them both at the same time. Is that a correct observation
On Sun, 3 June 2007 23:50:55 +0200, Arnd Bergmann wrote:
On Sunday 03 June 2007, Jörn Engel wrote:
+/**
+ * struct logfs_device_ops - device access operations
+ *
+ * @read: read from the device
+ * @write: write to the device
+ * @erase
On Sun, 3 June 2007 23:42:25 +0200, Arnd Bergmann wrote:
On Sunday 03 June 2007, Jörn Engel wrote:
+struct logfs_je_spillout {
+ __be64 so_segment[0];
+}__packed;
All the on-disk data structures you define in this file have naturally
aligned members, so the __packed attribute
On Mon, 4 June 2007 14:38:23 +0100, David Woodhouse wrote:
On Mon, 2007-06-04 at 11:12 +0200, Jörn Engel wrote:
On Sun, 3 June 2007 23:42:25 +0200, Arnd Bergmann wrote:
On Sunday 03 June 2007, Jörn Engel wrote:
+struct logfs_je_spillout {
+ __be64 so_segment[0];
+}__packed
This round the patch is split into file-sized hunks. There actually
seem to be kernel developers not manly enough to digest 6000+ lines of
code at once. An I thought I was the only wimp around.
Again, anyone giving comments in the last round is on Cc:.
I'll try to respond to comments but the
--- linux-2.6.21logfs/fs/Kconfig~logfs 2007-06-03 19:18:57.0 +0200
+++ linux-2.6.21logfs/fs/Kconfig2007-06-03 19:18:57.0 +0200
@@ -1351,6 +1351,32 @@ config JFFS2_CMODE_SIZE
endchoice
+config LOGFS
+ tristate Log Filesystem (EXPERIMENTAL)
+ depends on MTD
--- /dev/null 2007-03-13 19:15:28.862769062 +0100
+++ linux-2.6.21logfs/fs/logfs/Makefile 2007-06-03 19:18:57.0 +0200
@@ -0,0 +1,14 @@
+obj-$(CONFIG_LOGFS)+= logfs.o
+
+logfs-y+= compr.o
+logfs-y+= dir.o
+logfs-y+= file.o
+logfs-y+= gc.o
+logfs-y
--- /dev/null 2007-03-13 19:15:28.862769062 +0100
+++ linux-2.6.21logfs/fs/logfs/compr.c 2007-06-03 19:18:57.0 +0200
@@ -0,0 +1,95 @@
+/*
+ * fs/logfs/compr.c- compression routines
+ *
+ * As should be obvious for Linux kernel code, license is GPLv2
+ *
+ * Copyright (c) 2005-2007
--- /dev/null 2007-03-13 19:15:28.862769062 +0100
+++ linux-2.6.21logfs/fs/logfs/dir.c2007-06-03 19:54:55.0 +0200
@@ -0,0 +1,704 @@
+/*
+ * fs/logfs/dir.c - directory-related code
+ *
+ * As should be obvious for Linux kernel code, license is GPLv2
+ *
+ * Copyright (c)
--- /dev/null 2007-03-13 19:15:28.862769062 +0100
+++ linux-2.6.21logfs/fs/logfs/file.c 2007-06-03 19:55:14.0 +0200
@@ -0,0 +1,75 @@
+/*
+ * fs/logfs/file.c - prepare_write, commit_write and friends
+ *
+ * As should be obvious for Linux kernel code, license is GPLv2
+ *
+ *
--- /dev/null 2007-03-13 19:15:28.862769062 +0100
+++ linux-2.6.21logfs/fs/logfs/gc.c 2007-06-03 19:18:57.0 +0200
@@ -0,0 +1,352 @@
+/*
+ * fs/logfs/gc.c - garbage collection code
+ *
+ * As should be obvious for Linux kernel code, license is GPLv2
+ *
+ * Copyright (c)
--- /dev/null 2007-03-13 19:15:28.862769062 +0100
+++ linux-2.6.21logfs/fs/logfs/inode.c 2007-06-03 20:06:15.0 +0200
@@ -0,0 +1,512 @@
+/*
+ * fs/logfs/inode.c- inode handling code
+ *
+ * As should be obvious for Linux kernel code, license is GPLv2
+ *
+ * Copyright (c) 2005-2007
--- /dev/null 2007-03-13 19:15:28.862769062 +0100
+++ linux-2.6.21logfs/fs/logfs/journal.c2007-06-03 19:18:57.0
+0200
@@ -0,0 +1,696 @@
+/*
+ * fs/logfs/journal.c - journal handling code
+ *
+ * As should be obvious for Linux kernel code, license is GPLv2
+ *
+ * Copyright (c)
--- /dev/null 2007-03-13 19:15:28.862769062 +0100
+++ linux-2.6.21logfs/fs/logfs/memtree.c2007-06-03 19:18:57.0
+0200
@@ -0,0 +1,258 @@
+/*
+ * fs/logfs/memtree.c - Simple In-memory B+Tree
+ *
+ * As should be obvious for Linux kernel code, license is GPLv2
+ *
+ * Copyright
--- /dev/null 2007-03-13 19:15:28.862769062 +0100
+++ linux-2.6.21logfs/fs/logfs/segment.c2007-06-03 19:18:57.0
+0200
@@ -0,0 +1,524 @@
+/*
+ * fs/logfs/segment.c - Handling the Object Store
+ *
+ * As should be obvious for Linux kernel code, license is GPLv2
+ *
+ * Copyright
--- /dev/null 2007-03-13 19:15:28.862769062 +0100
+++ linux-2.6.21logfs/fs/logfs/super.c 2007-06-03 19:18:57.0 +0200
@@ -0,0 +1,521 @@
+/*
+ * fs/logfs/super.c
+ *
+ * As should be obvious for Linux kernel code, license is GPLv2
+ *
+ * Copyright (c) 2005-2007 Joern Engel
+ *
+ *
--- /dev/null 2007-03-13 19:15:28.862769062 +0100
+++ linux-2.6.21logfs/fs/logfs/progs/fsck.c 2007-06-03 19:18:57.0
+0200
@@ -0,0 +1,316 @@
+/*
+ * fs/logfs/prog/fsck.c- filesystem check
+ *
+ * As should be obvious for Linux kernel code, license is GPLv2
+ *
+ * Copyright
--- /dev/null 2007-03-13 19:15:28.862769062 +0100
+++ linux-2.6.21logfs/fs/logfs/progs/mkfs.c 2007-06-03 19:18:57.0
+0200
@@ -0,0 +1,324 @@
+/*
+ * fs/logfs/prog/mkfs.c- filesystem generation
+ *
+ * As should be obvious for Linux kernel code, license is GPLv2
+ *
+ *
On Sun, 3 June 2007 21:17:44 +0200, Jan-Benedict Glaw wrote:
On Sun, 2007-06-03 20:38:46 +0200, Jörn Engel [EMAIL PROTECTED] wrote:
This round the patch is split into file-sized hunks. There actually
seem to be kernel developers not manly enough to digest 6000+ lines of
code at once. An I
On Fri, 1 June 2007 09:59:17 +0100, Anton Altaparmakov wrote:
I agree that your patch is a good idea. I reviewed the latest
incarnation and it makes sense to me. And your comment concerning
Thanks.
the flags is a very welcome addition. Probably ought to find its way
into
On Thu, 31 May 2007 15:46:48 -0700, Andrew Morton wrote:
I_LOCK was used for several unrelated purposes, which caused deadlock
situations in certain filesystems as a side effect. One of the purposes
now uses the new I_SYNC bit.
Do we know what those deadlocks were? It's a bit of a
On Sun, 20 May 2007 21:30:52 +0400, Evgeniy Polyakov wrote:
In that case segment size must be more than 32 bits, or below
transformation will not be correct?
Must it? If segment size is just 20bit then the filesystem may only be
52bit. Or 51bit when using signed values.
segsize is long,
On Wed, 23 May 2007 19:07:32 +0400, Evgeniy Polyakov wrote:
On Wed, May 23, 2007 at 02:58:41PM +0200, Jörn Engel ([EMAIL PROTECTED])
wrote:
On Sun, 20 May 2007 21:30:52 +0400, Evgeniy Polyakov wrote:
And what if it is 33 bits? Or it is not allowed?
Not allowed. Both number and size
On Thu, 17 May 2007 16:43:59 +0800, David Woodhouse wrote:
As I mentioned, some techniques like log-structured filesystem could
perform generally better on any kind of flash-based storage with FTL.
Although there are many kinds of FTL, it is commonly true that
it performs well under
On Thu, 17 May 2007 20:03:11 +0400, Evgeniy Polyakov wrote:
Is logfs 32bit fs or 674bit, since although you use 64bit values for
offsets, area management and strange converstions like described below
from offset into segment number are performed in 32bit?
Is it enough for SSD for example to
On Thu, 17 May 2007 17:08:51 +0200, Arnd Bergmann wrote:
On Tuesday 15 May 2007, Jörn Engel wrote:
Add LogFS, a scalable flash filesystem.
Sorry for not commenting earlier, there were so many discussions on version
two that I wanted to wait for the fallout of that instead of duplicating
1 - 100 of 165 matches
Mail list logo
