![]() I thought the behaviour might be by design at first too, but I don't think it is because: 1. After I did this I was thinking maybe the issue was limited to stage 4 of chkdsk, but I took a 500GB drive I have that is about half full and ran chkdsk /f, and the memory usage got to 1.7GB before it completed. Could chkdsk possibly be trying to load all the files on the disk into memory and then failing to unload them? The memory usage hits its peak once stage 4 completes, and it does not increase at all during stage 5. Well, I did a little more testing and this is what I found: (tests are all done on the same 32GB USB flash drive I have been using throughout) Filesystem - disk space used - chkdsk memory usage (maximum level reached during chkdsk /r) - exfat - 0 - 5408k exfat - 1.42GB - 5416k fat32 - 0 - 10,284k fat32 - 1.42GB - 10,336k ntfs - 0 - 23,712k ntfs - 1.42GB - 1,431,192k ntfs - 2.54GB - 2,610,344k (if anyone is wondering what kind of files make up the 1.42GB they are a bunch of savegames at about 1 - 2 MB each) From my tests it looks like the problem is limited to NTFS, and seems to be closely related to the amount of files on the disk. There with a specific configuration whose chkdsk only uses the good old 30MB or so of RAM and he can give us all a little advice. It might be nice to get a little more information from someone on the "file system team", but if they truly have looked at the issue as he stated in the blog, then it either isn't a bug or it is but it would be too much work to fix when weighed against theĪnyway, I don't want to get off topic, and I think it's fine if you disagree with me, but I just genuinely want to hear from other people that are facing the same "issue" that we are (if you can call it that). He states that the behavior is limited to the /r switch but I've seen it with the /f switch - the memory usage increases just as quickly, the only reason it doesn't get as high is because chkdsk /f doesn't take as long. You’d really like the disk to be fixed before you do more stuff on the machine, an assumption validated by several subsequent third party blog posts on this topic)." "from their perspective the memory usage was by design and was a specific Windows 7 change for this scenario (the /r flag grabs an exclusive lock and repairs a disk and so our assumption is ![]() When you say "it's been stated it's allocating this memory by design" are you referring to the following quote from There are a LOT more important glaring problems in Windows 7. If anything's better, but it's been stated it's allocating this memory by design. Maybe it's not faster but somehow more accurate or more likely to correct problems successfully? Without looking into the implementation, it's impossible to know what's better, or really even I would be interested to see if anyone else can duplicate this. It doesn't seem to depend on which stage it is in - the memory usage balloons during stage 2 of a chkdsk /f on a (full) 1TB hard drive I have, and it happens during stage 4 of chkdsk /r on a half-full 32GB USB flash drive as well. chkdsk /f on a large hard drive works fine, or chkdsk /r on a smaller hard drive will work as well. The problem is easiest to duplicate if you run chkdsk on a drive other than your OS drive (so you can actually have task manager open while it runs as opposed to running after a reboot), and if you run a check that will take a long time. I actually have two machines running windrelease candidate (圆4) and the I noticed the problem on both. after chkdsk has been running for 10 seconds it will be using 250MB, after 2 minutes it will be using 3.0GB) I am monitoring memory usage using task manager. I've used chkdsk on the same USB flash drive on my XP, vista, and 7 machines, and the memory usage is as follows: xp : 20 - 30 MB (Depending on stage) vista : 2.5MB 7 : about 25MB per second running (e.g. I was wondering if anyone else has noticed extremely high RAM usage when using windows 7's chkdsk. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |