DiracDeBroglie

Got your spreadsheet from http://reboot.pro/2959/#entry74116 second version. WAAAAAAW, very impressive, very colorful. Don't have much time but I managed to perform a few small tests with CHS changes and then see the newly calculated result in LBA. This could be a very handy tool in conjunction with other tools that can write directly to the disk, like Tiny Hexer. j

Using DISKPART, I changed the type of my recovery partition from 0C (FAT32X) to 0B (FAT32), made the partition then active and restarted my computer. The computer booted immediately into my recovery partition without any problem. It looks like 0C and 0B are indeed the same. j

About the error message "System Error." "Code: 5." "Access is denied." when using Tiny Hexer, I tested LockDismount v0.3.0.0 (LD) and it works, at least on non-system drives (as mentioned in the link you gave) like USB Flash Drives. A drawback of LD is that it locks the entire HDD while in fact I only wanted to edit with Tiny Hexer a few sectors of one particular volume or partition on the system HDD. In my case I wanted to test Tiny Hexer by editing just a few empty dummy and meaningless sectors in the recovery partition (which sits on the system HDD). Upon trying to save away the altered test sector in Tiny Hexer I got then the error message. Using LD, LD tried to lock ALL the volumes on my system HDD and showed FAILED for all of the locking attempts -- a pity LD does not work solely on just one particular volume/partition, in stead of on entire HDDs. I went on to create a few virtual HDDs, or vdisks, in Disk Management and dropped the *.vhd files in a primary partition on the system HDD. To my surprise Tiny Hexer could save away the edited sectors in those vdisks without causing the "Access is denied" error; so no need at all to use LD. An extra check after reboot of the computer revealed the sectors where indeed altered/updated. Although the *.vhd files of the vdisks were located on the system HDD, Tiny Hexer had somehow "direct" disk access to the vdisks. Annoying thing with my vdisks though is that I have to re-attach them after each reboot. BTW, I did not get any "Access is denied." error from the old PowerQuest's Partition Table Editor (PTEDIT32.EXE) when saving away an edited PBR on one of the partitions on the system HDD. It looks like Win7 gives direct disk access to some old software, but to some other old software (like Tiny Hexer) it doesn't. j

I'm using your 3 scripts, and indeed those are extremely handy. Great added value to Tiny Hexer, those scripts have been very helpful to analyse USB Flash Drives where the MBR is sometimes missing. There is one disadvantage though with Tiny Hexer, there is no userfriendly editor to edit the partition table or any figures like 'sectors before' the PBR. I still use the old PowerQuest's Partition Table Editor (PTEDIT32.EXE), which works just fine. I'm not sure but I think you probably use also another utility for fixing MBRs and PBRs; if I recall correctly it start with HD..... , or something. johan

I checked out MBLdr and that could be a good alternative to replace proprietary boot selectors, only kicking into action by tapping a particular Function key. The link you gave me was in the context of someone who could not see the Recovery partition anymore. In emergency cases one can apply an even simplier solution for booting off the Recovery/Re-Install partition without having to resort to any MBR fiddling in case the MBR bootselector is lost. Burn a GPartEd LiveCD, boot from that, make the Recovery partition unhidden by unticking the checkbox hidden, and tick the checkbox Boot. Restarting the computer boots right away into the Recovery partition. Even more simple, run the repair disc, CD/DVD, (and this any normal human being with a normal iq should have), go into the cmd console, then: X:\diskpart diskpart>list disk ; select disk 0 (if your recov par is on disk 0) ; list partition ; select partition [number of recov par] ; detail part ; set id=0C override (in case it was 1C, hidden fat32x) ; detail part (again) ; Active ; detail part (again) Now the Recovery partition is type 0C, and active (will boot). Quit the repair disc, restart computer and it'll boot into the Recov part. PowerQuest's Partition Table Editor can also change the hidden fat32x (1C) ID to unhidden (0C). Reboot, mark Recovery partition as active in Disk Management and reboot again. Computer boots right away into the Recovery partition. Booting into a Recovery/Re-install partition is *never* a problem, at least if you haven't been fiddling with the bootsector of it (as in my case). I still need more time to go into all this (and into so many other posts and links) but I am off for 2 weeks not having access to any test machine. I can still read the forums now and then, though. CU later folks, j

