DiracDeBroglie

Hi, One can change the MFT zone reservation by altering the registry key NtfsMftZoneReservation. Details are given in: http://support.microsoft.com/kb/174619 Under WinXP, with NtfsMftZoneReservation set to 4, the MFT zone of a newly formatted volume takes up almost 50% of the volume size. One can check that using UltraDefrag, see links below. Setting NtfsMftZoneReservation=1, using regedit; rebooting the computer and checking again the MFT zone of the volume with UltraDefrag reveals that the original MFT zone has shrunk with something like 50% (or more) although I have not at all reformatted the volume. If I then reformat the drive, the new MFT zone shrinks even more but then to its normal size (12% or so), consistent with NtfsMftZoneReservation=1. If I then set NtfsMftZoneReservation=4, reboot computer, check the MFT zone of the volume, then the MFT zone has expanded by itself while the empty volume has not at all been reformatted. It looks like the filesystem is changing the size of the MFT zone of the (empty) volumes by itself after NtfsMftZoneReservation has been set differently followed by a reboot, but without reformatting the volume Do I get it completely wrong here?? Did I mis something? Is there anyone who could confirm this by doing extra tests? I have noticed exactly the same problem with Windows 7. Also there the MFT zone of empty volumes gets altered after NtfsMftZoneReservation has been set differently followed by a reboot, but without reformatting the volume. Johan http://ultradefrag.sourceforge.net/en/index.html http://sourceforge.net/projects/ultradefrag/files/stable-release/5.0.2/

Hi, Did some tests (among so many other tests) under Windows 7 on several volumes sizes (250MB to 100GB) with cluster sizes going from 4KiB to 64KiB. Whatever the cluster size, the $MFT offset varies around 30% of the volume size with a maximum of 3 to 3.5GB. So a 1GB volume has an MFT offset of approximately 300MB; a 10GB has an MFT offset of 3GB or so; a 100GB has an offset of also 3 to 3.5GB. Those offsets did not change whatever the cluster value. As for the MFT zone reservation, I performed tests on the same volumes with the registry key NtfsMftZoneReservation set to 4. For the volume of 250MB the MFT zone was 30 to 40MB; for the 5GB volume the MFT zone was 4.6% of the volume size, or 220MB; for the 10GB volume it was 2.5% or 250MB; for the 100GB volume the MFT zone was 0.22% of the volume size, or 220MB. The MFT zone reservation was insensitive to cluster size. Did the test with 4KiB and 64KiB cluster size and there was practically no difference. I've also done tests with NtfsMftZoneReservation set to 1, but the MFT zone was not that much smaller than in the case NtfsMftZoneReservation was set to 4. Had to reboot the computer each time I changed NtfsMftZoneReservation. The figures for MFT offset and MFT zone are an estimate from what I saw on the screen using UltraDefrag 5.0.2. So, what I've found under Win7 is not compliant with http://support.microsoft.com/kb/174619 which mentions that for NtfsMftZoneReservation=1 12.5 percent of the volume should be reserved. I did the same tests on my 2TB drive connected to my WinXP laptop, and there the MFT zone reservation (1->4) worked as predicted in http://support.microsoft.com/kb/174619 ; for NtfsMftZoneReservation=4 halve of my volume was MFT zone. It is a bit strange that exactly the same 2TB drive with exactly the same NtfsMftZoneReservation values, results in such a huge difference in MFT zone size between WinXP and Win7. (see http://sourceforge.net/projects/ultradefrag/files/stable-release/5.0.2/ and http://ultradefrag.sourceforge.net/en/index.html ) There was also a peculiar thing, though. I filled up the 10GB volume (cluster size = 4KiB). As the volume got filled up, the MFT zone started to shrink, still leaving the MFT itself and the remaining part of the MFT zone contiguous; that was good. However, that was not the case for cluster size 64KiB. There the *beginnig* of the MFT zone started to fill up going towards the end, thereby chopping the MFT from its MFT zone; that resulted in a strongly fragmened MFT. After the volume was completely filled up, there were MFT droplets scattered all over the initial MFT zone. That was under Win7, I didn't do the same test under WinXP. Noticed some very strange behavior when switching NtfsMftZoneReservation back and forth between 1 and 4, but I will open a new thread for that. Did some tests with paritition software in an attempt to extend a volume at its beginning (in stead of extending its end), and that indeed moved (copied) the entire content of the volume at the very (newly created) beginning of the volume. I tested the free edition MiniTool Partition Wizard Home Edition 7.1 (PWWin7), and MiniTool Partition Wizard Bootable CD 7.1 (PWBootCD). The results under Win7 were very catastrophic: see http://www.sevenforums.com/software/212288-partition-wizard-win7-non-compliant-advance-format-drive-mis-aligned.html Johan

