[Ocfs2-devel] What's your opinion on the patch to fix bug 58 for kernel 2.6 porting?

[Ocfs2-devel] What's your opinion on the patch to fix bug 58 for kernel 2.6 porting?

[Zhang, Sonic]

Hi Mark,

	Do you have any opinion on the patch to fix bug 58 for kernel
2.6 porting?
	Could you add the patch into the source tree? 

	Thank you.


*********************************************
Sonic Zhang
Software Engineer
Intel China Software Lab
Tel: (086)021-52574545-1667
iNet: 752-1667
********************************************* 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ocfs2-inode-count.patch
Type: application/octet-stream
Size: 2910 bytes
Desc: ocfs2-inode-count.patch
Url : http://oss.oracle.com/pipermail/ocfs2-devel/attachments/20040429/445ff5c9/ocfs2-inode-count.obj

[Ocfs2-devel] What's your opinion on the patch to fix bug 58 for kernel 2.6 porting?

[Mark Fasheh]

Well, to be perfectly honest I don't think this is the right solution.
Instead of peppering the code with signal stuff, why not try to figure out
what the timing issue is (it seems that the umount thread should wait on
pending operations) and fix it that way?
	--Mark

On Thu, Apr 29, 2004 at 10:10:56AM +0800, Zhang, Sonic wrote:
> Hi Mark,
> 
> 	Do you have any opinion on the patch to fix bug 58 for kernel
> 2.6 porting?
> 	Could you add the patch into the source tree? 
> 
> 	Thank you.
> 
> 
> *********************************************
> Sonic Zhang
> Software Engineer
> Intel China Software Lab
> Tel: (086)021-52574545-1667
> iNet: 752-1667
> ********************************************* 
> 


> _______________________________________________
> Ocfs2-devel mailing list
> Ocfs2-devel@oss.oracle.com
> http://oss.oracle.com/mailman/listinfo/ocfs2-devel

--
Mark Fasheh
Software Developer, Oracle Corp
mark.fasheh@oracle.com

[Ocfs2-devel] What's your opinion on the patch to fix bug 58 for kernel 2.6 porting?

[Zhang, Sonic]

Hi Mark,

	In kernel 2.6 VFS routine sys_umount()->...->generic_shutdown_super(), =
if the inode usage count i_count is not 0, error information is =
reported. Then, the system will halt in routine =
kill_bdev()->truncate_inode_pages().
	If we don't fix it in OCFS2 driver, we have to change the kernel 2.6 =
VFS sys_umount code. Is it a good solution?

	Thanks.


*********************************************
Sonic Zhang
Software Engineer
Intel China Software Lab
Tel: (086)021-52574545-1667
iNet: 752-1667
*********************************************=20

-----Original Message-----
From: Mark Fasheh [mailto:mark.fasheh@oracle.com]=20
Sent: 2004=C4=EA4=D4=C230=C8=D5 1:32
To: Zhang, Sonic
Cc: Ocfs2-Devel
Subject: Re: [Ocfs2-devel] What's your opinion on the patch to fix bug =
58 for kernel 2.6 porting?

Well, to be perfectly honest I don't think this is the right solution.
Instead of peppering the code with signal stuff, why not try to figure =
out
what the timing issue is (it seems that the umount thread should wait on
pending operations) and fix it that way?
	--Mark

On Thu, Apr 29, 2004 at 10:10:56AM +0800, Zhang, Sonic wrote:
> Hi Mark,
>=20
> 	Do you have any opinion on the patch to fix bug 58 for kernel
> 2.6 porting?
> 	Could you add the patch into the source tree?=20
>=20
> 	Thank you.
>=20
>=20
> *********************************************
> Sonic Zhang
> Software Engineer
> Intel China Software Lab
> Tel: (086)021-52574545-1667
> iNet: 752-1667
> *********************************************=20
>=20


> _______________________________________________
> Ocfs2-devel mailing list
> Ocfs2-devel@oss.oracle.com
> http://oss.oracle.com/mailman/listinfo/ocfs2-devel

--
Mark Fasheh
Software Developer, Oracle Corp
mark.fasheh@oracle.com

[Ocfs2-devel] What's your opinion on the patch to fix bug 58 for kernel 2.6 porting?