There are several MBR programs of TU, could you provide me with the exact link? Thanks, j

Are there any bootmangers, bootloader, bootselectors, (like Grub, LILO, ... ) that can be put in the MBR and that become active only when tapping a particular F-key at boot time, after which the MBR bootselector performs a particular task like making a hidden recovery partition bootable, then effectively boot into it and after that turn the ID of all the altered partitions back to what is was before?? Or is this kind of property only for proprietary bootloaders of the OEMs (Asus, Dell, HP, ..)? j

Just did a test with an EasyBCD created bootable partition, with 2 options in the Window Boot Manager's (WBM) menu: WinRE (WinRE.WIM) and Windows Setup (which basically calls a BOOT.WIM with a WinPE in it). When the menu pops up for about 10 seconds or so, I tap F8, which makes the WinRE start loading first, and that takes some time because that is a WIM image. After the loading is finished the ABO (Save Mode, Save Mode with Networking, Save Mode with Command Prompt, ...) pops up. After proceeding with the ABO WinRE boots. If I, on the other hand, change the boot order, that is, Windows Setup (default) and WinRE, I have the same procudere about the ABO menu after which I can boot into the Recovery partition's BOOT.WIM. It is not quit clear where exactly the ABO menu is located (bootmgr.exe or bcd), but it is sure that the appearance on the screen can only happen if WinLoad.exe has been executed and/or the Win Kernel loaded. j

Thanks for the info. I'll probably install soon a clean install of Win7HP which I will download from one the MS associate servers. I got an ASUS notebook K93SV and the way ASUS works is very sloppy; lots of bloatware and other rubbish. I'll get rid of it by a clean install. To boot from the Recovery/Re-Install partition I need to tap F9 at boot time. BTW, the info which can be seen on the screen in Avanced Boot Options (ABO), is that also located in the BCD store? Do I interpret it correct that first Windows Boot Manager loads its boot options (Win7, WinRE, Windows Setup, ...WinXP, ...Memtest, ...) and then the ABO? Or is it different somehow? Thanks, j

Well, if you can interpred as a human being directly HEX code, great for you! But that is not the case with me, I have to stick to something that readable by average human beings. j

Jaclaz, I read the links you forwarded me, more specifically those links: http://thestarman.narod.ru/asm/mbr/MSWIN41.htm http://thestarman.narod.ru/asm/mbr/ntFAT32BR.htm http://thestarman.narod.ru/asm/mbr/FAT32brcomp.htm Thanks for the links by the way. However, the pages of those links talk about an extra sector being added, sector 12, when a Win98 FAT32 partition is converted by Win2K or XP. But nowhere on those pages it is explicitly mentioned that sector 2 is not used or interpreted anymore after XP conversion (or I must've missed it in the text). That is why I got confused a bit and thought for a while that there were 4 sectors involved in the booting of a FAT32 partition under Win2K and higher. Especially on the page http://thestarman.narod.ru/asm/mbr/FAT32brcomp.htm , sector 2 before and after XP conversion remains the same; so tacitly I assumed sector 2 was stil involved but now I realize that sector 2 is still coded with old code from Win98. On the other hand, on my FAT32 partition sector 2 is completely zeroed, empty, and is lacking the RRaa at the beginning; that is clearly visible in the Tiny Hexer pictures of mine; so I can see sector 2 cannot be part of any bootsector sequence. Thanks, j

