2007-07-09 17:37:58

by Theodore Ts'o

[permalink] [raw]
Subject: ext4-patch-queue rebased to 2.6.22


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


2007-07-10 00:15:40

by Mingming Cao

[permalink] [raw]
Subject: Re: ext4-patch-queue rebased to 2.6.22

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 <[email protected]>
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 <[email protected]>
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: [email protected] Thu May 17 17:21:08 2007
+From: Kalpak Shah <[email protected]>
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

2007-07-10 14:54:15

by Amit K. Arora

[permalink] [raw]
Subject: Re: ext4-patch-queue rebased to 2.6.22

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

2007-07-10 17:09:41

by Andreas Dilger

[permalink] [raw]
Subject: Re: ext4-patch-queue rebased to 2.6.22

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.

2007-07-10 17:55:52

by Amit K. Arora

[permalink] [raw]
Subject: Re: ext4-patch-queue rebased to 2.6.22

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

2007-07-10 20:26:48

by Andreas Dilger

[permalink] [raw]
Subject: Re: ext4-patch-queue rebased to 2.6.22

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.