Menu
▾
▴
[coLinux-devel] [ colinux-Bugs-1555961 ] Colinux thrashes on boot
|
From: SourceForge.net <no...@so...> - 2007-01-04 03:51:59
|
Bugs item #1555961, was opened at 2006-09-10 17:07 Message generated for change (Comment added) made by bvoigt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=1555961&group_id=98788 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andrew Tonner (rakslice) Assigned to: Nobody/Anonymous (nobody) Summary: Colinux thrashes on boot Initial Comment: I'm having a problem with colinux thrashing the disk on launch. I'm running colinux 0.6.4-linux-2.6.11, and I've got it set up with debian install on a reiserfs image on cobd0 (made by "cp -ax"ing the colinux stock debian image after installing the reiserfs utils to it). When I start my colinux setup it usually gets as far as: [... snip ...] NET: Registered protocol family 1 NET: Registered protocol family 17 ReiserFS: cobd0: found reiserfs format "3.6" with standard journal ReiserFS: cobd0: using ordered data mode ReiserFS: cobd0: journal params: device cobd0, size 8192, journal first block 18 , max trans len 1024, max batch 900, ReiserFS: cobd0: checking transaction log ( cobd0) and sits there hitting the disk for several minutes before continuing. If I force kill the colinux-daemon process while it's doing this (taskkill /im colinux-daemon.exe /f), it doesn't die for several minutes (i.e. the amount of time usually spent thrashing) presumably because it's blocked on a huge IO operation. But it doesn't always do this... Sometimes it boots without unusual disk activity, especially on subsequent colinux launches before I restart windows again. (That could just be the effects of disk caching in windows, but I'm not sure.) This behaviour happens on both the systems I've tried colinux on: my dual core athlon 64 X2 nforce 4 box at work, and my athlon XP 2500 nforce 2 box at home. On my work box, the cobd0 image is 20GB (21474836480 bytes); the one on my home box is substantially smaller, (~8GB IIRC -- I don't have it handy right now.) ---------------------------------------------------------------------- Comment By: Ben Voigt (bvoigt) Date: 2007-01-03 22:51 Message: Logged In: YES user_id=782364 Originator: NO reiserfs, being a journalled filesystem, usually checks itself very quickly. However, by default every 20th boot it forces a full check. The frequency of checks can be changed in the reiser metadata... but looking at reiserfstune I can't find the command for it right now. ---------------------------------------------------------------------- Comment By: Andrew Tonner (rakslice) Date: 2007-01-03 20:06 Message: Logged In: YES user_id=39760 Originator: YES I've gone through this sequence of checks, and fsck never encounters any file system errors, and except for the occasional thrashing for several minutes when I mount a reiserfs volume nothing unusual happens. ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2006-09-13 13:23 Message: Logged In: YES user_id=579204 It can be a limit in one of the block operations from colinux. Please can you boot from an other image. For sample from the small Debian, ArchLinux or Fedora. Than check the image without mount, with the reiser tools. I'm not know the tool, it is like "fsck.ext3 -f /dev/cobd1" for an ext3 system. Than mount this device, unmount it, check again. Than mount it, write down some, umount it, check again. An totaly other idea: I'm afraid, that your shutting down don't complete your reiser umount. Please try to go into runlevel S (single user mode without network). Check, that no other task are running and not task shoult need write access to your roor filesystem. Than do this command sequence "sync; sleep 1; sync; sleep 3; mount -o remount ro /" The umount should no give an error. Now check your root file system device with reiser tools. If it was clean, shutdown your system and run it again. This helps? ---------------------------------------------------------------------- Comment By: Andrew Tonner (rakslice) Date: 2006-09-12 13:05 Message: Logged In: YES user_id=39760 I had sort of assumed that even kernel space IO happening on the linux side wouldn't cause the colinux-daemon process to block for IO like this. But I don't know the internals so I guess I should stop making assumptions like that. =) Still, other things suggest to me that it's not a resierfs journal replay: - According to the messages by time the read is happening, the system hasn't got the part where the journal replay should happen yet AFAIK - I fired up Sysinternals' FileMon, and the disk activity is colinux-daemon doing a series of consecutive (in terms of offsets) 64k IRP_MJ_READs. FileMon doesn't show the target of the reads (it just gives C:) but it must be the volume file, judging by the eventually huge offsets (I don't have any other files that big) and the fact that the last read before colinux continues is right at 20GB (the last read offset & size lines up with the volume file end position)... unless its reading something other than a file. - Also this behaviour happens even when the the last run of colinux was one that worked fine and was shutdown normally with halt or shutdown. ---------------------------------------------------------------------- Comment By: George P Boutwell (gboutwel) Date: 2006-09-10 20:40 Message: Logged In: YES user_id=30412 Sounds like there is some big disk operation going on in coLinux, I don't know what that operation is (perhaps coLinux didn't get shutdown correctly & reiserfs is trying to replay a long journal?), but you should probably leave it to complete, instead of trying to kill it. Make sure that you are shutting down coLinux, by logging in and running a proper linux shutdown command (halt, poweroff, shutdown -h now, etc) and not just 'killing' coLinux processes. ---------------------------------------------------------------------- Comment By: Andrew Tonner (rakslice) Date: 2006-09-10 17:09 Message: Logged In: YES user_id=39760 I should mention that I've removed the initrd section from my configuration file in case this bug is somehow related to the known problem with that, but this problem didn't go away. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=1555961&group_id=98788 |