C:\Windows\system32>reagentc /info Extended configuration for the Recovery Environment Windows RE enabled: 1 Windows RE staged: 0e Setup enabled: 0 Custom Recovery Tool: 0 WinRE.WIM directory: Recovery Environment: \\?\GLOBALROOT\device\harddisk0\partition1\Recovery\8c b2d9b4-7c05-11de-842e-b4611d44fefa BCD Id: 8cb2d9b4-7c05-11de-842e-b4611d44fefa Setup Files: Recovery Operation: 4 Operation Parameter: Boot Key Scan Code 0x0 REAGENTC.EXE: Operation successful C:\Windows\system32> I got a question about the command reagentc, if I do >help in the cmd console a list of commands appears, but reagentc is not in there. I finally have found ReAgentc.exe in System32 folder. How could I see some kind of a help list of all those Apps/commands available (in the Sys32 folder) in the cmd console? The recovery/re-install partition (20GB) is normally hidden but I switch it to unhidden (visible) and boot on-and-off with a GPartEd LiveCD. Sometimes I use the "Set ID=1C (or 0C) override" in the Diskpart console. About your remark about the recoverysequence and recoveryenabled settings, what do you mean with "recovery"? Do you mean the re-install of Win7HP (many GBs), or do you mean the repair tools (160MB) under the folder Recovery in the root of the C:\ system HDD? The repair tools are not a problem, they pop up in the Advanced Boot Options in case there is a issue with the Win7 system partition. However, I've also put a link to the WinRE.WIM in the Windows Boot Manager (BCD editing using EasyBCD) and that allows me to enter the repair at any time. j

