On Mon, 2007-05-07 at 23:59 +0200, Jörn Engel wrote:
LogFS has an on-medium tree, fairly similar to Ext2 in structure, so
mount times are O(1). In absolute terms, the OLPC system has mount
times of ~3.3s for JFFS2 and ~60ms for LogFS.
Impressive number
Motivation 2:
Flash is becoming
On Tue, 8 May 2007 09:39:37 +0200, Thomas Gleixner wrote:
Motivation 2:
Flash is becoming increasingly common in standard PC hardware. Nearly
a dozen different manufacturers have announced Solid State Disks
(SSDs), the OLPC and the Intel Classmate no longer contain hard disks
and
On Tue, 8 May 2007 09:23:48 +0200, Thomas Gleixner wrote:
On Tue, 2007-05-08 at 00:01 +0200, Jörn Engel wrote:
This patch is actually independent of LogFS. It fixes a deadlock
hidden in fs/fs-writeback.c that LogFS was unlucky enough to trigger.
I strongly suspect NTFS triggered the same
On Tue, 2007-05-08 at 16:22 +0530, Amit K. Arora wrote:
On Mon, May 07, 2007 at 10:24:37AM -0500, Dave Kleikamp wrote:
On Mon, 2007-05-07 at 17:37 +0530, Amit K. Arora wrote:
On Thu, May 03, 2007 at 09:31:33PM -0700, Andrew Morton wrote:
So we don't implement fallocate on bitmap-based
On Tue, 2007-05-08 at 14:46 +0200, Jan Engelhardt wrote:
+static int __logfs_readdir(struct file *file, void *buf, filldir_t
filldir)
+{
+ err = read_dir(dir, dd, pos);
+ if (err == -EOF)
+ break;
-EOF results in a return code 0 ?
Results
On Tue, May 08, 2007 at 05:54:41PM +0200, Thomas Gleixner ([EMAIL PROTECTED])
wrote:
On Tue, 2007-05-08 at 14:46 +0200, Jan Engelhardt wrote:
+static int __logfs_readdir(struct file *file, void *buf, filldir_t
filldir)
+{
+err = read_dir(dir, dd, pos);
+
On May 07, 2007 21:43 -0400, Theodore Tso wrote:
On Mon, May 07, 2007 at 05:15:41PM -0700, Andrew Morton wrote:
Userspace could presumably repair the mess in most situations by truncating
the file back again. The kernel cannot do that because there might be live
data in amongst there.
On Mon, 2007-05-07 at 21:43 -0400, Theodore Tso wrote:
On Mon, May 07, 2007 at 05:41:39PM -0700, Mingming Cao wrote:
We could check the total number of fs free blocks account before
preallocation happens, if there isn't enough space left, there is no
need to bother preallocating.
On Tue, 2007-05-08 at 18:32 +0200, Jörn Engel wrote:
Please sort includes alphabetically and seperate the
#include linux/mtd/mtd.h from the #include linux/... ones
Sort: will do.
Seperation: Any particular reason for that?
Easier to see the different include/xxx categories
+typedef
Make some miscellaneous changes to the AFS filesystem:
(1) Assert RCU barriers on module exit to make sure RCU has finished with
callbacks in this module.
(2) Correctly handle the AFS server returning a zero-length read.
(3) Split out data zapping calls into one function (afs_zap_data).
Before I forget this again: thanks for the review! It really is
appreciated.
On Tue, 8 May 2007 20:00:41 +0200, Thomas Gleixner wrote:
On Tue, 2007-05-08 at 18:32 +0200, Jörn Engel wrote:
Please sort includes alphabetically and seperate the
#include linux/mtd/mtd.h from the #include
This patchset moves non-filesystem interfaces of v9fs from fs/9p to net/9p.
It moves the transport, packet marshalling and connection layers to net/9p
leaving only the VFS related files in fs/9p.
This patch:
Moves the non-VFS related header files from fs/9p to include/net/9p.
Signed-off-by:
On May 08, 2007 14:17 -0500, Serge E. Hallyn wrote:
As the capability set changes and distributions start tagging
binaries with capabilities, we would like for running an older
kernel to not necessarily make those binaries unusable.
(0. Enable the CONFIG_SECURITY_FS_CAPABILITIES
On Tue, 8 May 2007 22:15:18 +0300, Pekka Enberg wrote:
On 5/8/07, Jörn Engel [EMAIL PROTECTED] wrote:
+typedef __be16 be16;
+typedef __be32 be32;
+typedef __be64 be64;
Why are those typedefs necessary ?
Not strictly. I tend to use the be* types fairly often in the code and
On Tue, 8 May 2007 14:51:02 -0600
Latchesar Ionkov [EMAIL PROTECTED] wrote:
This patchset moves non-filesystem interfaces of v9fs from fs/9p to net/9p.
It moves the transport, packet marshalling and connection layers to net/9p
leaving only the VFS related files in fs/9p.
(Please cc [EMAIL
On Tue, 8 May 2007 22:58:26 +0200, Thomas Gleixner wrote:
On Tue, 2007-05-08 at 22:25 +0200, Jörn Engel wrote:
Kernel doc comments as:
/**
* struct hrtimer - the basic hrtimer structure
* @node: red black tree node for time ordered insertion
* @expires:the
Quoting Andreas Dilger ([EMAIL PROTECTED]):
On May 08, 2007 14:17 -0500, Serge E. Hallyn wrote:
As the capability set changes and distributions start tagging
binaries with capabilities, we would like for running an older
kernel to not necessarily make those binaries unusable.
(0.
On 5/8/07, Andrew Morton [EMAIL PROTECTED] wrote:
On Tue, 8 May 2007 14:51:02 -0600
Latchesar Ionkov [EMAIL PROTECTED] wrote:
This patchset moves non-filesystem interfaces of v9fs from fs/9p to net/9p.
It moves the transport, packet marshalling and connection layers to net/9p
leaving only
On Tue, 8 May 2007 01:53:38 -0400, Albert Cahalan wrote:
You seem to be missing the immutable bit. This is really useful
for dealing with buggy or badly-designed things running as root.
I've used to to protect /dev/null from becoming a normal file
filled with junk, and to protect
On Wed, 9 May 2007 00:44:14 +0200, Ingo Oeser wrote:
On Tuesday 08 May 2007, Thomas Gleixner wrote:
On Tue, 2007-05-08 at 00:00 +0200, Jörn Engel wrote:
+#define packed __attribute__((__packed__))
Please use the __attribute__((__packed__)) on your structs instead of
creating some
On Tue, 8 May 2007 15:52:53 -0700, Greg KH wrote:
On Tue, May 08, 2007 at 10:58:27PM +0200, J??rn Engel wrote:
Basically I prefer be64 over __be64 for similar reasons that most people
prefer u64 over __u64. Others prefer uint64_t over both, but C99 hasn't
defined beint64_t yet.
There
On Wed, May 09, 2007 at 01:10:09AM +0200, J??rn Engel wrote:
The remaining question is how to deal with kernel-only code that uses
be64. Convert that to __be64 as well? Or introduce be64 in
include/linix/types.h instead?
I say leave it alone for now, it's not that common :)
thanks,
greg
22 matches
Mail list logo
