Skip to contentSkip to conversation

Forking ext4 filesystem and JBD2

PATCH In review Mingming Cao 6 participants 15 messages Aug 10, 2006 – Aug 19, 2006 VFS

lore
Share & tools
lore
#0 lore raw

cover Forking ext4 filesystem and JBD2

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

#1 lore raw
Quoted 4 lines · 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.

[...]

Quoted 1 line

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

#2 lore raw
Quoted 8 lines · Jeff Garzik
Quoted 4 lines · 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.

Quoted 9 lines

[...]

Quoted 1 line

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

#3 lore raw
Quoted 23 lines · On Thu, 10 Aug 2006 09:33:04 -0700 Mingming Cao <[email protected]> wrote:
Quoted 13 lines · Jeff Garzik
Quoted 4 lines · 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.

[...]

Quoted 1 line

Any comments? Could we add ext4/jbd2 to mm tree for a wider testing?

Quoted 8 lines

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.

Quoted 8 lines

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

#4 lore raw

Hi!

Quoted 9 lines
Quoted 8 lines

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.

Quoted 6 lines

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 :-).

Signature · 1 line
Thanks for all the (sleeping) penguins.
#5 lore raw
Quoted 9 lines · Pavel Machek

Hi!

Quoted 7 lines
Quoted 4 lines

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.

Quoted 6 lines
Quoted 3 lines

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

#6 lore raw
In reply to Mingming Cao

Hi,

Quoted 4 lines · 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.

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

Quoted 3 lines

Thanks,
Mingming

Regards,
Michal

Signature · 3 lines
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
#7 lore raw
Quoted 37 lines · Michal Piotrowski

Hi,

Quoted 4 lines · 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.

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
Quoted 1 line

kjournald2 starting. Commit interval 5 seconds

Definitely it's an inotify bug. I have checked this with other file systems.

Regards,
Michal

Signature · 9 lines
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
#8 lore raw
Quoted 40 lines · Michal Piotrowski
Quoted 37 lines · Michal Piotrowski

Hi,

Quoted 4 lines · 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.

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
Quoted 1 line

kjournald2 starting. Commit interval 5 seconds

Quoted 1 line

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.

Signature · 7 lines
John McCutchan <[email protected]>

-------------------------------------------------------------------------
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
#9 lore raw
In reply to Michal Piotrowski
Quoted 40 lines · Michal Piotrowski
Quoted 37 lines · Michal Piotrowski

Hi,

Quoted 4 lines · 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.

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
Quoted 1 line

kjournald2 starting. Commit interval 5 seconds

Quoted 1 line

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.

Signature · 1 line
John McCutchan <[email protected]>
#10 lore raw
In reply to Michal Piotrowski
Quoted 40 lines · Michal Piotrowski
Quoted 37 lines · Michal Piotrowski

Hi,

Quoted 4 lines · 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.

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
Quoted 1 line

kjournald2 starting. Commit interval 5 seconds

Quoted 1 line

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.

Signature · 1 line
John McCutchan <[email protected]>
#11 lore raw
In reply to Michal Piotrowski
Quoted 40 lines · Michal Piotrowski
Quoted 37 lines · Michal Piotrowski

Hi,

Quoted 4 lines · 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.

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
Quoted 1 line

kjournald2 starting. Commit interval 5 seconds

Quoted 1 line

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.

Signature · 1 line
John McCutchan <[email protected]>
#12 lore raw
In reply to Michal Piotrowski
Quoted 40 lines · Michal Piotrowski
Quoted 37 lines · Michal Piotrowski

Hi,

Quoted 4 lines · 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.

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
Quoted 1 line

kjournald2 starting. Commit interval 5 seconds

Quoted 1 line

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.

Signature · 7 lines
John McCutchan <[email protected]>

-------------------------------------------------------------------------
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
#13 lore raw
In reply to Michal Piotrowski
Quoted 40 lines · Michal Piotrowski
Quoted 37 lines · Michal Piotrowski

Hi,

Quoted 4 lines · 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.

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
Quoted 1 line

kjournald2 starting. Commit interval 5 seconds

Quoted 1 line

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.

Signature · 1 line
John McCutchan <[email protected]>
#14 lore raw
Quoted 41 lines · John McCutchan
Quoted 40 lines · Michal Piotrowski
Quoted 38 lines · Michal Piotrowski

Hi,

Quoted 4 lines · 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.

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

Quoted 4 lines
Quoted 1 line

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

Quoted 4 lines

--
John McCutchan <[email protected]>

Regards,
Michal

Signature · 9 lines
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