Mingming Cao wrote:
This patch is on top of i_version_update_vfs.
The i_version field of the inode is set on inode creation and incremented when
the inode is being modified.
ta));
ei->i_dir_start_lookup = 0;
Index: linux-2.6.22-rc4/fs/ext4/inode.c
===
Mingming Cao wrote:
Index: linux-2.6.22-rc4/fs/ext4/super.c
===
--- linux-2.6.22-rc4.orig/fs/ext4/super.c 2007-06-13 17:19:11.0
-0700
+++ linux-2.6.22-rc4/fs/ext4/super.c2007-06-13 17:24:45.0 -0700
@@ -2
Mingming Cao wrote:
This patch is a spinoff of the old nanosecond patches.
It includes some cleanups and addition of a creation timestamp. The
EXT3_FEATURE_RO_COMPAT_EXTRA_ISIZE flag has also been added along with
s
Should be EXT4_FEATURE_RO_COMPAT_EXTRA_ISIZE
-aneesh
-
To unsubscribe from
On Mon, Jul 02, 2007 at 08:28:27PM -0700, Andrew Morton wrote:
> On Tue, 3 Jul 2007 11:10:19 +1000 David Chinner <[EMAIL PROTECTED]> wrote:
>
> Seems sane, although one does wonder whether it's a worthy tradeoff. We
> add additional overhead to readpage[s]() just to avoid some IO during
> mkswap?
On Tue, 3 Jul 2007 11:10:19 +1000 David Chinner <[EMAIL PROTECTED]> wrote:
> Teach do_mpage_readpage() about unwritten extents so we can
> always map them in get_blocks rather than they are are holes on
> read. Allows setup_swap_extents() to use preallocated files on XFS
> filesystems for swap fil
Trond or Bruce, can you please review these patch series and ack if you
agrees? Thanks.
As to performance concerns that raise before the inode version counter
(at least for ext4) is done inside ext4_mark_inode_dirty), so there is
no extra IO work to store this counter to disk.
Mingming
On Sun, 20
On Sat, 2007-06-30 at 13:29 -0400, Andreas Dilger wrote:
> On Jun 30, 2007 10:13 -0400, Mingming Cao wrote:
> > Another approach we have been thinking is using a backing
> > inode(per-inode-with-preallocation) to store the preallocated blocks.
> > When user asked for preallocation on the base ino
On Sat, 2007-06-30 at 10:13 -0400, Mingming Cao wrote:
> On Fri, 2007-06-29 at 13:01 -0700, Andrew Morton wrote:
> > Guys, Mike and Sreenivasa at google are looking into implementing
> > fallocate() on ext2. Of course, any such implementation could and should
> > also be portable to ext3 and ext4
On Mon, 2007-07-02 at 11:49 -0400, Theodore Tso wrote:
> On Sun, Jul 01, 2007 at 09:48:33AM -0500, Jose R. Santos wrote:
> > Is your concern due to being unable to find contiguous block in the
> > case that a bad disk area is in one of the bitmap blocks? One thing we
> > can do is try to search fo
On Sun, Jul 01, 2007 at 09:48:33AM -0500, Jose R. Santos wrote:
> Is your concern due to being unable to find contiguous block in the
> case that a bad disk area is in one of the bitmap blocks? One thing we
> can do is try to search for another set of contiguous blocks and if we
> fail to find one
On Sun, 1 Jul 2007 12:31:53 -0400
Andreas Dilger <[EMAIL PROTECTED]> wrote:
> On Jun 30, 2007 23:40 -0500, Jose R. Santos wrote:
> > Yes, I think bigger block groups will benefit extents a great deal
> > since not only can we have larger extents, but I believe that as the
> > filesystem ages the
On Mon, Jul 02, 2007 at 08:55:43AM +1000, David Chinner wrote:
> On Sat, Jun 30, 2007 at 11:21:11AM +0100, Christoph Hellwig wrote:
> > On Tue, Jun 26, 2007 at 04:02:47PM +0530, Amit K. Arora wrote:
> > > > Can you clarify - what is the current behaviour when ENOSPC (or some
> > > > other
> > > >
12 matches
Mail list logo