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 PROTE
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 messag
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.
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
On Mon, 17 Sep 2007 16:46:32 -0500 Michael Halcrow <[EMAIL PROTECTED]> wrote:
> +/**
> + * ecryptfs_write_lower
> + * @ecryptfs_inode: The eCryptfs inode
> + * @data: Data to write
> + * @offset: Byte offset in the lower file to which to write the data
> + * @size: Number of bytes from @data to wr
On Sep 19, 2007 12:22 -0700, Mingming Cao 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.
>
> @@ -653,7 +653,7 @@ static journal_t * journal_init_common (
> - journal = kmalloc(sizeof(*journal), GFP_KERN
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 b
On Wed, 19 Sep 2007 15:15:58 -0700 (PDT)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> 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
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 u
On Wed, 2007-09-19 at 13:48 -0600, Andreas Dilger wrote:
> 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(*
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: Mi
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 <[EMAIL PROTECTED]>
>
> ---
> fs/jbd/journal.c |6 ++
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
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
+++ b/fs/unio
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 behavio
Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
Acked-by: Josef Sipek <[EMAIL PROTECTED]>
---
fs/unionfs/dentry.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/unionfs/dentry.c b/fs/unionfs/dentry.c
index f32922e..91f9780 100644
--- a/fs/unionfs/dentry.c
+++ b/fs/uni
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 +++---
fs/un
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
2
Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
Acked-by: Josef Sipek <[EMAIL PROTECTED]>
---
fs/unionfs/fanout.h |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/fs/unionfs/fanout.h b/fs/unionfs/fanout.h
index c5bf454..afeb9f6 100644
--- a/fs/unionfs/fanout.h
+++ b/fs/unionf
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 allocatio
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 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.
> >
> > Als
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
>
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 Tue, 2007-09-18 at 19:19 -0700, Andrew Morton wrote:
> On Tue, 18 Sep 2007 18:00:01 -0700 Mingming Cao <[EMAIL PROTECTED]> wrote:
>
> > JBD: Replace slab allocations with page cache allocations
> >
> > JBD allocate memory for committed_data and frozen_data from slab. However
> > JBD should not
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 t
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 stickin
On 19 Sep 2007, at 18:29, Christoph Lameter wrote:
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
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
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
> w
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, 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 whe
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
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 cas
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
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
+++ linu
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
===
--- linux-2.6
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
===
--- linux-2.6.orig/fs/isof
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 13:52:01.000
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 PROTEC
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
===
--- l
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 2007-
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
+++ linux-2.6/f
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
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
+++ linux-2.6/fs/ef
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
+++ linux-2.6/fs/
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 are
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
+++ linux-2.6/fs/e
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
+++ linux-2.6/fs/e
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
+++ linux-2.6/fs/e
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
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
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
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.
Signed-
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 sing
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 s
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 : htt
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
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 cu
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 ever
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
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 vmal
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
+++ linux-2.6/include
Christoph Lameter <[EMAIL PROTECTED]> writes:
It seems like a good idea simply because the same functionality
is already open coded in a couple of places and unifying
that would be a good thing. But ...
> The patchset provides this functionality in stages. Stage 1 introduces
> the basic fall bac
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-
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 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
+++ linux-2.6/include
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
defragmentation methods are still evolving. It is not clear to what
extend
they can provi
68 matches
Mail list logo