Hi Jaclaz, Normally (as far as I understood), a cluster comprises a number of sectors: a= 1, 2, 4, ... 128 (=equivalent with 64 KiB cluster); here a is always >1. Maybe we could try the following exercise. Take the 8GB volume from your previous post, it contains 15625000 sectors (512 byte sectors). Now I would like to know at what SECTOR the MFT starts on the volume for several cases. Suppose now we format the volume with clusters of just one (1) sector (0.5 KiB); the clusters contain each 512 bytes, and the MFT would then start at SECTOR #786432. Q:Is that correct? Take now clusters of 8 KiB on the 8GB volume. According to y=ax, a=16 and the start SECTOR of the MFT is now #12582912. Q:Is that correct? Assume the cluster size is 64 KiB on the 8GB volume. This would result in a=128 and the MFT start SECTOR becomes #100663296. Q:Is that correct? Note: the latter would entail that the MFT zone would occupy 6.44 times the 8GB volume capacity. Previous exercise is maybe not *that* important for solving my particular problem but it can, however, give me more insight in the internals of a filesystem and its bookkeeping, insight that could be of use to me at a later stage. -------------------------------- Yes, I got it confused. MBR and VBR (first bootsector in primary partition, or in EBR chain) are not to be confused. Thanks for the links btw. Also good that you pointed out the subtle difference between filesystem and volume (I didn't know). However, in http://thestarman.pcministry.com/asm/mbr/NTFSBR.htm#BSback they seem to make a distiction, in particular, between volume and partition. Btw, if I understand correctly, each primary partition has its bootsector mirrored at the end of the partition outside the volume or filesystem. As far as I understood, this is also the case with logical partitions (encapsulated in an extended partition) where each logical partition has its EBR mirrored in the back of its logical partition just outside its logical volume (or filesystem)---please correct me if I am wrong. I haven't found any confirmation on the net, but I assume there is nothing about any (boot)sector being mirrored to the back of the Extended encapsulating partition or volume, which would sit one level higher above the logical partitions (volumes), is there?? Still have to examine the tool(s) in http://ultradefrag.sourceforge.net/ Johan

