search for: fsync_dev

Rebooting to try 2.4.7-ac4, I had Xfree86 crash on exit and hang the machine (it does that once a month or so; this notebook gets booted quite often). After fscking the root and another ext2 partition, the system got to the big ext3 partition and just went dead. No message, no disk activity, no keyboard response. I powered down and rebooted 2.4.7-ac3 patched with ext3-2.4-0.9.5-247ac3, and that

...he above a bit ago, except he uses bh->b_jlist == BJ_None. buffer_journaled() seems to be a function in fs.h which seems a bit more appropriate. Next, with the above we'd still see problems. My next patch included a suggestion from Heinz to add lock_kernel() and unlock_kernel() around the fsync_dev() and invalidate_buffers() in lvm.c/lvm_do_pv_flush(). Currently I have this in my working kernel, I'm gonna try again without it though, it seems that it shouldn't be necessary, the other block devices I've looked at don't seem to lock the kernel. Lastly, I was still getting an as...

...ctures thanks to "read_dqblk". At the same time, "sync" is running: sync Call Trace: [__down+109/208] [__down_failed+8/12] [.text.lock.dquot+73/286] [ext3_sync_dquot+337/462] [vfs_quota_sync+102/372] [sync_dquots_dev+194/260] [fsync_dev+66/128] [sys_sync+7/16] [system_call+51/56] and has started an ext3 transaction (in ext3_sync_dquot) and is trying to get the lock that rquotad has. Presumably the transaction that sync has started is keeping t_updates greater than 0, thus preventing kjournald from progressing, and this preventi...

...a new patch against 2.4.8-pre8, updated to Al's new super > handling. The differences between the original are small, > but they are big enough that I want extra testing from the > LVM guys (and ext3/XFS). ext3 will probably lock up on unmount with 2.4.8-pre8. The fix is to replace fsync_dev with fsync_no_super in fs/ext3/super.c and fs/jbd/recovery.c. I'll be generating a new patchset this weekend. -

> ext3 will probably lock up on unmount with 2.4.8-pre8. The fix is > to replace fsync_dev with fsync_no_super in fs/ext3/super.c and > fs/jbd/recovery.c. I'll be generating a new patchset this weekend. Actually if you dont fix recovery.c it will hang the machine when you mount an fs that needs recovering. With the old patches at least umount of ext3 seems fine as is. Alan

Patch against linux-2.4.8 is at http://www.uow.edu.au/~andrewm/linux/ext3/ The only changes here are merging up to 2.4.8 and the bigendian fix. linux-2.4.8-ac1 currently has ext3-0.9.3 which has no known crash-worthy bugs, but is old. I'm about to send Alan a diff which takes -ac up to 0.9.6. The changes between 0.9.3 and 0.9.6 may be summarised as: - Simplify the handling of

..._block *sb) lock_super(sb); if (sb->s_dirt && sb->s_op && sb->s_op->write_super) sb->s_op->write_super(sb); + if (sb->s_op && sb->s_op->sync_fs) + sb->s_op->sync_fs(sb); unlock_super(sb); unlock_kernel(); @@ -346,7 +348,7 @@ int fsync_dev(kdev_t dev) lock_kernel(); sync_inodes(dev); DQUOT_SYNC(dev); - sync_supers(dev); + sync_supers(dev, 1); unlock_kernel(); return sync_buffers(dev, 1); @@ -2833,7 +2835,7 @@ static int sync_old_buffers(void) { lock_kernel(); sync_unlocked_inodes(); - sync_supers(0); + sync_supers(0,...

When I copy a file(13Megs) from /home/ to /tmp/, sync takes almost 2 minutes. When I copy the same file to /usr/local/, sync returns almost right away. Both filesystems are ext3 and are on the same harddrive. When sync is running, the harddrive light stays on but I don't hear it doing anything. dmesg doesn't show any errors either. Below is the `time` output for each command. If you