This series of patch forkes a new filesystem, ext4, from the current
ext3 filesystem, as the code base to work on, for the big features such
as extents and larger fs(48 bit blk number) support, per our discussion
on lkml a few weeks ago.
[patch 1/5] ext4-fork.patch
1) create a ext4 dir under fs/
2) copy all ext3 files to fs/ext4
3) rename all ext3/EXT3 symbols in ext4 filesystem source code to
ext4/EXT4 correspondingly.
[patch 2/5] register-ext3dev.patch
Registered the ext4 filesystem as ext3dev at this moment, as Ted Tso has
proposed before. The intention is to explicitly tell the new filesystem
is still under development. And it will be re-register itself as ext4
filesystem once the on-disk format changes are pretty much developed and
merged.
[patch 3/5] fork-jbd2.patch
Forking JBD2 from JBD at the same time forking ext4 filesystem, as we
discussed before. New JBD2 layer is only used by ext4 for now, and will
support both 64bit and 32 bit blk number.
[patch 4/5] jbd2-rename-funcs.patch
Rename all exported symbols in JBD2 layer with a jbd2_ prefix to
distinguish them from those symbols from JBD layer.
[patch 5/5] rename-jbd2-in-ext4.patch
Use JBD2 functions/header files in ext4 filesystem
Tested the changes on i386 machine(load ext4and jbd2 as module and also
tested as built-in). Able to mount ext3dev filesystem on an exisiting
ext3 filesystem, and survived a few hours fsx tests and tiobench tests.
Patches against 2.6.18-rc4 kernel. Previous extents and 48bit ext3
patches are rebased to against ext4 filesystem, will send them out in
another thread. The whole series of ext4 patches (including patches to
fork ext4 filesystem and patches to add extents and 48 bit blk number)
are avaible at
http://ext2.sourceforge.net/48bitext3/patches/latest/
Any comments? Could we add ext4/jbd2 to mm tree for a wider testing?
Thanks,
Mingming
Mingming Cao wrote:
> This series of patch forkes a new filesystem, ext4, from the current
> ext3 filesystem, as the code base to work on, for the big features such
> as extents and larger fs(48 bit blk number) support, per our discussion
> on lkml a few weeks ago.
[...]
> Any comments? Could we add ext4/jbd2 to mm tree for a wider testing?
ext4 developers should create a git tree with the consensus-accepted
patches.
That way Linus can pull as soon as the merge window opens, Andrew is
guaranteed to have the latest in his -mm tree, and users and other
kernel hackers can easily follow the development without having to
gather scattered patches from lkml.
Jeff
Hi,
On 10/08/06, Mingming Cao <[email protected]> wrote:
> This series of patch forkes a new filesystem, ext4, from the current
> ext3 filesystem, as the code base to work on, for the big features such
> as extents and larger fs(48 bit blk number) support, per our discussion
> on lkml a few weeks ago.
It appears after a few minutes of running
#! /bin/bash
while true
do
sudo mount -o loop -t ext3dev /home/fs-farm/ext4.img /mnt/fs-farm/ext4/
sudo umount /mnt/fs-farm/ext4/
done
BUG: warning at /usr/src/linux-work2/fs/inotify.c:171/set_dentry_child_flags()
[<c0104006>] show_trace_log_lvl+0x58/0x152
[<c01046ad>] show_trace+0xd/0x10
[<c0104775>] dump_stack+0x19/0x1b
[<c018aa7f>] set_dentry_child_flags+0x5a/0x119
[<c018ab94>] remove_watch_no_event+0x56/0x64
[<c018ac62>] inotify_remove_watch_locked+0x12/0x34
[<c018af1b>] inotify_rm_wd+0x75/0x93
[<c018b468>] sys_inotify_rm_watch+0x40/0x58
[<c0102f15>] sysenter_past_esp+0x56/0x8d
DWARF2 unwinder stuck at sysenter_past_esp+0x56/0x8d
Leftover inexact backtrace:
[<c01046ad>] show_trace+0xd/0x10
[<c0104775>] dump_stack+0x19/0x1b
[<c018aa7f>] set_dentry_child_flags+0x5a/0x119
[<c018ab94>] remove_watch_no_event+0x56/0x64
[<c018ac62>] inotify_remove_watch_locked+0x12/0x34
[<c018af1b>] inotify_rm_wd+0x75/0x93
[<c018b468>] sys_inotify_rm_watch+0x40/0x58
[<c0102f15>] sysenter_past_esp+0x56/0x8d
kjournald2 starting. Commit interval 5 seconds
>
> Thanks,
> Mingming
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
On 10/08/06, Michal Piotrowski <[email protected]> wrote:
> Hi,
>
> On 10/08/06, Mingming Cao <[email protected]> wrote:
> > This series of patch forkes a new filesystem, ext4, from the current
> > ext3 filesystem, as the code base to work on, for the big features such
> > as extents and larger fs(48 bit blk number) support, per our discussion
> > on lkml a few weeks ago.
>
> It appears after a few minutes of running
>
> #! /bin/bash
> while true
> do
> sudo mount -o loop -t ext3dev /home/fs-farm/ext4.img /mnt/fs-farm/ext4/
> sudo umount /mnt/fs-farm/ext4/
> done
>
> BUG: warning at /usr/src/linux-work2/fs/inotify.c:171/set_dentry_child_flags()
> [<c0104006>] show_trace_log_lvl+0x58/0x152
> [<c01046ad>] show_trace+0xd/0x10
> [<c0104775>] dump_stack+0x19/0x1b
> [<c018aa7f>] set_dentry_child_flags+0x5a/0x119
> [<c018ab94>] remove_watch_no_event+0x56/0x64
> [<c018ac62>] inotify_remove_watch_locked+0x12/0x34
> [<c018af1b>] inotify_rm_wd+0x75/0x93
> [<c018b468>] sys_inotify_rm_watch+0x40/0x58
> [<c0102f15>] sysenter_past_esp+0x56/0x8d
> DWARF2 unwinder stuck at sysenter_past_esp+0x56/0x8d
> Leftover inexact backtrace:
> [<c01046ad>] show_trace+0xd/0x10
> [<c0104775>] dump_stack+0x19/0x1b
> [<c018aa7f>] set_dentry_child_flags+0x5a/0x119
> [<c018ab94>] remove_watch_no_event+0x56/0x64
> [<c018ac62>] inotify_remove_watch_locked+0x12/0x34
> [<c018af1b>] inotify_rm_wd+0x75/0x93
> [<c018b468>] sys_inotify_rm_watch+0x40/0x58
> [<c0102f15>] sysenter_past_esp+0x56/0x8d
> kjournald2 starting. Commit interval 5 seconds
Definitely it's an inotify bug. I have checked this with other file systems.
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
Jeff Garzik wrote:
> Mingming Cao wrote:
>
>> This series of patch forkes a new filesystem, ext4, from the current
>> ext3 filesystem, as the code base to work on, for the big features such
>> as extents and larger fs(48 bit blk number) support, per our discussion
>> on lkml a few weeks ago.
>
> [...]
>
>> Any comments? Could we add ext4/jbd2 to mm tree for a wider testing?
>
>
> ext4 developers should create a git tree with the consensus-accepted
> patches.
>
> That way Linus can pull as soon as the merge window opens, Andrew is
> guaranteed to have the latest in his -mm tree, and users and other
> kernel hackers can easily follow the development without having to
> gather scattered patches from lkml.
>
We do maintain a quilt(akpm) style patches on http://ext2.sf.net, the
latest patches are always at
http://ext2.sourceforge.net/48bitext3/patches/latest/
We thought about doing git initially, still open for that doing do, if
it's more preferable by Linus or Andrew. Just thought it's a lot
easiler for non git user to pull the patches from a project website.
Thanks, Mingming
On Thu, 10 Aug 2006 09:33:04 -0700
Mingming Cao <[email protected]> wrote:
> Jeff Garzik wrote:
> > Mingming Cao wrote:
> >
> >> This series of patch forkes a new filesystem, ext4, from the current
> >> ext3 filesystem, as the code base to work on, for the big features such
> >> as extents and larger fs(48 bit blk number) support, per our discussion
> >> on lkml a few weeks ago.
> >
>
> > [...]
> >
> >> Any comments? Could we add ext4/jbd2 to mm tree for a wider testing?
> >
> >
> > ext4 developers should create a git tree with the consensus-accepted
> > patches.
> >
> > That way Linus can pull as soon as the merge window opens, Andrew is
> > guaranteed to have the latest in his -mm tree, and users and other
> > kernel hackers can easily follow the development without having to
> > gather scattered patches from lkml.
> >
>
> We do maintain a quilt(akpm) style patches on http://ext2.sf.net, the
> latest patches are always at
> http://ext2.sourceforge.net/48bitext3/patches/latest/
>
> We thought about doing git initially, still open for that doing do, if
> it's more preferable by Linus or Andrew. Just thought it's a lot
> easiler for non git user to pull the patches from a project website.
>
We should aim to get the big copy-ext3-to-ext4 patch into Linus's tree as
early as possible.
I'm just not sure when to do that. Immediately after 2.6.19-rc1 is
released would be good because it is when every tree (including -mm) is in
its most-synced-up state.
otoh, we should work out what our processes will be for keeping ext3 and
ext4 in sync wrt bugfixes, cleanups, speedups, etc. If those processes are
good, we can do the copy-n-paste any time. And they need to be good...
On Thu, 2006-10-08 at 17:15 +0200, Michal Piotrowski wrote:
> On 10/08/06, Michal Piotrowski <[email protected]> wrote:
> > Hi,
> >
> > On 10/08/06, Mingming Cao <[email protected]> wrote:
> > > This series of patch forkes a new filesystem, ext4, from the current
> > > ext3 filesystem, as the code base to work on, for the big features such
> > > as extents and larger fs(48 bit blk number) support, per our discussion
> > > on lkml a few weeks ago.
> >
> > It appears after a few minutes of running
> >
> > #! /bin/bash
> > while true
> > do
> > sudo mount -o loop -t ext3dev /home/fs-farm/ext4.img /mnt/fs-farm/ext4/
> > sudo umount /mnt/fs-farm/ext4/
> > done
> >
> > BUG: warning at /usr/src/linux-work2/fs/inotify.c:171/set_dentry_child_flags()
> > [<c0104006>] show_trace_log_lvl+0x58/0x152
> > [<c01046ad>] show_trace+0xd/0x10
> > [<c0104775>] dump_stack+0x19/0x1b
> > [<c018aa7f>] set_dentry_child_flags+0x5a/0x119
> > [<c018ab94>] remove_watch_no_event+0x56/0x64
> > [<c018ac62>] inotify_remove_watch_locked+0x12/0x34
> > [<c018af1b>] inotify_rm_wd+0x75/0x93
> > [<c018b468>] sys_inotify_rm_watch+0x40/0x58
> > [<c0102f15>] sysenter_past_esp+0x56/0x8d
> > DWARF2 unwinder stuck at sysenter_past_esp+0x56/0x8d
> > Leftover inexact backtrace:
> > [<c01046ad>] show_trace+0xd/0x10
> > [<c0104775>] dump_stack+0x19/0x1b
> > [<c018aa7f>] set_dentry_child_flags+0x5a/0x119
> > [<c018ab94>] remove_watch_no_event+0x56/0x64
> > [<c018ac62>] inotify_remove_watch_locked+0x12/0x34
> > [<c018af1b>] inotify_rm_wd+0x75/0x93
> > [<c018b468>] sys_inotify_rm_watch+0x40/0x58
> > [<c0102f15>] sysenter_past_esp+0x56/0x8d
> > kjournald2 starting. Commit interval 5 seconds
>
> Definitely it's an inotify bug. I have checked this with other file systems.
I'm going on vacation today, so I won't be able to look at it for a
while. Right off the bat it seems related to Nick Piggin's patch from
February:
inotify-lock-avoidance-with-parent-watch-status-in-dentry.patch.
--
John McCutchan <[email protected]>
Hi!
> > We do maintain a quilt(akpm) style patches on http://ext2.sf.net, the
> > latest patches are always at
> > http://ext2.sourceforge.net/48bitext3/patches/latest/
> >
> > We thought about doing git initially, still open for that doing do, if
> > it's more preferable by Linus or Andrew. Just thought it's a lot
> > easiler for non git user to pull the patches from a project website.
> >
>
> We should aim to get the big copy-ext3-to-ext4 patch into Linus's tree as
> early as possible.
>
> I'm just not sure when to do that. Immediately after 2.6.19-rc1 is
> released would be good because it is when every tree (including -mm) is in
> its most-synced-up state.
Or you could simply do it _now_. Its new-driver-like, so freeze should
not apply :-).
--
Thanks for all the (sleeping) penguins.
Pavel Machek wrote:
> Hi!
>
>>> We do maintain a quilt(akpm) style patches on http://ext2.sf.net, the
>>> latest patches are always at
>>> http://ext2.sourceforge.net/48bitext3/patches/latest/
>>>
>>> We thought about doing git initially, still open for that doing do, if
>>> it's more preferable by Linus or Andrew. Just thought it's a lot
>>> easiler for non git user to pull the patches from a project website.
>>>
>> We should aim to get the big copy-ext3-to-ext4 patch into Linus's tree as
>> early as possible.
>>
>> I'm just not sure when to do that. Immediately after 2.6.19-rc1 is
>> released would be good because it is when every tree (including -mm) is in
>> its most-synced-up state.
>
> Or you could simply do it _now_. Its new-driver-like, so freeze should
> not apply :-).
I agree... though that is contingent on having _some_ ext4 patches
reviewed and applied.
Jeff
On Thu, 2006-10-08 at 17:15 +0200, Michal Piotrowski wrote:
> On 10/08/06, Michal Piotrowski <[email protected]> wrote:
> > Hi,
> >
> > On 10/08/06, Mingming Cao <[email protected]> wrote:
> > > This series of patch forkes a new filesystem, ext4, from the current
> > > ext3 filesystem, as the code base to work on, for the big features such
> > > as extents and larger fs(48 bit blk number) support, per our discussion
> > > on lkml a few weeks ago.
> >
> > It appears after a few minutes of running
> >
> > #! /bin/bash
> > while true
> > do
> > sudo mount -o loop -t ext3dev /home/fs-farm/ext4.img /mnt/fs-farm/ext4/
> > sudo umount /mnt/fs-farm/ext4/
> > done
> >
> > BUG: warning at /usr/src/linux-work2/fs/inotify.c:171/set_dentry_child_flags()
> > [<c0104006>] show_trace_log_lvl+0x58/0x152
> > [<c01046ad>] show_trace+0xd/0x10
> > [<c0104775>] dump_stack+0x19/0x1b
> > [<c018aa7f>] set_dentry_child_flags+0x5a/0x119
> > [<c018ab94>] remove_watch_no_event+0x56/0x64
> > [<c018ac62>] inotify_remove_watch_locked+0x12/0x34
> > [<c018af1b>] inotify_rm_wd+0x75/0x93
> > [<c018b468>] sys_inotify_rm_watch+0x40/0x58
> > [<c0102f15>] sysenter_past_esp+0x56/0x8d
> > DWARF2 unwinder stuck at sysenter_past_esp+0x56/0x8d
> > Leftover inexact backtrace:
> > [<c01046ad>] show_trace+0xd/0x10
> > [<c0104775>] dump_stack+0x19/0x1b
> > [<c018aa7f>] set_dentry_child_flags+0x5a/0x119
> > [<c018ab94>] remove_watch_no_event+0x56/0x64
> > [<c018ac62>] inotify_remove_watch_locked+0x12/0x34
> > [<c018af1b>] inotify_rm_wd+0x75/0x93
> > [<c018b468>] sys_inotify_rm_watch+0x40/0x58
> > [<c0102f15>] sysenter_past_esp+0x56/0x8d
> > kjournald2 starting. Commit interval 5 seconds
>
> Definitely it's an inotify bug. I have checked this with other file systems.
I just ran your loop of mounting/unmounting a fs for over an hour and I
can't reproduce this.
--
John McCutchan <[email protected]>
On 19/08/06, John McCutchan <[email protected]> wrote:
> On Thu, 2006-10-08 at 17:15 +0200, Michal Piotrowski wrote:
> > On 10/08/06, Michal Piotrowski <[email protected]> wrote:
> > > Hi,
> > >
> > > On 10/08/06, Mingming Cao <[email protected]> wrote:
> > > > This series of patch forkes a new filesystem, ext4, from the current
> > > > ext3 filesystem, as the code base to work on, for the big features such
> > > > as extents and larger fs(48 bit blk number) support, per our discussion
> > > > on lkml a few weeks ago.
> > >
> > > It appears after a few minutes of running
> > >
> > > #! /bin/bash
> > > while true
> > > do
> > > sudo mount -o loop -t ext3dev /home/fs-farm/ext4.img /mnt/fs-farm/ext4/
> > > sudo umount /mnt/fs-farm/ext4/
> > > done
> > >
> > > BUG: warning at /usr/src/linux-work2/fs/inotify.c:171/set_dentry_child_flags()
> > > [<c0104006>] show_trace_log_lvl+0x58/0x152
> > > [<c01046ad>] show_trace+0xd/0x10
> > > [<c0104775>] dump_stack+0x19/0x1b
> > > [<c018aa7f>] set_dentry_child_flags+0x5a/0x119
> > > [<c018ab94>] remove_watch_no_event+0x56/0x64
> > > [<c018ac62>] inotify_remove_watch_locked+0x12/0x34
> > > [<c018af1b>] inotify_rm_wd+0x75/0x93
> > > [<c018b468>] sys_inotify_rm_watch+0x40/0x58
> > > [<c0102f15>] sysenter_past_esp+0x56/0x8d
> > > DWARF2 unwinder stuck at sysenter_past_esp+0x56/0x8d
> > > Leftover inexact backtrace:
> > > [<c01046ad>] show_trace+0xd/0x10
> > > [<c0104775>] dump_stack+0x19/0x1b
> > > [<c018aa7f>] set_dentry_child_flags+0x5a/0x119
> > > [<c018ab94>] remove_watch_no_event+0x56/0x64
> > > [<c018ac62>] inotify_remove_watch_locked+0x12/0x34
> > > [<c018af1b>] inotify_rm_wd+0x75/0x93
> > > [<c018b468>] sys_inotify_rm_watch+0x40/0x58
> > > [<c0102f15>] sysenter_past_esp+0x56/0x8d
> > > kjournald2 starting. Commit interval 5 seconds
> >
> > Definitely it's an inotify bug. I have checked this with other file systems.
>
> I just ran your loop of mounting/unmounting a fs for over an hour and I
> can't reproduce this.
I can reproduce this in a few minutes.
ls -sh /home/fs-farm/
razem 3,6G
513M ext2.img 513M ext4.img 513M reiser3.img 513M xfs.img
513M ext3.img 513M jfs.img 513M reiser4.img
#! /bin/bash
m_fs() {
sudo mount -o loop -t ext2 /home/fs-farm/ext2.img /mnt/fs-farm/ext2/
sudo mount -o loop -t ext3 /home/fs-farm/ext3.img /mnt/fs-farm/ext3/
sudo mount -o loop -t ext3dev /home/fs-farm/ext4.img /mnt/fs-farm/ext4/
sudo mount -o loop -t reiserfs /home/fs-farm/reiser3.img
/mnt/fs-farm/reiser3/
sudo mount -o loop -t reiser4 /home/fs-farm/reiser4.img
/mnt/fs-farm/reiser4/
sudo mount -o loop -t xfs /home/fs-farm/xfs.img /mnt/fs-farm/xfs/
sudo mount -o loop -t jfs /home/fs-farm/jfs.img /mnt/fs-farm/jfs/
}
u_fs() {
sudo umount /mnt/fs-farm/ext2/
sudo umount /mnt/fs-farm/ext3/
sudo umount /mnt/fs-farm/ext4/
sudo umount /mnt/fs-farm/reiser3/
sudo umount /mnt/fs-farm/reiser4/
sudo umount /mnt/fs-farm/xfs/
sudo umount /mnt/fs-farm/jfs/
}
while true
do
m_fs
u_fs
done
mount
[..]
/dev/sda3 on /home type ext3 (rw)
http://www.stardust.webpages.pl/files/o_bugs/mm-config
>
> --
> John McCutchan <[email protected]>
>
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)