Some definitions: -Disk Management (DM): -Beginning of a volume = left(side) in DM = outermost track = highest data rate; -End of a volume = right(side) in DM = innermost track = lowest data rate. I read the content of all the links you posted, and also some content that was provided in secondary links. Thanks for the links. Clusters?? So, if cluster size is 512 bytes then the 8 GB volume counts 15625000 clusters (=sectors in this case). If the beginning of the MFT is located at cluster #786432, the MFT zone occupies something like 5% of the volume space (in bytes)---I assume (yes "assume" again, sorry) that the 5% is between the beginning of the volume and the beginning of the MFT; so the MFT zone is on the outermost tracks of the volume. If, on the other hand, the cluster size on the 8 GB volume would be 8 KiB, then the MFT zone would occupy 80% to 90% of the volume space asuming the MFT still starts at cluster #786432? For the case were the cluster size would be 64 KiB on the same 8 GB volume, the MFT zone would hypothetically occupy 640% of the volume space, if the MFT still were to start at cluster #786432. Of course, this cannot be the case. There must be a limiting/correcting factor somewhere (I think?). According to http://www.pcguide.com/ref/hdd/file/ntfs/archMFT-c.html the maximum cluster size of the MFT itself would be 4 KiB, but the pcguide.com article doesn't mention anything about the cluster size of the MFT zone. I hope and assume the cluster size of the MFT zone and the non-reserved area on the "other side" of the MFT always have the same cluster size (correct me if am wrong). Theoretically, with a cluster size of 8 (or higher) KiB during formatting of the entire 8 GB volume, one could still have a situation where the MFT zone would start at the end of the drive, despite the MFT itself having a cluster size of only 4 KiB. Furthermore, with a maximum cluster size of 4 KiB for the MFT, it looks like one could have two (2) different cluster-size systems on the volume; e.g. 4 KiB for the MFT, and 64 KiB for the user data files!? Do I really interpret all this correctly? I must've overlooked something. What did I miss? --------------- Are you sure that in a newly created volume (with an almost empty MFT zone and empty non-reserved area on the "other side") the MFT has the preference to grow towards the right, meaning towards the innermost tracks, away from the MFT zone?? From the links you gave me, I inferred that the MFT has the "tendence or preference" to grow from the beginning of the MFT zone (which lays (in disk-space terms) 12.5%, 25.0%, 37.5% or 50.0% from the beginning of the volume) towards the beginning of the volume, so towards the outermost track in the volume, meaning to the LEFTward direction (so not to the right). Maybe I interpreted all this not quite right, please correct me if I am wrong. Just realized something. With [expand "on the right" when it grows], maybe you meant "on the right SIDE" of the MFT, so growing in leftward direction?? Did you? If yes, then ignore previous paragraph of mine. Ok good, expanding the partition towards the right side in DM (towards innermost (slower) tracks) does not entail copying of the MFT nor copying of any userdate. That is what I wanted to hear. "bootsector mirror"? Did some Googling but couldn't really find that much info about it. Something with NTFSdos errors came up. I recently learned GPT has, apart from its primary version on the first 34 sectors, also a secundary GPT, which is a copy of the primary, and starts at the very last sector going towards lower LBA numbering, so 34 sectors towards the beginning of the volume, contrary to the primary GPT that goes upwards toward higher LBA numbering. So one could consider the secundary GPT as a mirror of the primary one. Is a bootsector mirror something similar then? Some extra safety in case the first bootsector gets damaged? I thought that, for recovery purposes, there was already a copy of the bootsector in the second sector (sector 2, = LBA 1). If I interpret this correctly, expanding a volume (partition) by moving the beginning towards the left and leaving the end where it was, will likely entail that the MFT and all userdata will be copied towards the left! (Damm!) That is not really what I wanted to hear, but that's how it is now. I believe it is very important to know this kind of information when one needs to take decisions about partition layout prior to formatting a drive. About the MFT zone, if the non-reserved area is filled up with userdata, then next files are dropped in the MFT zone. Question is, how is the MFT zone being filled up then? Does the dropping of userdata starts somewhere at the very beginning of the volume, so at the end of the MFT zone, where the userdata then grows towards the MFT? Or, does NTFS starts writing the userdata at the beginning of the MFT zone, right behind the MFT itself, where the userdata then grows towards the beginning of the volume? The latter scenario would consequently lead to fragmentation (and performance degradation) of the MFT itself. I couldn't agree more. I have to do some experiments on my drive. Question is, do you (or anybody else reading this post) know any good utilities or tools (according to your personal experience), which could return information (or could give me at least some idea) about the beginning and ending of the MFT, the MFT zone, the non-reserved area, the location of areas with high concentration of occupied clusters, etc. A tool like that might have a graphical 1-dimensional (as in WinXP defragmentor) or 2-dimensional (Old Macintosh software) representations of the location of the MFT, system and userdata files, or could also return a numerical representation (a bit in the style of PTedit32 and PartitionInfo 8 for instance) of the location of the MFT, system and userdata files. As for graphical tools, on pages http://technet.microsoft.com/en-us/library/cc767961.aspx http://technet.microsoft.com/en-us/library/Cc767961.opt05_big(en-us,TechNet.10).gif I've found a tool called "diskeeper IRISCRIMSON". That tool clearly shows the MFT. On the webpage of diskeeper, http://www.diskeeper.com/business/diskeeper/professional/features/default.aspx , I noticed there is no mentioning anymore of any MFT representation. I remember that many years ago (When hard drives where still small) I had some utility on my Macinstosh, which represented the (or groups of) clusters in a 2-D matrix on the screen. If I recall correctly, some group of clusters was represented by a little square in a particular color, depending if the clusers belonged to userdata or system data. Lower left corner of the 2-D matrix represented LBA 0 and the upper right corner represended the last LBA. It was great stuff those days, but I can't remember that I have ever seen anything similar for the Windows environment. HEX C0000 is lovely number (I think). I don't know why they picked exactly *that* number, though. Conversion both ways between the numbers is straight forward. Johan

