ext4-patch-queue rebased to 2.6.22

ext4-patch-queue rebased to 2.6.22

[Theodore Ts'o]

Per our discussion on the call, I've moved the fallocate patches back up
to the front of the queue, and rebased the syscall numbers to 2.6.22.
So we're just waiting for Amit to make the minor on-disk format change
Andreas suggested before we push to Linus.

					- Ted

Re: ext4-patch-queue rebased to 2.6.22

[Mingming Cao]

On Mon, 2007-07-09 at 13:37 -0400, Theodore Ts'o wrote:
> Per our discussion on the call, I've moved the fallocate patches back up
> to the front of the queue, and rebased the syscall numbers to 2.6.22.

I updated the ext4 patch queue.

It seem there is conflict to apply delayed allocation patch, fixed it.

Also I removed the ext4_no_inode_version mount option patch per our
discussion this morning.

At last, applied a few clean ups from Aneesh to the ext4 patch queue.

diff --git a/ext4-fallocate-1-syscall_i386_amd64_ppc
b/ext4-fallocate-1-syscall_i386_amd64_ppc
index 0f88bc9..91a8708 100644
--- a/ext4-fallocate-1-syscall_i386_amd64_ppc
+++ b/ext4-fallocate-1-syscall_i386_amd64_ppc
@@ -221,7 +221,7 @@ Index: linux-2.6.22-rc6/include/asm-x86_64/unistd.h
  __SYSCALL(__NR_timerfd, sys_timerfd)
  #define __NR_eventfd          284
  __SYSCALL(__NR_eventfd, sys_eventfd)
-+#define __NR_fallocate                284
++#define __NR_fallocate                285
 +__SYSCALL(__NR_fallocate, sys_fallocate)
  
  #ifndef __NO_STUBS
diff --git a/ext4-nanosecond-patch b/ext4-nanosecond-patch
index a8fb57e..e792cdd 100644
--- a/ext4-nanosecond-patch
+++ b/ext4-nanosecond-patch
@@ -3,7 +3,7 @@ From: Kalpak Shah <kalpak@clusterfs.com>
 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
+EXT4_FEATURE_RO_COMPAT_EXTRA_ISIZE flag has also been added along with
 s_{min, want}_extra_isize fields in struct ext3_super_block.

 Signed-off-by: Andreas Dilger <adilger@clusterfs.com>
diff --git a/ext4_remove_subdirs_limit.patch
b/ext4_remove_subdirs_limit.patch
index effd545..83f4d5a 100644
--- a/ext4_remove_subdirs_limit.patch
+++ b/ext4_remove_subdirs_limit.patch
@@ -1,4 +1,4 @@
-From: kalpak@clusterfs.com Thu May 17 17:21:08 2007
+From: Kalpak Shah <kalpak@clusterfs.com>
 Hi,


> So we're just waiting for Amit to make the minor on-disk format change
> Andreas suggested before we push to Linus.

Yep.

Thanks,
Mingming

Re: ext4-patch-queue rebased to 2.6.22

[Amit K. Arora]

On Mon, Jul 09, 2007 at 01:37:56PM -0400, Theodore Ts'o wrote:
> So we're just waiting for Amit to make the minor on-disk format change
> Andreas suggested before we push to Linus.

I have commited following changes to the ext4 patch queue:

1. Updated ext4-fallocate-1-syscall_i386_amd64_ppc to add compat wrapper
   for x86_64/ia32. This addresses Heiko's concern that we did not have
   a wrapper for ia32.

2. Added a new patch ext4-fallocate-8-new-ondisk-format and updated
   the series file. This patch, as suggested by Andreas, will allow
   an initialized extent to be of max 2^15 length. Main purpose of this
   change is to have a better extent-to-group alignment.
   For uninitialized extents the max length remains same - i.e. 2^15 - 1.


Thanks!
--
Regards,
Amit Arora

Re: ext4-patch-queue rebased to 2.6.22

[Andreas Dilger]

On Jul 10, 2007  20:24 +0530, Amit K. Arora wrote:
> On Mon, Jul 09, 2007 at 01:37:56PM -0400, Theodore Ts'o wrote:
> > So we're just waiting for Amit to make the minor on-disk format change
> > Andreas suggested before we push to Linus.
> 
> 2. Added a new patch ext4-fallocate-8-new-ondisk-format and updated
>    the series file. This patch, as suggested by Andreas, will allow
>    an initialized extent to be of max 2^15 length. Main purpose of this
>    change is to have a better extent-to-group alignment.
>    For uninitialized extents the max length remains same - i.e. 2^15 - 1.

One tiny change I'd ask for in this patch (it isn't critical to get in
before the upstream submission as it is only code style) is instead of
using (EXT_MAX_LEN - 1) for uninitialized extents, instead use a separate
#define EXT_UNINIT_MAX_LEN (EXT_MAX_LEN - 1) and use that in the code.
While a minor change, this localizes the knowledge of the maximum length
of uninitialized extents into just one place - right after the maximum
length of initialized extents.

It might even make sense to change the other #define to be called
EXT_INIT_MAX_LEN so people have to think about this when using the #define.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

Re: ext4-patch-queue rebased to 2.6.22

[Amit K. Arora]

On Tue, Jul 10, 2007 at 11:09:39AM -0600, Andreas Dilger wrote:
> On Jul 10, 2007  20:24 +0530, Amit K. Arora wrote:
> > On Mon, Jul 09, 2007 at 01:37:56PM -0400, Theodore Ts'o wrote:
> > > So we're just waiting for Amit to make the minor on-disk format change
> > > Andreas suggested before we push to Linus.
> > 
> > 2. Added a new patch ext4-fallocate-8-new-ondisk-format and updated
> >    the series file. This patch, as suggested by Andreas, will allow
> >    an initialized extent to be of max 2^15 length. Main purpose of this
> >    change is to have a better extent-to-group alignment.
> >    For uninitialized extents the max length remains same - i.e. 2^15 - 1.
> 
> One tiny change I'd ask for in this patch (it isn't critical to get in
> before the upstream submission as it is only code style) is instead of
> using (EXT_MAX_LEN - 1) for uninitialized extents, instead use a separate
> #define EXT_UNINIT_MAX_LEN (EXT_MAX_LEN - 1) and use that in the code.
> While a minor change, this localizes the knowledge of the maximum length
> of uninitialized extents into just one place - right after the maximum
> length of initialized extents.
> 
> It might even make sense to change the other #define to be called
> EXT_INIT_MAX_LEN so people have to think about this when using the #define.

Done. Changes are in ext4 patch queue.
Can you please have a quick look and see if this is what you preferred ?

--
Regards,
Amit Arora

Re: ext4-patch-queue rebased to 2.6.22

[Andreas Dilger]

On Jul 10, 2007  23:25 +0530, Amit K. Arora wrote:
> On Tue, Jul 10, 2007 at 11:09:39AM -0600, Andreas Dilger wrote:
> > It might even make sense to change the other #define to be called
> > EXT_INIT_MAX_LEN so people have to think about this when using the #define.
> 
> Done. Changes are in ext4 patch queue.
> Can you please have a quick look and see if this is what you preferred ?

Yes, it looks good, though I wonder if it also makes sense to change the
ext4_ext_*_uninitialized() code to use EXT_INIT_MAX_LEN instead of 0x8000,
since that makes it a bit clearer that the two are related.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.