On Wed, 2007-09-19 at 14:18 +0200, Oliver Neukum wrote:
> Am Samstag 08 September 2007 schrieb Dave Kleikamp:
> > On Fri, 2007-09-07 at 11:52 +0200, Oliver Neukum wrote:
> > > Am Donnerstag 06 September 2007 schrieb Christian Kujau:
> > > > On Tue, 4 Sep 2007, Oliver Neukum wrote:
> > > > > using jfs on a flash drive (which is a bit unusual: 2K sectors)
> > > > > unmounting
> > > > > triggers a warning and takes 52 second, if I have used the
> > > > > filesystem. (ls -l)
> > > > > is sufficient. This is 2.6.23-rc4 on x86_64.
> >
> > I'm not really sure there's a good reason to have jfs on flash. You
> > would probably be better off with jffs2. However, I do want to
>
> This is a usb storage device. The fs has no idea it is on flash.
> A real disk would have the same effect.
>
> > understand what's going on here and figure out how to fix it.
> >
> > > > Hm, the fs/jfs/jfs_logmgr.c changes in -rc5 were only whitespace
> > > > cleanup, so may not be worth a try.
> > >
> > > 2.6.23-rc5 with JFS_DEBUG:
> > >
> > > the first try works without error, on the second attempt to mount:
> > >
> > > oenone:/var/log # tail -2500 /var/log/messages |grep jfs
> > > Sep 7 11:50:25 oenone kernel: jfs_mount: diMount(ipaimap2) failed, rc =
> > > -5
> > > Sep 7 11:50:25 oenone kernel: jfs_mount failed w/return code = -5
>
> Sep 19 14:13:04 oenone kernel: jfs_flush_journal: synclist not empty
> Sep 19 14:13:04 oenone kernel: metapage: ffff810063ae57b8: 0e161000 00000000
> 000036a0 00002ae6
> Sep 19 14:13:04 oenone kernel: metapage: ffff810063ae57c8: 508e7f00 ffff8100
> 508e7f00 ffff8100
> Sep 19 14:13:04 oenone kernel: metapage: ffff810063ae57d8: 00000004 00000000
> 00000000 00000000
> Sep 19 14:13:04 oenone kernel: metapage: ffff810063ae57e8: 63ad9000 ffff8100
> 00000055 00000000
> Sep 19 14:13:04 oenone kernel: metapage: ffff810063ae57f8: 00000001 00002ae6
> 63ae5800 ffff8100
> Sep 19 14:13:04 oenone kernel: metapage: ffff810063ae5808: 63ae5800 ffff8100
> 9f28df78 ffff8100
> Sep 19 14:13:04 oenone kernel: metapage: ffff810063ae5818: 00001000 0000376c
> 00000000 00002ae6
> Sep 19 14:13:04 oenone kernel: metapage: ffff810063ae5828: 508e7e00 ffff8100
> Sep 19 14:13:04 oenone kernel: page: ffff81009f28df78: 010000000000087c
> ffffffff00000001
> Sep 19 14:13:04 oenone kernel: page: ffff81009f28df88: ffff810063ae57b8
> ffff810063ae3e28
> Sep 19 14:13:04 oenone kernel: page: ffff81009f28df98: 0000000000000055
> ffff81009f28df68
> Sep 19 14:13:04 oenone kernel: page: ffff81009f28dfa8: ffff81009fc79790
>
> Again, this happens on the second umount.
It looks like there is a dirty page on the sync list that doesn't get
written. I see a possible case were we try to write the page, but it
can't be written do to an uncommitted transaction, and we never try to
write it again. This code hasn't changed in ages, so I can only imagine
that the timing of writing to flash, coupled with some kernel change
opened a race window that we hadn't seen before. Would you be able to
try this patch?
-------------------------------------------------------------------
JFS: Make sure special inode data is written after journal is flushed
This patch makes sure that data that we tried to flush before the journal
was completely written actually gets pushed to disk.
To avoid duplicating code, moved common code to write_special_inodes().
Signed-off-by: Dave Kleikamp <[EMAIL PROTECTED]>
diff --git a/fs/jfs/jfs_logmgr.c b/fs/jfs/jfs_logmgr.c
index de3e4a5..971f44a 100644
--- a/fs/jfs/jfs_logmgr.c
+++ b/fs/jfs/jfs_logmgr.c
@@ -208,6 +208,17 @@ static struct lmStat {
} lmStat;
#endif
+static void write_special_inodes(struct jfs_log *log,
+ int (*writer)(struct address_space *))
+{
+ struct jfs_sb_info *sbi;
+
+ list_for_each_entry(sbi, &log->sb_list, log_list) {
+ writer(sbi->ipbmap->i_mapping);
+ writer(sbi->ipimap->i_mapping);
+ writer(sbi->direct_inode->i_mapping);
+ }
+}
/*
* NAME: lmLog()
@@ -935,22 +946,13 @@ static int lmLogSync(struct jfs_log * log, int hard_sync)
struct lrd lrd;
int lsn;
struct logsyncblk *lp;
- struct jfs_sb_info *sbi;
unsigned long flags;
/* push dirty metapages out to disk */
if (hard_sync)
- list_for_each_entry(sbi, &log->sb_list, log_list) {
- filemap_fdatawrite(sbi->ipbmap->i_mapping);
- filemap_fdatawrite(sbi->ipimap->i_mapping);
- filemap_fdatawrite(sbi->direct_inode->i_mapping);
- }
+ write_special_inodes(log, filemap_fdatawrite);
else
- list_for_each_entry(sbi, &log->sb_list, log_list) {
- filemap_flush(sbi->ipbmap->i_mapping);
- filemap_flush(sbi->ipimap->i_mapping);
- filemap_flush(sbi->direct_inode->i_mapping);
- }
+ write_special_inodes(log, filemap_flush);
/*
* forward syncpt
@@ -1536,7 +1538,6 @@ void jfs_flush_journal(struct jfs_log *log, int wait)
{
int i;
struct tblock *target = NULL;
- struct jfs_sb_info *sbi;
/* jfs_write_inode may call us during read-only mount */
if (!log)
@@ -1598,11 +1599,7 @@ void jfs_flush_journal(struct jfs_log *log, int wait)
if (wait < 2)
return;
- list_for_each_entry(sbi, &log->sb_list, log_list) {
- filemap_fdatawrite(sbi->ipbmap->i_mapping);
- filemap_fdatawrite(sbi->ipimap->i_mapping);
- filemap_fdatawrite(sbi->direct_inode->i_mapping);
- }
+ write_special_inodes(log, filemap_fdatawrite);
/*
* If there was recent activity, we may need to wait
@@ -1611,6 +1608,7 @@ void jfs_flush_journal(struct jfs_log *log, int wait)
if ((!list_empty(&log->cqueue)) || !list_empty(&log->synclist)) {
for (i = 0; i < 200; i++) { /* Too much? */
msleep(250);
+ write_special_inodes(log, filemap_fdatawrite);
if (list_empty(&log->cqueue) &&
list_empty(&log->synclist))
break;
>
> > Does fsck find any errors?
>
> fsck 1.40.2 (12-Jul-2007)
> fsck.jfs version 1.1.11, 05-Jun-2006
> processing started: 9/19/2007 14.17.38
> Using default parameter: -p
> The current device is: /dev/sdd1
> Block size in bytes: 4096
> Filesystem size in blocks: 474269
> **Phase 0 - Replay Journal Log
> Filesystem is clean.
>
> Regards
> Oliver
--
David Kleikamp
IBM Linux Technology Center
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jfs-discussion mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jfs-discussion