Hi, Well, the quessing work of mine was not just really wild guessing, there was some reasoning behind it. In Disk Management (DM) Disk 0 (boot disk) has its C partition on the left side in DM. I assume (I know, I know "assume" again) the folks from ASUS are smart enough to put the OS (Win7) on the outermost tracks, which are supposed to be the high data rate tracks (in the assumption the boot drive is recording in zones: http://www.pcguide.com/ref/hdd/geom/tracks_ZBR.htm ). That should results in the fastest booting possible with that particular drive. So, implicitly and tacitly I assumed (sorry again) that the left side in DM represents the outermost (high data rate) tracks for ALL drives and parititions visible in DM--- I might be wrong. But, you were very right by raising your point. The notions outermost, innermost, fast, slow, beginning, end, ...they are ambiguous and susceptible to interpretation. So, I've examined the 2TB drive of mine in the following way. I created 3 primary partitions (cluster size = 64 KB) on the 2TB drive with the following asymmetric partition layout: | (F) 10 GB || (H) 10 GB || UNallocated 1833 GB || (I) 10 GB | Volume F is the leftmost volume in DM, Volume I is the rightmost Volume in DM. I then copied a test folder of 4 large video files (total 9.68 GB) onto Volume F, and that took 109 seconds. From that I calculated a write speed of 88.9 MB/sec. I repeated the same procedure for volume I. Summarizing the Write speeds: Volume F: 88.9 MB/sec Volume I: 43.1 MB/sec The same procedure was then repeated (again) with 3 video files in the test folter (7.26 GB), and that resulted in Write speeds: Volume F: 90.8 MB/sec Volume I: 45.4 MB/sec I also did the test with Atto Disk Benchmark, that gave me the following results: Volume F: 145 MB/sec (Write speed) ; 128 MB/sec (Read speed) Volume I: 67 MB/sec (Write speed) ; 67 MB/sec (Read speed)---the same speed as the write speed, is that strange?--- Temporary conclusion: In my particular case the left side in DM represents the high data rate (outermost) tracks, and the right side in DM represents the low data rate (innermost) tracks. There is still the position of the MBR te be determined. Is the MBR located at the side of the outermost tracks or at the side of the innermost tracks? To find that out, I used PartitionInfo 8 on Win7 (but in Compatible Mode WinXP-SP3). As the disk is asymmetrically partitioned, one can clearly see the one and the other end of the disk in the sector numbering in PartitionInfo 8. Volume F started at sector 2048, and Volume I started at sector 123886544896. As the MBR is usually located on sector 1, or LBA 0, the MBR is neighboring Volume F. Hence the MBR must be on the very outermost track, meaning the very left side in DM. Still a question: is if fair to call the outermost track in the partition (which presumably is also the highest data rate track in the partition, and also the nearest to the MBR) then the "beginning" of the partition?? ---------------- Concerning the Master File Table (MFT) issue, did some reading on: http://en.wikipedia.org/wiki/Master_File_Table#Internals http://www.pcguide.com/ref/hdd/file/ntfs/archMFT-c.html In the example in your post (jaclaz), the $MFT sits at a (relative) offset of Dec 5355 (clusters) from the "beginning" of the partition. Do I understand it correctly that this is 30 to 35% into the partition size? Or, do I interpret this wrong somehow? In your example that would be an initial "MFT zone" of 30-35% ?! In pcguide.com they talk about a MFT zone of only 12%. I have a question about the MFT. Just to be sure, in what direction does the MFT structure initially grow in case the partition is nearly empty (right after its creation)? I am not sure but I would "assume" (yes, yes, sorry) that the MFT initially grows towards the beginning of the partition inwhich the MFT sits. It looks like the MFT has "loosely" reserved some kind of smaller partition within its partition. Next is really relevant for my problem. Did I understand it correctly?? If an NTFS partition gets expanded by extending the "end" of the partition with UNallocated clusters, then nothing is being copied into the new part. If the old partition part was totally filled up, further filling up of the newly added part to the partion causes the "tail" of the MFT to jump at some time into the new part where it just keeps on growing there alongside the newly added (very) large files (which are nothing but external attributes of the MFT). Do I understand this one correctly??; and this is maybe the most important part of all for me!! If the partition gets expanded with UNallocated clusters at the side which represent the "beginning" of the partition (by adding more outermost tracks to the partition), then neither the user data (with large files), nor any MFT info from the old part will be moved during the expansion process of the partition. Increasing the partition at its beginning is basically enlarging the MFT zone (which can be used, as far as I understood, for exactly the same purpose as the zone on the "other side" of the MFT in the partition). Do I interpret all this correctly? (I seem to make a distiction between user data and the MFT, but I am getting more and more conscious that the (very large) user data files are a fully integral part of a dynamically growing and expanding structure called the MFT.) johan

I'm also in the opinion to partition the drive in several partitions. I think you have a strong point (in your link) favoring logical drives in a extented partition. Extended partitions have their own EPBRs inside the extended partition and not on sector 1, where any accidents in sec1 or track0 could cause lot of hassle. Logical drives should therefore be easier to repair in case of havoc. Actually, I recently learned that GPT partitions have similar protection as the 34 GPT primary sectors have a 34 secundary sector backup at the other end of the drive. Things might be different with virusses. Only "dumb" virusses may limit themselves to destroyng sec1, track0 thereby making it relatively easy to reconstruct logical MBR partitions and GPT partitions. However, I never heared about "dumb" virusses---they are all smart; so it likely that bad intentions on the drive will just wipe out ALL partition info where ever on the drive. By the way, aren't there any tools available that could backup (onto another medium) the MBR or GPT of a drive and restore it in case of trouble? Johan

Hi Jaclaz, how're doing, the very best for the new year, seasons greetings, Just had a look at your links. Looks like it could be quite a hassle to get a WinXP computer communicating with a GPT drive. The 2TB (external USB enclosure) of mine is intended as backup drive in the first place, although I'll keep the first 100GB or so as primary for future booting. I think 4 (primary) partitions will do in my case. If I need more than 4, then I'll have to decide between MBR with an extended partition or GPT. I don't feel for putting to much hassle and effort in getting the WinXP laptop and the 2TB drive to communicate; so I got a preference for MBR partitioning. If for some reason I have to partition the drive into GPT, then I can still backup the WinXP laptop over the home network and via the Win7 laptop. The main decision still to take from my side is the partition layout for the drive. That'll depend very much on the data that I will backup next coming years. One issue still left which I see is important in deciding how to work out the partition layout is related with another post of mine: johan

Any idea about links, websites, docs, which explain in a easy to read and quick fashion how to create basic (primary, extended and logical) partitions using Diskpart? I've been surfing in the help command of Dispart.exe cmd terminal but I have to say user-friendlyness is not the strongest point of diskpart. johan

Hi, Cluberti, Thanks for the link. I checked it out, definitely useful. The link didn't mention with so many words, though, that extended partitions don't exist under GPT. Furhermore, www.uefi.org didn't really provide me with any useful or conclusive info either about the exclusion of extended partions on GPT drives. After some Googling on the net, I discovered just a few forums and blogs were it is simply mentioned in the discussion that extended partitions don't exist on GPT drives. I find it very difficult to get or to lay my hands on any official document stating very explicitly that extended partitions don't exist in the GPT world. For the past 20, 30 years PC drives have been partitioned in primary and extended partitions. Any ICT person, any advanced user, anybody using a computer the past 20 years knows the notion "extended partitions". So, also for me the notion of extended partition is part of my genetics, and it didn't even occur to me that under Win7 there would be anything that could lack the notion of extended partition. I would find it trivial and obvious that in any (official) communication from MS, Intel or www.uefi.org about GPT they would clearly mention that extended partitions (or volume) don't exist at all. Anyhow, I am probably not going to use GPT as I've now realised GPT is not compatible with my WinXP laptop. johan

Hi, On my 2TB external drive, in a USB enclosure, I can create 4 primary MBR partitions using my WinXP laptop, it's just that the partitions are not aligned with respect to the 4K physical sectors in the 2TB drive. So, in order to ensure alignement, I have to create the 4 primary MBR partitions on my Win7 laptop. However, the Disk management (DM) in Win7 creates the 4th MBR partition automatically as an extended partition, and I don't want that: I want 4 primary MBR partitions under Win7. Question now is, how can one create 4 primary MBR partitions under Win7 using the graphical interface of Disk Management?? Is there a trick somehow to the job?? I could also initilize the drive as GPT, then I can go up to 128 primary partitions, but the thing is that the drive must be usable on my WinXP laptop. So, as my WinXP laptop cannot even see any GPT drive, I have to stick to MBR mode. johan

Hi, Under Win7, Disk Management (DM) allows you to shrink and extend basic partitions (primary, extended and logical partitions). Usually shrinking and extending happens on the right side of a partition in DM, that is, towards the innermost tracks of the drive. I assume that the left side of a partition in DM represents the beginning of the partition and is located at the outermost (fast) tracks of the drive, and the right side of the partition represents the end of the partition and is located at the innermost (slow) tracks of the drive---correct me if I am wrong. I also assume that the data and filesystem bookkeeping information (Master File Table---MTF) is always at the left side, so the beginning of the partition in the case of Win7 (NTFS). As far as I understood DM can move the end of a partition in the shrinking and extending process, but moving the beginning of a partition does not seem to work in Win7 DM. Maybe Diskpart could do the job, but I'm not sure. However, there are third party tools out there that can do the job and move the beginning of a basic partition. I have a question though: if, in the case of extending the partition, the beginning of the partition is moved towards the outside of the disk (meaning adding more outermost tracks to the partition), then I assume the filesystem bookkeeping data has to be moved also towards the outside along with the beginning of the partition. But what about the many GBytes of user data in the partition?? Can that stay, which would imply that the relative position of the files would have to be recalculated in the MTF, or will that huge block of GBytes of user data also be moved towards the outside of the disk along with the beginning of the partition and the filesystem bookkeeping data? Ofcourse, best would be that the huge block of user data would simply stay and that the relative file position of all files is recalculated, but I am not sure if that is the case. I am really looking for a conclusive answer on the question because that wil have an impact on the partition layout of my 2TB drive. johan

Just discovered something. The work-around I explained in my previous post for creating extended partions works only for MBR drives, not for GPT drives. Under GPT, Win7 DM just keeps on creating primary partitions; just did the test with more then 10 partitions, they were all primary. So, I assume under GPT the only way to create an extended partition is by using diskpart. I have to say Microsoft really messed it up with their Win7 DM. johan

I prefer to use something with a graphical user-interface, so DM. I am still doubting DM cannot create an extended partition before having 3 primary partitions first. Ponch, could you confirm what I have experienced with DM under Win7?? Is it really true that Win7 DM can only create an extended partition after having 3 primary partitions first?? (it is so bloody illogical of Win7 DM) In the Help Topics of DM, I coundn't find anything about the user NOT having the flexibility to choose at the beginning of the formatting process between primary or extended basic partititions. It looks like Microsoft doesn't communicate very clear about the limitations of DM in Win7, something that should definitely be done as under WinXP DM offers right away the choice between a primary or an extended partition. In WinXP I can format the entire drive right way into an extended partition, no way in Win7. I've been trying out things and there is a very simple way to get an extended partition using DM in Win7. For instance, if one wants an extended partition starting from a particular position (track), just fill up the disk space before that position with 3 primary paritions (of whatever size each). The 4th partition is then automatically an extended one. If one only needs only one primary partition, the 2nd and 3rd primary partition can be deleted, followed by an extension or expansion of the 1st primary covering all space until the beginning of the extended partition. That procedure gives you 1 primary and 1 extended partition; I know, it is cumbersome and Diskpart does it more elegantly but if one wants to use the Graphical User-interface, that is the way to do it I think. I noticed that shrinking/deleting a logical volume in Win7 DM is not really a problem, but shrinking the extended partition enclosure surrounding the logical partitions seems more difficult, as opposed to extending/expanding an extended partition, which works well. So, if one want the entire drive formatted as an extended partition, then create 3 primary partitions totalling a disk size smaller than the drive size (the 4th part remains unallocated), delete the first partition (becomes unallocated), partition the 4th part (automatic primary), and then partition the first unallocated part. The first partition is then automatically an extended partition. Then delete all primary partitions, and expand the extended partition to the end. The entire drive is then an extended drive. Apart from the primary-extended partition issue, there is also the issue of formatting the drive into a basic volume or a simple volume. Right clicking the unallocated area of the drive in Win7 DM makes the DM to offer you the option to format the drive in New Simple Volume. New Simple Volume is a dynamic volume; however, if I continue to format as New Simple Volume, then primary and extended volumes appear, which are basic volumes, but there is definitely no dynamic volume on my drive. So DM seems to take the decision to create a basic volume instead of a dynamic volume without any notification nor any warning, although I asked in principle for a dynamic volume (New Simple Volume). Completely nuts!! johan

Just found a link which worries me: http://97.95.43.80:10080/632/ So, it looks like DM in Win7 always chooses a primary partition, and only dedides to create an extended partition when creating a 4th partition. Can anyone confirm that? Furhtermore, DM in Win7 is a bit confusing if you ask me. DM offers me to format the drive in a New Simple Volume, New Spanned Volume or New Striped Volume. Only New Simple Volume works and so DM should than create dynamic disc, but DM doesn't do that. Instead it creates a basic volume (primary), which you should be able to convert to a dynamic disk, but that also does not work either. Strange! johan

Hi, I got Win7 Home Premium SP1. I know the KB doc but it is not applicable to my case as my internal Win7 drive is a 512-byte physical sector 1TB drive. In the mean time I ran into another partitioning problem under Win7: where I could really use some help. johan

The problem I have is DM in Win7. Is it so that in Win7 DM it is not possible to create an ordinary (basic) Extended partition with several logical partitions on an external USB drive?? In WinXP all is ok, I can create an Extented partition with several logical partitions. So, why can it not be done in my Win7 DM? Does anyone really understand the problem I have? johan

On WinXP I can create a primary partition and right after a second partition which is an extended one. Under WinXP I have an absolute grip on the type of partition, which is not the case in Win7. In Win7 I can only create primary partitions, but no extended partitions. In Win7 DM (disk management) I rightclick the unallocated drive; then the only format possibility that pops up is New Simple Volume, which seems to be a basic primary volume. I think there must be a problem with Win7 DM, as DM in WinXP works just fine. So, what could be the problem in the Win7 DM? johan

Hi, I got a 2TB drive (4K physical sector) in an external USB 3.0 (2.0) enclosure. With my old laptop (Windows XP) I can without any problem partition the drive into several primary partitions and several logical partitions within one extended partition. Note: the enclosure works in USB 2.0 mode on the old laptop. However, with my new laptop (Windows 7) I cannot at all create any (basic) extended partition. Disk Management in Win7 only gives me the format options New Simple Volume, New Spanned Volume and New Striped Volume. New Spanned Volume and New Striped Volume do not work at all on my drive. New Simple Volume does work but creates only and automatically (basic) primary partitions. There is no way I can create an extended partition with in there logical volumes (or partitions). Under Win7 the enclosure works in USB 3.0 mode. Why is it that I cannot create extended volumes (partitions) in Win7?? johan

SUBJECT: 512-byte-size clusters on Advanced Formate drives. Just want to report a peculiarity about 4K-physical sector drives that emulate 512-byte sectors (Advanced Format [AF] drives). What follows might seem trivial to many readers, but anyhow, I figured I'll drop it on this blog. I've formatted my 4K physical sector 2TB AF drive in clusters (Allocation Unit Size) of 512 bytes under WinXP: guess what, it works! Unbelievable! I checked it with a notepad document of 130 bytes. On my old 512-byte physical sector drive, which is formatted with 4096-byte clusters, the Size On Disk is 4096 bytes. However, on the 4K sector 2TB drive, the Size On Disk is 512 bytes too!!! As far as I understood, one 4K physical sector could be home to 8 different files of each less than 512 bytes. So, even if the beginning of any partition on a 4K-physical sector drive would be aligned (by whatever trick, or tool, or utility under WinXP), my temporary conclusion is that 2 files could still be starting and ending within the same 4K physical sector, resulting in a performance degradation. It seems obvious to me that partition alignment only makes sense if the cluster size is a multiple of 4096 bytes. Nonetheless, I haven't found any information on the Internet about the issue that clustersize must be a multiple of 4096 bytes for making partition alignment effective. I wouldn't be surprised there are folks out there who try to combine a partition alignment with cluster sizes of 512 or 1024 bytes. All this was on WinXP. One would expect that on a modern OS like Win7 this kind of nonsense would not be possible, but forget it!; exactly that kind of nonsense is possible in Win7. I just formatted my 4K physical sector 2TB AF drive under Win7 in clusters of 512 bytes. I checked it with a 259-byte notepad text file and the Size On Disk is 512 bytes. During partitioning and formatting Win7 (Disk Management) puts the partition(s) at an offset of 1048576 bytes so that the partition(s) on an Advanced Format drive is always aligned. However, Win7 allows the user to erase the advantage of partition aligned. Any user, ignorant about the partition alignment issue, and more concerned about minimizing waist of disk space for large numbers of small files, can put the cluster size at a fraction of 4096 bytes. Is there anybody who could confirm this flaw in Win7 formatting of AF drives? Johan

Hi, The 2TB (4K-sector; 512e; Advanced Format) drive of mine is a Seagate drive. I used SeaTools for Windows to check the drive---took me a whole long day---and all seems ok. A comparison of SMART info from before and after the SeaTools testing revealed no problems with the drive. Most important SMART attribute 'Reallocated Sector Count' remained pinned down at zero. On the other hand, the attribute 'Hardware ECC recovered' went from 19 to 27 (Current); the value for Worst remained at 15. Hope the attribute 'Hardware ECC recovered' is ok. For downloading SeaTools for Windows, go to: http://www.seagate.com/www/en-us/support/downloads/seatools Note; SMART check in SeaTools returns "Test unavailable". I contacted Seagate support via email and they told me that it's probably because the drive is in a third party USB enclore. I find that hard to believe as CrystalDiskInfo and PC Wizard 2010 both give me huge amounts of very *SMART* info about the drive. Seagate also has a Partition Offset Information (POI) Utilitie: http://seagate.custkb.com/seagate/crm/selfservice/search.jsp?DocId=214391&NewLang=en POI does work fine on my internal 512-byte sector drives of both laptops (XP and W7), but on the 2TB drive POI does not work at all. Also here, Seagate support purported POI does not work on drives in third party external enclosures, as mine. I have to say I also find that nonsense because PTEDIT32 (which is 12 years old) and PartitionInfo 8 both give the number of "Sectors Before" the beginning of all partitions, on the internal drives as well as on the external drive. Divide the "Sectors Before" by 8 and if the outcome is an integer than the partition in question is aligned. The same job for all other partitions (and maybe also on the total sectors inside each partition) return an integer in case of proper alignment. Strange that POI from Seagate cannot do that. I've found another cute Alignment Checker called Disk Alignment Test (short: diskat): http://diskat.net/download-en.html (if the site is not down) I got it from http://www.hddoctor.net/how-to-fix-disk-alignment-in-advanced-format-hard-drives/ Diskat did exactly the job on the Seagate 2TB drive that POI didn't, couldn't or wouldn't do. All the alignment stuff raised a question with me. If Advanced Format drives emulate 512-byte sectors, how come that utilities like Diskat (and POI) somehow know that the 2TB drive is a 4K physical sector drive?? I couldn't find any attribute in SMART that passes on to Diskat or POI info about the number of bytes per physical sector. nice links: http://www.techsupportalert.com/freeware-forum/system/6404-discussion-about-advanced-partitioning.html http://www.techsupportalert.com/content/best-free-partition-manager.htm Regards, Johan PS: I'll be off for a week. Back on 28 Dec.

You won't like the answers. jaclaz Yes, that's right I don't like the answers, but I guess I just have to learn to live with the non-perfect tech-world. Still got a question about bad sectors, though. Right-click any drive in WinExplorer root level, -> Properties, Tools, Check Now, then one can Scan for and attempt recovery of bad sectors. If I create just ONE primary partition onto my 2TB drive and I perform a full Scan for bad sectors, do I have to scan again for bad sectors in the newly created partitions after I've split the drive into smaller partitions. Note, I just hope Win7 can scan for bad 4K sectors just as good as it can scan for bad 512byte sectors (If that is not the case, then please notify). Thanks, johan

Jaclaz, Still a few questions. Q1: What are the best tools for looking up bad sectors, or looking up those sectors that *might* become (or have a high potential of becoming) bad in the "near" future? Is Disk Management under Win7 good enough for that job? From what I read, the latest drives check for (very) bad sectors in an automated way (on the fly). If sectors have to be re-read too often, the firmware in the drive could move the data off the suspicious sector to a spear sector, or something like that. However, I want to minimize the chance that any sectors in the next coming years start causing trouble; that way I could minimize the probability that I loose any data or have any other problems the next coming years. Hence that I'm looking for a tool that could look for potentially future bad sectors (some tool that can test the sectors to the very extreme). Q2: What are according to you the best tools---meaning, delivering the most comprehensive, detailed hardware info of the drive---for analyzing 4K (and 512byte too) sector drives? (Probably, any such tool will rely on SMART info from the drive.) Q3: What are the best Benchmark tools for testing the performance of 4K sector drives? I got DiskSpeed32 and Atto Disk Benchmark v.2.47, but I assume there must be more powerful stuff out there. NOTE, I got Win7HP, 64-bit. Thanks in advance, johan

Jaclaz, Just one more question about bootloaders on 4K sectors. Does that mean that any "ordinary" bootloader/manager, which was designed for 512byte sectors, can reside partially in the (first 512byte) MBR, and then continue from the 1025th byte onwards in the first 4K sector, all the way up to the last byte of the 256th 4K sector, just before the beginning of the first partition? Also, can any "ordinary" bootloader/manager, which was designed for 512byte sectors, function without any risk for problems on a 4K sector drive? I noticed that with older drives there is alway the offset of 63 512byte sectors; it looks like it is an international standard. However, is there also an international standard for the offset in 4K drives?? Microsoft uses an offset of 256 times a 4K sector, but the HD manufacturers (WD, Seagate) seem to deviate from that. I think (but I could be wrong) this could be annoying for the developers of more sofisticated boatloaders. Anyhow, so far so good for the MBR related stuff. I have some other questions about partition in the next message. johan

Hi, Jaclaz, That's a MS decision , if you check the "alignment jumper" that there is on some 4 Kb sector HD's (I seem to remember Seagate), you will see that they add a "fake" sector so that older OS (XP, that has hardcoded 63 as "boundary") will partition disk starting from sector 64. Since this has been made by the actual HD manufacturer, it means that 64 is "good enough". 64 x 512 = 32768 bytes (=8 times 4K sectors) or 64 x 4096 = 2642144 bytes, which is 1/4 of the offset in the Win7 registry key being 1048576 (=256 times 4K sectors). Problem is that it is not quite clear to me if one means a sector of 512 bytes or 4096 bytes. Fortunately, in the Win7 key they use simply bytes as offset, which is not susceptible to interpretation. Yes/No. There is NOT any gap between two primaries. (the previous is already aligned at start and has a size that is a 4 Kb multiple, so also it's end is aligned, hence the following is already aligned). There is no "gap" between a primary and an Extended (for the same reason) but there is a gap inside the extended until the beginning of the first Logical Volume and between any two Logical Volumes. These gaps were 63 sectors in the "previous standard" and are probably (but I have never had an occasion to check) 2048 in the "new standard". Is that 2048 times 512bytes, or 2048 x 4K? The first results in 2048 x 512 = 1048576 bytes, which is the same value in the registry key mentioned earlier. So 256 times a 4K sector between the logical volumes: that is a lot! This is a common doubt. Traditionally we have seen (because they were like that ) that the MBR is first sector of a hard disk. It is NOT like that (it is , but we have to slightly change the definition) The MBR is the first 512 bytes of the first sector of a hard disk. So, the first 512 bytes of the first 4K sector are used as MBR. A petty that the last 7 short (512bytes) sectors in the first 4K sectors are not used. That extra space could have been used for larger bootloaders, for instance, in case one wants to boot multiple OSs. Also the remaining 255 4K sectors between the first 4K boot sector and the beginning of the first partition are just sitting there. What is that space used for? For extra and larger bootloaders, maybe? johan jaclaz

Jaclaz, Just had a look at the key HKEY_LOCAL_MACHINE\SYSTEM\CURRENTCONTROLSET\SERVICES\VDS\ALIGNMENT that you mentioned earlier using RegEdit. Indeed there are the keys: Between4_8GB Between8_32GB GreaterThan32GB LessThan4GB and presumably they all have an offset of 1048576 (bytes), except for LessThan4GB, which has an offset of 65536 bytes. Then 1048576 / 4096 = 256, and 65536 / 4096 = 16. So it looks that any 512 or 4096-byte sector drive has its partitions automatically aligned in Win7. Is that a correct conclusion? I just wonder why the offset is so large? 256 times 4Kib offset is a lot. What could be the reason for that? And, are those gaps of 1048576 (bytes) also present between the partitions? Got also a question about the Master Boot Record. Usually the MBR is 512 bytes, but how long is the MBR in a 4KiB sector drive? Could be interesting to know because maybe I'll use my 2TB drive as an internal boot drive lateron. johan