[PATCH 0/5] Forking ext4 filesystem and JBD2

[PATCH 0/5] Forking ext4 filesystem and JBD2

[Mingming Cao]

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

Re: [PATCH 0/5] Forking ext4 filesystem and JBD2

[Jeff Garzik]

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

Re: [PATCH 0/5] Forking ext4 filesystem and JBD2

[Mingming Cao]

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

Re: [PATCH 0/5] Forking ext4 filesystem and JBD2

[Andrew Morton]

On Thu, 10 Aug 2006 09:33:04 -0700
Mingming Cao <cmm@us.ibm.com> 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...

Re: [PATCH 0/5] Forking ext4 filesystem and JBD2

[Andrew Morton]

On Thu, 10 Aug 2006 09:33:04 -0700
Mingming Cao <cmm@us.ibm.com> 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...

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: [PATCH 0/5] Forking ext4 filesystem and JBD2

[Pavel Machek]

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.

Re: [PATCH 0/5] Forking ext4 filesystem and JBD2

[Jeff Garzik]

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

Re: [PATCH 0/5] Forking ext4 filesystem and JBD2

[Michal Piotrowski]

Hi,

On 10/08/06, Mingming Cao <cmm@us.ibm.com> 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/)

Re: [PATCH 0/5] Forking ext4 filesystem and JBD2

[Michal Piotrowski]

On 10/08/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> Hi,
>
> On 10/08/06, Mingming Cao <cmm@us.ibm.com> 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/)

Re: [PATCH 0/5] Forking ext4 filesystem and JBD2

[Michal Piotrowski]

On 10/08/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> Hi,
>
> On 10/08/06, Mingming Cao <cmm@us.ibm.com> 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/)

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: [PATCH 0/5] Forking ext4 filesystem and JBD2

[John McCutchan]

On Thu, 2006-10-08 at 17:15 +0200, Michal Piotrowski wrote:
> On 10/08/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> > Hi,
> >
> > On 10/08/06, Mingming Cao <cmm@us.ibm.com> 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 <john@johnmccutchan.com>

Re: [PATCH 0/5] Forking ext4 filesystem and JBD2

[John McCutchan]

On Thu, 2006-10-08 at 17:15 +0200, Michal Piotrowski wrote:
> On 10/08/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> > Hi,
> >
> > On 10/08/06, Mingming Cao <cmm@us.ibm.com> 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 <john@johnmccutchan.com>

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: [PATCH 0/5] Forking ext4 filesystem and JBD2

[John McCutchan]

On Thu, 2006-10-08 at 17:15 +0200, Michal Piotrowski wrote:
> On 10/08/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> > Hi,
> >
> > On 10/08/06, Mingming Cao <cmm@us.ibm.com> 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 <john@johnmccutchan.com>

Re: [PATCH 0/5] Forking ext4 filesystem and JBD2

[John McCutchan]

On Thu, 2006-10-08 at 17:15 +0200, Michal Piotrowski wrote:
> On 10/08/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> > Hi,
> >
> > On 10/08/06, Mingming Cao <cmm@us.ibm.com> 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 <john@johnmccutchan.com>

Re: [PATCH 0/5] Forking ext4 filesystem and JBD2

[John McCutchan]

On Thu, 2006-10-08 at 17:15 +0200, Michal Piotrowski wrote:
> On 10/08/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> > Hi,
> >
> > On 10/08/06, Mingming Cao <cmm@us.ibm.com> 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 <john@johnmccutchan.com>

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: [PATCH 0/5] Forking ext4 filesystem and JBD2

[John McCutchan]

On Thu, 2006-10-08 at 17:15 +0200, Michal Piotrowski wrote:
> On 10/08/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> > Hi,
> >
> > On 10/08/06, Mingming Cao <cmm@us.ibm.com> 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 <john@johnmccutchan.com>

Re: [PATCH 0/5] Forking ext4 filesystem and JBD2

[Michal Piotrowski]

On 19/08/06, John McCutchan <john@johnmccutchan.com> wrote:
> On Thu, 2006-10-08 at 17:15 +0200, Michal Piotrowski wrote:
> > On 10/08/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> > > Hi,
> > >
> > > On 10/08/06, Mingming Cao <cmm@us.ibm.com> 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 <john@johnmccutchan.com>
>

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

Re: [PATCH 0/5] Forking ext4 filesystem and JBD2

[Michal Piotrowski]

On 19/08/06, John McCutchan <john@johnmccutchan.com> wrote:
> On Thu, 2006-10-08 at 17:15 +0200, Michal Piotrowski wrote:
> > On 10/08/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> > > Hi,
> > >
> > > On 10/08/06, Mingming Cao <cmm@us.ibm.com> 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 <john@johnmccutchan.com>
>

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642