[Joel Becker]

On Fri, Apr 30, 2004 at 09:19:19AM +0800, Zhang, Sonic wrote:
> 	In kernel 2.6 VFS routine sys_umount()->...->generic_shutdown_super(), if the inode usage count i_count is not 0, error information is reported. Then, the system will halt in routine kill_bdev()->truncate_inode_pages().
> 	If we don't fix it in OCFS2 driver, we have to change the kernel 2.6 VFS sys_umount code. Is it a good solution?

	The issue is not whether to fix it in the OCFS2 driver.  The
issue is solving the problem without resorting to ugly stuff like
signals.
	Can you provide a complete description of what happens to cause
the problem, so we can look at it?

Joel

-- 

"Depend on the rabbit's foot if you will, but remember, it didn't
 help the rabbit."
	- R. E. Shay

Joel Becker
Senior Member of Technical Staff
Oracle Corporation
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

[Ocfs2-devel] What's your opinion on the patch to fix bug 58 for kernel 2.6 porting?

[Zhang, Sonic]

Hi,

	OK, see below.

This bug occurs only when unmount a volume immediately after =
open/read/write/close files.

Bug 58 details.
http://oss.oracle.com/bugzilla/show_bug.cgi?id=3D58

Steps: (done in one bash script)
1. load_ocfs2
2. mount /dev/hda4 /ocfs
3. write and read files in /ocfs.
4. close files.
5. umount /ocfs immediately=20

Results:
System halts with error information.
VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice =
day...


Possible Cause:
	This error information is printed out in kernel 2.6 VFS routine =
generic_shutdown_super() after the second call to invalidate_inodes(). =
In invalidate_inodes(), only inodes with 0 usage count are added to the =
dispose list. And the ocfs_clear_inode(), which lead to =
ocfs_dismount_volume(), is only invoked for those inodes in the dispose =
list.=20

	In ocfs2 after svn version 847, ocfs_clear_inodes() is not invoked if =
unmount a volume immediately after open/read/write/close files, because =
the inode usage counts of the OCFS2 volume are not 0. The i_count isn't =
decreased in function ocfs_file_release() until the journal lock is =
released in ocfs_commit_thread().

	I remember that this change is adopted to avoid the =
ocfs_commit_thread() to access invalid inode referenced in journal lock. =
Am I right?

	In order to fix this bug, I think we have 2 approaches.=20
	One is to keep the mnt_count in struct vfsmount larger than 2 before =
the all inode usage counters are decreased to 0. The other is to =
decrease all inode usage counters before invalide_inodes() is called. =
This can be done in ocfs_put_super(), which is invoked just before the =
second call to invalidate_inodes().

	Any suggestion?
	Thank you.


*********************************************
Sonic Zhang
Software Engineer
Intel China Software Lab
Tel: (086)021-52574545-1667
iNet: 752-1667
*********************************************=20

-----Original Message-----
From: joel.becker@oracle.com [mailto:joel.becker@oracle.com]=20
Sent: 2004=C4=EA5=D4=C21=C8=D5 0:53
To: Zhang, Sonic
Cc: Mark Fasheh; Ocfs2-Devel
Subject: Re: [Ocfs2-devel] What's your opinion on the patch to fix bug =
58 for kernel 2.6 porting?

On Fri, Apr 30, 2004 at 09:19:19AM +0800, Zhang, Sonic wrote:
> 	In kernel 2.6 VFS routine =
sys_umount()->...->generic_shutdown_super(), if the inode usage count =
i_count is not 0, error information is reported. Then, the system will =
halt in routine kill_bdev()->truncate_inode_pages().
> 	If we don't fix it in OCFS2 driver, we have to change the kernel 2.6 =
VFS sys_umount code. Is it a good solution?

	The issue is not whether to fix it in the OCFS2 driver.  The
issue is solving the problem without resorting to ugly stuff like
signals.
	Can you provide a complete description of what happens to cause
the problem, so we can look at it?

Joel

--=20

"Depend on the rabbit's foot if you will, but remember, it didn't
 help the rabbit."
	- R. E. Shay

Joel Becker
Senior Member of Technical Staff
Oracle Corporation
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127