On Tue, 18 Sep 2007, Christoph Lameter wrote:
Index: linux-2.6/include/linux/mm.h
===
--- linux-2.6.orig/include/linux/mm.h 2007-09-17 21:46:06.0 -0700
+++ linux-2.6/include/linux/mm.h 2007-09-17 23:56:54.0
On 19 Sep 2007, at 07:32, David Rientjes wrote:
On Tue, 18 Sep 2007, Christoph Lameter wrote:
Index: linux-2.6/include/linux/mm.h
===
--- linux-2.6.orig/include/linux/mm.h 2007-09-17
21:46:06.0 -0700
+++
On Tue, 18 Sep 2007 20:36:10 -0700
Christoph Lameter [EMAIL PROTECTED] wrote:
Make vunmap return the page array that was used at vmap. This is useful
if one has no structures to track the page array but simply stores the
virtual address somewhere. The disposition of the page array can be
On Wed, 19 Sep 2007, Anton Altaparmakov wrote:
Index: linux-2.6/include/linux/mm.h
===
--- linux-2.6.orig/include/linux/mm.h 2007-09-17 21:46:06.0
-0700
+++ linux-2.6/include/linux/mm.h 2007-09-17
On 19 Sep 2007, at 09:09, David Rientjes wrote:
On Wed, 19 Sep 2007, Anton Altaparmakov wrote:
Index: linux-2.6/include/linux/mm.h
===
--- linux-2.6.orig/include/linux/mm.h 2007-09-17 21:46:06.0
-0700
+++
On Wed, 19 Sep 2007, Anton Altaparmakov wrote:
Although it may cause a problem as highmem.h also includes mm.h so a bit of
trickery may be needed to get it to compile...
I suspect that is_vmalloc_addr() should not be in linux/mm.h at all and should
be in linux/vmalloc.h instead and
On 9/19/07, David Chinner [EMAIL PROTECTED] wrote:
The problem is this: to alter the fundamental block size of the
filesystem we also need to alter the data block size and that is
exactly the piece that linux does not support right now. So while
we have the capability to use large block sizes
On Wednesday 19 September 2007 04:30, Linus Torvalds wrote:
On Tue, 18 Sep 2007, Nick Piggin wrote:
ROFL! Yeah of course, how could I have forgotten about our trusty OOM
killer as the solution to the fragmentation problem? It would only have
been funnier if you had said to reboot every so
On Wed, 19 Sep 2007 08:34:47 +0100
Anton Altaparmakov [EMAIL PROTECTED] wrote:
Hi Christoph,
On 19 Sep 2007, at 04:36, Christoph Lameter wrote:
Currently there is a strong tendency to avoid larger page
allocations in
the kernel because of past fragmentation issues and the current
Am Donnerstag 13 September 2007 schrieb Dave Kleikamp:
On Wed, 2007-09-12 at 18:58 +0200, Michal Piotrowski wrote:
Subject : umount triggers a warning in jfs and takes almost a minute
References : http://lkml.org/lkml/2007/9/4/73
Last known good : ?
Submitter : Oliver
On Wed, 2007-09-19 at 13:44 +0200, Oliver Neukum wrote:
Am Donnerstag 13 September 2007 schrieb Dave Kleikamp:
On Wed, 2007-09-12 at 18:58 +0200, Michal Piotrowski wrote:
Subject : umount triggers a warning in jfs and takes almost a
minute
References :
On 19 Sep 2007, at 10:19, David Rientjes wrote:
On Wed, 19 Sep 2007, Anton Altaparmakov wrote:
Although it may cause a problem as highmem.h also includes mm.h so
a bit of
trickery may be needed to get it to compile...
I suspect that is_vmalloc_addr() should not be in linux/mm.h at
all and
On Wed, Sep 19, 2007 at 03:09:10PM +1000, David Chinner wrote:
Ok, let's step back for a moment and look at a basic, fundamental
constraint of disks - seek capacity. A decade ago, a terabyte of
filesystem had 30 disks behind it - a seek capacity of about
6000 seeks/s. Nowdays, that's a single
Christoph Lameter wrote:
Add a flag SlabReclaimable() that is set on slabs with a method
that allows defrag/reclaim. Clear the flag if a reclaim action is not
successful in reducing the number of objects in a slab. The reclaim
flag is set again if all objects have been allocated from it.
On Mon, 17 Sep 2007 07:29:05 -0400
Jeff Layton [EMAIL PROTECTED] wrote:
This patchset is the latest one for fixing the clearing of setuid/setgid
bits in networked filesystems. It should apply cleanly to 2.6.23-rc4-mm1.
This is basically the same patchset as take 5. The main differences are
This patchset is a medium scale rewrite of the export operations
interface. The goal is to make the interface less complex, and
easier to understand from the filesystem side, aswell as preparing
generic support for exporting of 64bit inode numbers.
This touches all nfs exporting filesystems, and
Add a structured fid type so that we don't have to pass an array
of u32 values around everywhere. It's a union of possible layouts.
As a start there's only the u32 array and the traditional 32bit
inode format, but there will be more in one of my next patchset
when I start to document the various
Trivial switch over to the new generic helpers.
Signed-off-by: Christoph Hellwig [EMAIL PROTECTED]
Index: linux-2.6/fs/ext2/super.c
===
--- linux-2.6.orig/fs/ext2/super.c 2007-09-13 15:10:46.0 +0200
+++
Trivial switch over to the new generic helpers.
Signed-off-by: Christoph Hellwig [EMAIL PROTECTED]
Index: linux-2.6/fs/ext3/super.c
===
--- linux-2.6.orig/fs/ext3/super.c 2007-09-13 15:10:46.0 +0200
+++
Add the guts for the new filesystem API to exportfs.
There's now a fh_to_dentry method that returns a dentry for the
object looked for given a filehandle fragment, and a fh_to_parent
operation that returns the dentry for the encoded parent directory
in case the file handle contains it.
There
Trivial switch over to the new generic helpers.
Signed-off-by: Christoph Hellwig [EMAIL PROTECTED]
Index: linux-2.6/fs/ext4/super.c
===
--- linux-2.6.orig/fs/ext4/super.c 2007-09-13 15:10:46.0 +0200
+++
Trivial switch over to the new generic helpers.
Signed-off-by: Christoph Hellwig [EMAIL PROTECTED]
Index: linux-2.6/fs/efs/namei.c
===
--- linux-2.6.orig/fs/efs/namei.c 2007-09-13 15:10:46.0 +0200
+++
Trivial switch over to the new generic helpers.
Signed-off-by: Christoph Hellwig [EMAIL PROTECTED]
Index: linux-2.6/fs/ntfs/namei.c
===
--- linux-2.6.orig/fs/ntfs/namei.c 2007-09-13 15:10:45.0 +0200
+++
Trivial switch over to the new generic helpers.
Signed-off-by: Christoph Hellwig [EMAIL PROTECTED]
Index: linux-2.6/fs/jfs/jfs_inode.h
===
--- linux-2.6.orig/fs/jfs/jfs_inode.h 2007-09-13 15:10:46.0 +0200
+++
Very little changes here, fat had a mostly no op decode_fh before
and does not store any parent information.
Signed-off-by: Christoph Hellwig [EMAIL PROTECTED]
Index: linux-2.6/fs/fat/inode.c
===
--- linux-2.6.orig/fs/fat/inode.c
OCFS2 has it's own 64bit-firendly filehandle format so we can't use
the generic helpers here. I'll add a struct for the types later.
Signed-off-by: Christoph Hellwig [EMAIL PROTECTED]
Index: linux-2.6/fs/ocfs2/export.c
===
---
I'm not sure what people were thinking when adding support to
export tmpfs, but here's the conversion anyway:
Signed-off-by: Christoph Hellwig [EMAIL PROTECTED]
Index: linux-2.6/mm/shmem.c
===
--- linux-2.6.orig/mm/shmem.c
Now that all filesystems are converted remove support for the
old methods.
Signed-off-by: Christoph Hellwig [EMAIL PROTECTED]
Index: linux-2.6/fs/exportfs/expfs.c
===
--- linux-2.6.orig/fs/exportfs/expfs.c 2007-08-29
This one is a lot more complicated than the previous ones. XFS already
had a very clever scheme for supporting 64bit inode numbers in filehandles,
and I've reworked this to be some kind of a prototype for the generic
64bit inode filehandle support.
Signed-off-by: Christoph Hellwig [EMAIL
Another nice little cleanup by using the new methods.
Signed-off-by: Christoph Hellwig [EMAIL PROTECTED]
Index: linux-2.6/fs/reiserfs/inode.c
===
--- linux-2.6.orig/fs/reiserfs/inode.c 2007-09-13 15:10:45.0 +0200
+++
Convert gfs2 to the new ops. Uses a similar structure to the generic
helpers, but gfs2 has it's own file handle formats.
Signed-off-by: Christoph Hellwig [EMAIL PROTECTED]
Index: linux-2.6/fs/gfs2/ops_export.c
===
---
Nice little cleanup by consolidating things a little and using
a structure for the special file handle format.
Signed-off-by: Christoph Hellwig [EMAIL PROTECTED]
Index: linux-2.6/fs/isofs/export.c
===
---
Now that nfsd has stopped writing to the find_exported_dentry member
we an mark the export_operations const
Signed-off-by: Christoph Hellwig [EMAIL PROTECTED]
Index: linux-2.6/fs/efs/super.c
===
--- linux-2.6.orig/fs/efs/super.c
Update deocumentation to the current state of affairs. Remove duplicated
method descruptions in exportfs.h and point to Documentation/filesystems/
Exporting instead. Add a little file header comment in expfs.c describing
what's going on and mentioning Neils and my copyright [1].
[1] Neil, in
On Wed, 19 Sep 2007, Anton Altaparmakov wrote:
There even is such a function already in mm/sparse.c::vaddr_in_vmalloc_area()
with pretty identical content. I would suggest either this new inline should
go away completely and use the existing one and export it or the existing one
should go
On Wed, 19 Sep 2007, Anton Altaparmakov wrote:
I suspect that is_vmalloc_addr() should not be in linux/mm.h at all and should
be in linux/vmalloc.h instead and vmalloc.h should include linux/highmem.h.
That would be more sensible than sticking a vmalloc related function into
linux/mm.h where
On Wed, 19 Sep 2007, Eric Dumazet wrote:
1) Only power of two allocations are good candidates, or we waste RAM
Correct.
2) On i386 machines, we have a small vmalloc window. (128 MB default value)
Many servers with 4GB memory (PAE) like to boot with vmalloc=32M option to
get 992MB of
On Wed, 19 Sep 2007, Andi Kleen wrote:
alloc_page(GFP_VFALLBACK, order, )
Is there a reason this needs to be a GFP flag versus a wrapper
around alloc_page/free_page ? page_alloc.c is already too complicated
and it's better to keep new features separated. The only drawback
would
On Wed, 19 Sep 2007, Gabriel C wrote:
Christoph Lameter wrote:
+ if (is_vmalloc_addr(word))
+ page = vmalloc_to_page(word)
^^
Missing ' ; '
Argh. Late beautification attempts are backfiring
-
To unsubscribe from this list:
On 19 Sep 2007, at 18:29, Christoph Lameter wrote:
On Wed, 19 Sep 2007, Anton Altaparmakov wrote:
I suspect that is_vmalloc_addr() should not be in linux/mm.h at
all and should
be in linux/vmalloc.h instead and vmalloc.h should include linux/
highmem.h.
That would be more sensible than
On Wed, 19 Sep 2007, Rik van Riel wrote:
Why is it safe to not use the normal page flag bit operators
for these page flags operations?
Because SLUB always modifies page flags under PageLock.
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to
Convert the GFP_KERNEL flag used in JBD/JBD2 to GFP_NOFS, consistent
with the rest of kmalloc flag used in the JBD/JBD2 layer.
Signed-off-by: Mingming Cao [EMAIL PROTECTED]
---
fs/jbd/journal.c |6 +++---
fs/jbd/revoke.c |8
fs/jbd2/journal.c |6 +++---
fs/jbd2/revoke.c
On Wed, 2007-09-19 at 12:15 -0700, Mingming Cao wrote:
Here is the patch to clean up __GFP_NOFAIL flag in jbd/jbd2. In all
cases except one handles memory allocation failure so I get rid of those
GFP_NOFAIL flags.
Also, shouldn't we use GFP_KERNEL instead of GFP_NOFS flag for kmalloc
in
On Wed, 2007-09-19 at 14:26 -0500, Dave Kleikamp wrote:
On Wed, 2007-09-19 at 12:15 -0700, Mingming Cao wrote:
Here is the patch to clean up __GFP_NOFAIL flag in jbd/jbd2. In all
cases except one handles memory allocation failure so I get rid of those
GFP_NOFAIL flags.
Also,
On Sep 19, 2007 12:15 -0700, Mingming Cao wrote:
@@ -96,8 +96,7 @@ static int start_this_handle(journal_t *
alloc_transaction:
if (!journal-j_running_transaction) {
- new_transaction = kmalloc(sizeof(*new_transaction),
-
On Wed, 2007-09-19 at 19:28 +, Dave Kleikamp wrote:
On Wed, 2007-09-19 at 14:26 -0500, Dave Kleikamp wrote:
On Wed, 2007-09-19 at 12:15 -0700, Mingming Cao wrote:
Here is the patch to clean up __GFP_NOFAIL flag in jbd/jbd2. In all
cases except one handles memory allocation failure
The following is a series of patches related to Unionfs. They represent a
few code cleanups (suggested or inspired by comments on the previous set of
patches), and a few more bug fixes (esp. to cache coherency). These fixes
were tested on our 2.6.23-rc6 latest code, as well as the backports to
Signed-off-by: Erez Zadok [EMAIL PROTECTED]
Acked-by: Josef Sipek [EMAIL PROTECTED]
---
fs/unionfs/commonfops.c | 12 ++--
fs/unionfs/dentry.c |2 +-
fs/unionfs/dirfops.c|4 ++--
fs/unionfs/file.c | 12 ++--
fs/unionfs/mmap.c |6 +++---
Signed-off-by: Erez Zadok [EMAIL PROTECTED]
Acked-by: Josef Sipek [EMAIL PROTECTED]
---
fs/unionfs/dentry.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/fs/unionfs/dentry.c b/fs/unionfs/dentry.c
index 91f9780..9e0742d 100644
--- a/fs/unionfs/dentry.c
+++
Ensure that our lookup locking is consistent and symmetric: if a lock
existed before calling lookup_backend, it should remain so; only if
performing a lookup of a known new dentry, should lookup_backend return a
newly-locked dentry-inode info (and only if there was no error). Document
this
Prevent an oops if a lower file is deleted and then it is stat'ed from the
upper layer. Ensure that we return a negative dentry so the user will get
an ENOENT. Properly dput/mntput so we don't leak references at the lower
file system.
Signed-off-by: Erez Zadok [EMAIL PROTECTED]
Acked-by: Josef
On Wed, 2007-09-19 at 14:34 -0700, Andrew Morton wrote:
On Wed, 19 Sep 2007 12:22:09 -0700
Mingming Cao [EMAIL PROTECTED] wrote:
Convert the GFP_KERNEL flag used in JBD/JBD2 to GFP_NOFS, consistent
with the rest of kmalloc flag used in the JBD/JBD2 layer.
Signed-off-by: Mingming Cao
On Wed, 19 Sep 2007, KAMEZAWA Hiroyuki wrote:
Hmm, I don't like returning array which someone allocated in past and forgot.
But that is exactly the point. There is no need to keep track of the
information that is of no interest until the disposition of the mapping.
And, area-page[] array
On Wed, Sep 19, 2007 at 04:04:30PM +0200, Andrea Arcangeli wrote:
On Wed, Sep 19, 2007 at 03:09:10PM +1000, David Chinner wrote:
Ok, let's step back for a moment and look at a basic, fundamental
constraint of disks - seek capacity. A decade ago, a terabyte of
filesystem had 30 disks behind
On Mon, 17 Sep 2007 16:46:32 -0500 Michael Halcrow [EMAIL PROTECTED] wrote:
Add a set of functions through which all I/O to lower files is
consolidated. This patch adds a new inode_info reference to a
persistent lower file for each eCryptfs inode; another patch later in
this series will set
On Mon, 17 Sep 2007 16:47:10 -0500 Michael Halcrow [EMAIL PROTECTED] wrote:
Replace page encryption and decryption routines and inode size write
routine with versions that utilize the read_write.c functions.
Signed-off-by: Michael Halcrow [EMAIL PROTECTED]
---
fs/ecryptfs/crypto.c
On Mon, 17 Sep 2007 16:48:44 -0500 Michael Halcrow [EMAIL PROTECTED] wrote:
+ if ((rc = ecryptfs_write_lower(ecryptfs_dentry-d_inode,
checkpatch missed the assignment-in-an-if here.
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to
On Mon, 17 Sep 2007 16:50:16 -0500 Michael Halcrow [EMAIL PROTECTED] wrote:
Convert readpage, prepare_write, and commit_write to use read_write.c
routines. Remove sync_page; I cannot think of a good reason for
implementing that in eCryptfs.
Signed-off-by: Michael Halcrow [EMAIL PROTECTED]
58 matches
Mail list logo