As for Madame Tussauds in London, most folks are alive and kicking, especially the last holds for footballer David Beckham. From the links you gave me FAT32 uses mainly sector 0, but Microsoft has started to use also sector 1 and -2, with backups in sectors, 6, 7 and 8. As far as I understood from wiki (http://en.wikipedia.org/wiki/File_Allocation_Table) sector 12 is used to put an extended bootloader in there. I'm not sure where the backup of sector 12 would reside.(?) I had a look in sectors 17, 18 and 19 hoping to find a backup of sector 12 in there, but nope, nothing, niks, nada,... At first sight, It looks like sector 12 is not being backuped, but I could be completely wrong here. I noticed there are no differences between sector 0 and sector 6, a slight difference between sector 1 and sector 7, and no difference between sector 2 and sector 8. Attached are 4 images to support that: I am not all too sure about the difference between sector 1 and sector 7, is it serious, should I copy sector 7 onto sector 1? I have to wait and see how the recovery partition behaves. But one thing is for sure, I'm still stuck with the error message: "System Error." "Code: 5." "Access is denied." when trying to write back an updated sector in Tiny Hexer. What could be the possible reasons for that error? johan

Jaclaz, YOU'RE MY HERO!! I'm truely convinced that in Madame Tussauds in London they should create a new category called REAL HEROES and put a wax statue of you in that category. Or even better, they should revive the series "HEROES" (http://www.imdb.com/title/tt0813715/) and introduce a whole new hero called JACLAZ who's got the ability to control computers from distance just by "thinking"; I bet a revival or a come-back of the series with JACLAZ as hero would be a hit. You better get in touch with the producer Tim Kring --- also, get your character JACLAZ already patented or somehow intellectually protected. When I read your response I pretty much realized right away what the problem was. I had the figures and the solution right under my nose all the time and didn't see it; I also had the tools right on top of it but litterly didn't see it; bloody hell. I opened the usual old soft: PowerQuest's Partition Table Editor (PTEDIT32.EXE) and there it was: The Sectors Before in the MBR and the Hidden Sectors in the bootsector (PBR) were different. I realized immediately the PBR was wrong. So I copied the Sectors Before (MBR) to the Hidden Sectors (PBR) pane, and saved it. The recovery partition booted correctly and the Win7HP re-installation application started immediately. The recovery partition was first located on the outermost tracks of the system HDD. As I want to save the outermost (and highest data rate) tracks for the system partition, or a pagefile partition later on, I cloned/imaged/copied (with GPartEd LiveCD) the recovery partition to the innermost tracks, where I performed some tests and all was ok. After that I shrunk the partition from 25GB to 20GB, as the partition contained only 17GB of data, thereby leaving another 5GB unallocated space behind the recovery partition at the innermost tracks of the HDD. I ran again some tests and all was ok. Then, I took a clone/image/copy of the relocated/shifted recovery partition, using the GPartEd LiveCD, onto my external backup HDD. The last operation I performed on the recovery partition on the system HDD was again a shift (GPartEd) towards the very end as to recycle the last unallocated 5GB on the innertracks of the system HDD. Although the last operation kept the Sectors Before (MBR) and the Hidden Sectors (PBR) on the system HDD consistent, the Sectors Before (MBR) on the system HDD were definitely not consistent anymore with the Hidden Sectors (PBR) of the recovery partition CLONE/IMAGE on the backup HDD because I performed the last 5GB shift after I took the clone/image. As I continued working (fiddling actually) on the recovery partition, I decided to continue with a fresh re-start and re-imaged my clone/image from the external backup HDD back onto the system HDD, thereby making the Sector inconsistency a matter of fact. Lesson to be learned, if you take a clone/image, do not shift the orignal partition anymore!! (Unless you got Hero behind you.) I still have a few questions but I'll post them later. It's bed time now. j

Yes. http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/questions-with-yes-or-no-answers.html jaclaz Hahaha veeeeeery funny, ok jaclaz, would you be so nice, so kind, so friendly to let me know how I can get rid of the error message? Thanks in advance, j

Ok, here comes the zip file with the MBR and PBR. MBRPBR20120709tinyhexer.zip j

Here it comes. The main point is getting the error message gone so that I can move on with Tiny Hexer. j --------------------------------------------------------- C:\Windows\system32>bcdedit /enum all Windows Boot Manager -------------------- identifier {bootmgr} device boot description Windows Boot Manager locale en-US inherit {globalsettings} default {current} resumeobject {0540b4cc-c367-11e1-9849-806e6f6e6963} displayorder {current} {500cf7cd-c423-11e1-b5b0-14dae9e74180} {fec54f22-c74c-11e1-ada2-14dae9e74180} toolsdisplayorder {memdiag} timeout 10 displaybootmenu Yes Windows Boot Loader ------------------- identifier {500cf7cd-c423-11e1-b5b0-14dae9e74180} device ramdisk=[C:]\Recovery\8cb2d9b4-7c05-11de-842e-b4611d44fefa\Winre.wim,{500cf7cc-c423-11e1-b5b0-14dae9e74180} path \Windows\System32\Boot\winload.exe description Window 7 Recovery Environment (system partition) locale en-US osdevice ramdisk=[C:]\Recovery\8cb2d9b4-7c05-11de-842e-b4611d44fefa\Winre.wim,{500cf7cc-c423-11e1-b5b0-14dae9e74180} systemroot \Windows detecthal Yes winpe Yes ems Yes Windows Boot Loader ------------------- identifier {current} device partition=C: path \Windows\system32\winload.exe description Microsoft Windows 7 locale en-US osdevice partition=C: systemroot \Windows resumeobject {0540b4cc-c367-11e1-9849-806e6f6e6963} Windows Boot Loader ------------------- identifier {fec54f22-c74c-11e1-ada2-14dae9e74180} device ramdisk=[F:]\sources\BOOT.WIM,{fec54f21-c74c-11e1-ada2-14dae9e74180} path \Windows\System32\Boot\winload.exe description Windows Setup locale en-US osdevice ramdisk=[F:]\sources\BOOT.WIM,{fec54f21-c74c-11e1-ada2-14dae9e74180} systemroot \Windows detecthal Yes winpe Yes ems Yes Resume from Hibernate --------------------- identifier {0540b4cc-c367-11e1-9849-806e6f6e6963} device partition=C: path \Windows\system32\winresume.exe description Microsoft Windows 7 locale en-US inherit {resumeloadersettings} filedevice partition=C: filepath \hiberfil.sys debugoptionenabled No Windows Memory Tester --------------------- identifier {memdiag} device boot path \Boot\memtest.exe description Windows Memory Diagnostic locale en-US inherit {globalsettings} badmemoryaccess Yes EMS Settings ------------ identifier {emssettings} bootems Yes Debugger Settings ----------------- identifier {dbgsettings} debugtype Serial debugport 1 baudrate 115200 RAM Defects ----------- identifier {badmemory} Global Settings --------------- identifier {globalsettings} inherit {dbgsettings} {emssettings} {badmemory} Boot Loader Settings -------------------- identifier {bootloadersettings} inherit {globalsettings} {hypervisorsettings} Hypervisor Settings ------------------- identifier {hypervisorsettings} hypervisordebugtype Serial hypervisordebugport 1 hypervisorbaudrate 115200 Resume Loader Settings ---------------------- identifier {resumeloadersettings} inherit {globalsettings} Device options -------------- identifier {1f8184a5-14de-11df-9734-f08c6d8c50b0} description Ramdisk Options ramdisksdidevice unknown ramdisksdipath \Recovery\1f8184a4-14de-11df-9734-f08c6d8c50b0\boot.sdi Device options -------------- identifier {500cf7cc-c423-11e1-b5b0-14dae9e74180} description Window 7 Recovery Environment (system partition) ramdisksdidevice partition=C: ramdisksdipath \NST\boot.sdi Setup Ramdisk Options --------------------- identifier {ramdiskoptions} description RamdiskOptions ramdisksdidevice partition=C: ramdisksdipath \NST\boot.sdi Device options -------------- identifier {fec54f21-c74c-11e1-ada2-14dae9e74180} description Windows Setup ramdisksdidevice partition=C: ramdisksdipath \NST\boot.sdi C:\Windows\system32> ---------------------------------------------------------

Sector 0 and 6 are identical, between sector 1 and 7 there is a slight difference, and between sector 12 and 8 there is a large difference. I copied (Copy and Paste) sector 7 into sector 1 and tried to save it but there always seems to be an error message: "System Error." "Code: 5." "Access is denied." However, I can open any file in the partition, edit it, and save it back. It looks like the partition is not at all locked. Any idea about the origin of the error? j

Hi, My FAT32X Recovery (R:\) partition fails to boot. Note that in the past and until recent, exactly the same recovery(reinstall) partition used to boot and reinstall my OEM Win7 several times without any problem. Luckily I took a backup of my Win7HP on 5 DVDs (long time ago) and I still got several copies of the 5 ISO files too. However, although I could do without the corrupted recovery partition, I still would like to fix the problem and get the recovery partition back up and running so that I can invoke it at boot time by just tapping F9, as before. The recovery partitioin is about 20GB and contains only my Window7HP OEM installation. In the root directory, the recovery partition contains the bootmgr.exe, boot\BCD and sources\BOOT.WIM. I've rebuild the BCD file with EasyBCD (and with the BCDedit commands in the cmd prompt too) several times and tried out all possibilities concerning repairing and rebuilding from scratch, but no bootable recovery partition yet. I've then also removed the entire \boot directory and the bootmgr.exe, followed by rebuilding the boot directory and bootmgr.exe using EasyBCD (BCD Deployment); still the recovery partition does not reboot. Finally I introduced a recovery partition boot option into the boot menu of my active system partition (normal Win7) by putting the R:\sources\BOOT.WIM into the C:\boot\BCD using EasyBCD. And that worked just fine. I could boot into my recovery partition and reinstall Win7HP. So the content of the recovery partition is still intact. I'm starting to think the problem must be in the BOOTSECTOR (or maybe in the MBR??) of the recovery partition. Upon booting the recovery partition, I just get a blinking "_" for an infinitely long time; to get out I need to poweroff the notebook. I have the impression that the bootsector is not even calling the bootmgr. I had a look at the first sector (sector 0) with Tiny Hexer and compared it (using the compare facility in the menu) with the backup sector (sector 6): There was no difference --- it could be that the copy is already overwritten by the corrupted version of the bootsector, I'm not sure. I noticed some text in the bootsector: the word "BOOTMGR" and the text "Remove disks or other media.ÿ Disk errorÿ Press any key to restart" appeared. So, if something would be wrong with the bootmgr, I think I should see some readable text on the screen, but that is not the case; the only thing I see is a blinking "_" . I would like to get more insight in how the bootsector calls the bootmgr. Does the bootsector look for a file by name, so the name "bootmgr", or does the bootsector jumps to a particular sector in the partition, which would be the first sector of the file "bootmgr"? Could it be that it is not the bootsector after all causing the problem but rathter the MBR, somehow? Thanks in advance, johan

Hey, I did not know that. So defragging is best done by Window's defragger then. Many thanks for this tip to pointertovoid and bphlpt, j

A very, very useful link. Many thanks. j

Specifications of tested HDD: Seagate Barracuda 7200.12 (ST31000524AS); 1TB, 32MB cache; Queue Depth =32; NCQ =supported; average track size =0.8MB. Some more IOmeter test results with parameters: 4K, 100%Read, a range of %s for randomness, and for 4 different numbers of simultaneous I/0s values (32; 4; 2; 1). The following figures show the throughput (Total MBs per Second) as a function of the % randomness. Test file = 500MB (Can be set by specifying the number of sectors in the option Disk Targets -> Maximum Disk Size; I my case I specified 1,000,000 sectors, as 1 sector is 512 bytes; Starting Disk Sector was kept at 0) # simultaneous I/Os =32 ------------------------ 0% randomness -> 95 MB/s 1% randomness -> 96 MB/s (a bit higher than in the 0% case) 2% randomness -> 6.8 MB/s 3% randomness -> 6.3 MB/s 4% randomness -> 5.3 MB/s 5% randomness -> 5.0 MB/s 10% randomness -> 4.1 MB/s 20% randomness -> 3.2 MB/s 50% randomness -> 2.1 MB/s 100% randomness -> 1.4 MB/s # simultaneous I/Os =4 ------------------------ 0% randomness -> 76 MB/s 1% randomness -> 84 MB/s (8 MB/s higher than in the 0% case) 2% randomness -> 17 MB/s 3% randomness -> 14 MB/s 4% randomness -> 10 MB/s 5% randomness -> 9.2 MB/s 10% randomness -> 4.8 MB/s 20% randomness -> 2.6 MB/s 50% randomness -> 1.4 MB/s 100% randomness -> 1.1 MB/s # simultaneous I/Os =2 ------------------------ 0% randomness -> 67 MB/s 1% randomness -> 67 MB/s 2% randomness -> 14 MB/s 3% randomness -> 12 MB/s 4% randomness -> 9.8 MB/s 5% randomness -> 8.2 MB/s 10% randomness -> 4.7 MB/s 20% randomness -> 2.6 MB/s 50% randomness -> 1.2 MB/s 100% randomness -> 0.8 MB/s # simultaneous I/Os =1 ------------------------ 0% randomness -> 43 MB/s 1% randomness -> 40 MB/s 2% randomness -> 9.8 MB/s 3% randomness -> 8.2 MB/s 4% randomness -> 7.2 MB/s 5% randomness -> 6.4 MB/s 10% randomness -> 4.0 MB/s 20% randomness -> 2.4 MB/s 50% randomness -> 1.1 MB/s 100% randomness -> 0.6 MB/s All tests clearly show a maximum throughput at 0% or 1% randomness after which the performance rolls off quickly for higher randomness, usually from 2% randomness onwards. One would expect the highest throughput for the highest #I/O value, but ... no way, depending on the randomness. #I/O=32 has the best performance for a randomness of 0%, 1%, 20%, 50% and 100%. For the randomness range of 2% -> 10% the highest throughput comes with #I/O=4, and probably the average randomness of 2% -> 10% comes the closest to an average "real live" system configuration. Take now the folder C:\Windows which is the dominant folder in how fast Win7 boots; the Windows folder contains 21GB and 92,000 files - hence average file size 0.22MB, which is a lot smaller than the average track size of 0.8MB on my system drive (so NCQ "could" be doing a good job and shorten the boot time). Intra-file randomness (on the platters) can be reduced by defragging the folder/boot volume, but file-to-file randomness cannot be detected by any defragger (at least I do not know any defragger like that), for the simple reason that defraggers don't know what the file order is in the booting process. Hence that, although the boot volume is very well defragmented, one could still be facing a large (file-to-file) randomness taking down the "real live" throughput significantly. Bottom line is that I haven't got a clue how good or bad the file-to-file randomness could be on my boot volume. Furthermore, I wouldn't be surprised that after running a defragger, the intra-file randomness has gone down, but the file-to-file randomness could've been increased, thereby (partially) offsetting the gain (shorter boot time) of the defragmenation. Fortunately, in Win7 (on my notebook) communication between the motherboard and the system drive happens through (U)DMA, although I have to say I have no idea how large the data-chunks are in my system at boot time. It could be that the UDMA (in Win7) plays down (significantly) the importance of randomness in the throughput; In (older) OSs that don't have (or have limited) UDMA, the throughput is likely more sensitive to the file-to-file randomness (I think its fair to say this was already implicitly confirmed by pointertovoid). Conclusion: 1) jaclaz was/is right; Benchmark results need very careful interpretation when extrapolating them to "real live" situations, as some parameters (like file order in the booting process) are not know by the benchmarkers. 2) Defragging the volume may help improve the booting speed (we all know that already); however, the gain in boot time might be small in Win7 due to UDMA. johan

What a disappointment!! With 10%random the Total MBs per Second drop from 90 (with 0% random) to about 3.5. With 100%random the performance went down to 1.5MB/Sec!!! Its time for an SSD. #I/O was all the time 32. Oh, I forgot to ask in my previous post: How can one create a test file of a particular length in IOmeter? Thanks j

Is this some kind of a "RAM disk", but where its content is a perfect mirror of its respective file content on the HDD? (so that a powerfailure doesn't mess up file consistency on the HDD?) Does that mean that the UDMA controller has access to whatever motherboard RAM size (hundreds of MBs, or even GBs) and where-ever located in the motherboard RAM? I know that on old OSs there was a thing like RAM disk, but its content was not always consistent with the HDD, floppy, JAZZ, Zip drive content. As a result powerfailure was usually very damaging to your files on the HDD. I assume that kind of powerfailure damage cannot happen when using DMA for data transfer between motherboard RAM and the HDD? Or can it? johan

What is a F6 diskette? >>The reference here is IOMeter but it's not easy to use, especially for access alignment. What is access alignment? ----------------------------------- I did the IOmeter test too on my 1TB Seagate Barracuda 7200.12 system HDD, with 3 different options in the pane |Disk Targets| -> |# of Oustanding I/O|=1, then =4 and again =32; I suppose that must be the Queue Depth equivalent to (or equal to) the NCQ in the HDD (correct me if I'm wrong). I'm not all to sure how to interpret the options |Maximum Disk Size (in sectors)| and |Starting Disk Sector|; do these need a figure?? I left them at zero during my tests. In the pane |Access Specifications| I've put the value |4K; 100%Read; 0%Random|. The results from the tests are showns in the screenshots hereafter for #I/O=1, =4 and =32. IOmeterQD1; IOmeterQD4; IOmeterQD32 The difference in performance between #I/O=1 and =4 seems significant; the difference between #I/O=4 and =32 is less, but still noticable. Anyhow, with #I/O=32 the performance comes pretty close to what I had earlier with ATTO Disk Benchmark. I also performed a test with #I/O=64 (no screenshot); the performance was better than with #I/O=1, but poorer than with #I/O=4. It looks like offering too many (>32) parallel I/Os chokes the NCQ handling in the HDDs controller. Still a question about the |Access Specifications| pane where I've put |4K; 100%Read; 0%Random|. All possible options were with 0% Random. I'm not sure what is meant with "Random"; does it mean random sector location of the HDDs platters? If yes, then 0% Random should mean 100% non-Random, right? If yes, 100% non-Random should mean 100% sequential (contiguous), which basically puts us into the same context of ATTO. But if both IOmeter and ATTO perform nearly-contiguous measurements, why does |# of Oustanding I/O| in IOmeter impacts the performance so much, while the Queue Depth in ATTO does not nearly influences the performance? Sticking point is how to interpret "Random" in |4K; 100%Read; 0%Random| for IOmeter? johan PS: I couldn't figure out how to introduce the image file inline in the text; they are now attached at the back.