Jan 152015

4Kn logoWhile I’ve been planning to build myself a new RAID-6 array for some time (more space, more speed), I got interested in the latest and greatest of hard drive innovations, which is the 4Kn Advanced Format. Now you may now classic hard drives with 512 byte sectors and the regular Advanced Format also known as 512e, which uses 4kiB physical sector sizes, but emulates 512 byte sectors for compatibility reasons. Interestingly, [Microsoft themselves state], that “real” 4Kn harddrives, which expose their sector size to the operating system with no glue layers in between are only supported in Windows 8 and above. So even Windows 7 has no official support.

On top of that, Intel [has stated], that their SATA controller drivers do not support 4Kn, so hooking one such drive up to your Intel chipsets’ I/O controller hub (ICH) or platform controller hub (PCH) will not work. Quote:

“Intel® Rapid Storage Technology (Intel® RST) version 9.6 and newer supports 4k sector disks if the device supports 512 byte emulation (512e). Intel® RST does not support 4k native sector size devices.”

For clarity, to make 4Kn work in a clean fashion, it must be supported on three levels, from lowest to highest:

  1. The firmware: For mainboards, this means your system BIOS/UEFI. For dedicated storage controllers, the controller BIOS itself.
  2. The kernel driver of the storage controller, so that’s your SATA AHCI/RAID drivers or SAS drivers.
  3. Any applications above it performing raw disk access, whether kernel or user space. File system drivers, disk cloning software, low level benchmarks, etc.

Granted, 4Kn drives are extremely new and still very rare. There is basically only the 6TB Seagate enterprise drives available ([see here]) and then some Toshiba drives, also enterprise class. But, to protect my future investments in that RAID-6, I got myself a [Toshiba MG04ACA300A] 3TB drive, which was the only barely affordable 4Kn disk I could get, basically also the only one available right now besides the super expensive 6TB Seagates. That way I can check for 4Kn compatibility relatively cheaply (click to enlarge images):

If you look closely, you can spot the nice 4Kn logo right there. In case you ask yourselves “Why 4Kn?”, well, mostly cost and efficiency. 4kiB sectors are 8 times as large as classic 512 byte ones. Thus, for the same data payload you need 8 times less sector gaps, 8 times less synchronization markers and 8 times less address markers. Also, a stronger checksum can be used for data integrity. See this picture from [Wikipedia]:


Sector size comparison (Image is © Dougolsen under the CC-BY 3.0 unported license)

Now this efficiency is already there with 512e drives. 512e Advanced Format was supposedly invented, because more than half the programs working with raw disks out there can’t handle variable sector sizes and are hardcoded for 512n. That also includes system firmwares, so your mainboards’ BIOS/UEFI. To solve those issues, they used 4kiB sectors, then let a fast ARM processor translate them into 512 byte sectors on the fly to give legacy software something it could understand.

4Kn on the other hand is the purist, “right” approach. No more emulation, no more cheating. No more 1GHz ARM dual core processor in your hard drive just to be able to serve data fast enough.

Now we already know that Intel controllers won’t work. For fun, I hooked it up to my ASUS P6T Deluxes’ secondary SATA controller though, a Marvell 88SE6120. Plus, I gave the controller the latest possible driver, the quite hard-to-get version You can download that [here] for x86 and x64.  To forestall the result: It doesn’t work. At all. This is what the systems’ log has to say about it (click to enlarge):

So that’s a complete failure right there. Even after the “plugged out” message, the timeouts would still continue to happen roughly every 30 seconds, accompanied by the whole operating system freezing for 1-2 seconds every time. I cannot say for any other controllers like the Marvell 9128 or Silicon Image chips and others, but I do get the feeling that none of them will be able to handle 4Kn.

Luckily, I do already have the controller for my future RAID-6 right here, an Areca ARC-1883ix-12, the latest and greatest tech with PCIe x8 3.0 and SAS/12Gbit ports with SATA/6Gbit encapsulation. Its firmware and driver supports 4Kn fully as you can see in Arecas [specifications]. The controller features an out-of-band management system via its own ethernet port and integrated web server for browser-based administration, even if the system doesn’t even have any OS booted up. All that needs to be installed on the OS then is a very tiny driver (click to enlarge):

Plus, Areca gives us one small driver for many Windows operating systems. Only for the Windows XP 32-Bit NT5.1 kernel you’ll get a SCSI Miniport driver exclusively, while all newer systems (WinXP x64, Windows Vista, 7, 8) get a more efficient StorPort driver. So, plugged the controller in, installed the driver, hooked up the disk, and it seems we’re good to go:

The 4Kn drive is being recognized

The 4Kn drive is being recognized (click to enlarge)

Now, any legacy master boot record (MBR) partition table has a 32-bit address field. That means, it can address 232 elements. With each element being 512 bytes large, you reach 2TiB. So that’s where the 2TiB limit comes from. With 4Kn however, the smallest addressable atom is now eight times as large: 4096 bytes! So we should be able to reach 16TiB due to the larger sector size. Supposedly, some USB hard drive manufacturers have used this trick (by emulating 4Kn) to make their larger drives work easily on Windows XP. When trying to partition the Toshiba drive however, I hit a wall, as it seems Windows disk management is about as stupid as was the FAT32 formatter on Windows 98:

MBR initialization failed

MBR initialization failed (click to enlarge)

That gets me thinking. On XP x64, I can still just switch from MBR to the GPT partitioning scheme to be able to partition huge block devices. But what about Windows XP 32-bit? I don’t know how the USB drive manufacturers do it, so I can only presume they ship the drives pre-partitioned if its one of those that don’t come with a special mapping tool for XP. In my case, I just switch to GPT and carry on (click to enlarge):

Now I guess I am the first person in the world to be able to look at this, and potentially the last too:

fsutil.exe showing a 4Kn drive on XP x64

fsutil.exe showing a native SATA 4Kn drive on XP x64, encapsulated in SAS. Windows 7 would show the physical and logical sector size separately due to its official 512e support. Windows XP always reports the logical sector size (click to enlarge)

So far so good. The very first and most simple test? Just copy a file onto the newly formatted file system. I picked the 4k (no pun intended) version of the movie “Big Buck Bunny”:

Copying a first file onto the 4Kn disks NTFS file system

Copying a first file onto the 4Kn disks NTFS file system

Hidden files and folders are shown here, but Windows doesn’t seem to want to create a System Volume Information\ folder for whatever reason. Other than that it’s very fast and seems to work just nicely. Since the speed is affected by the RAID controllers write back cache, I thought I’d try HD Tune 2.55 for a quick sequential benchmark. Or in other words: “Let’s hit our second legacy software wall” (click to enlarge):

Yeah, so… HD Tune never detects anything above 2TiB, but this? At first glance, 375GB might sound quite strange for a 3TB drive. But consider this: 375 × 8 = 3000. What happened here is that HD Tune got the correct sector count of the drive, but misinterpreted each sectors’ size as 512 bytes. Thus, it reports the devices’ size as eight times as small. Reportedly, this is also the exact way how Intels RST drivers fail when trying to address a 4Kn drive. HD Tune 2.55 is thus clearly hardcoded for 512n. There is no way to make this work. Let’s try the paid version of the tool which is usually quite ahead of its free and legacy counterpart (click to enlarge):

Indeed, HD Tune Pro 5.00 works just as it should when accessing the raw drive. Users who don’t want to pay are left dead in the water here. Next, I tried HDTach, also an older tool. HDTach however reads from a formatted file system instead of from a raw block device. The file system abstracts the device to a higher level, so HDTach doesn’t know and doesn’t need to know anything about sectors. As a result, it also just works:

HD Tach benchmarking NTFS on a 4Kn drive

HD Tach benchmarking NTFS on a 4Kn drive (click to enlarge)

Next, let’s try an ancient benchmark, that again accesses drives on the sector level: The ATTO disk benchmark. It is here where we learn that 4Kn, or generally variable sector sizes aren’t space magic. This tool was written well before the times of 512e or 4Kn, and look at that (click to enlarge):

Now what does that tell us? It tells us, that hardware developers feared the chaotic ecosystem of tools and software that accesses disks at low levels. Some might be cleanly programmed, where most may not. That doesn’t just include operating systems’ built-in toolsets, but also 3rd party software, independently from the operating system itself. Maybe it also affects disk cloning software like from Acronis? Volume shadow copies? Bitlocker? Who knows. Thing is, to be sure, you need to test that stuff. And I presume that to go as far as hard drive manufacturers did with 512e, they likely found one abhorrent hell of crappy software during their tests. Nothing else will justify ARM processors at high clock rates on hard drives just to translate sector sizes plus all the massive work that went into defining the 512e Advanced Format standard before 4Kn Advanced Format.

Windows 8 might now fully support 4Kn, but that doesn’t say anything about the 3rd party software you’re going to run on that OS either. So we still live in a Windows world where a lot of fail is waiting for us. Naturally, Linux and certain UNIX systems have adapted much earlier or have never even made the mistake of hardcoding sector sizes into their kernels and tools.

But now, to the final piece of my preliminary tests: Truecrypt. A disk encryption software I still trust despite the project having been shut down. Still being audited without any terrible security hole discoveries so far, it’s my main choice for cross-platform disk encryption, working cleanly on at least Windows, MacOS X and Linux.

Now, 4Kn is disabled for MacOS X in Truecrypts source code, but seemingly, this [can be fixed]. I also discovered that TC will refuse to use anything other than 512n on Linux if Linux kernel crypto is unavailable or disabled by the user in TC, see this part of Truecrypts’ CoreUnix.cpp:

#if defined (TC_LINUX)
if (volume->GetSectorSize() != TC_SECTOR_SIZE_LEGACY)
  if (options.Protection == VolumeProtection::HiddenVolumeReadOnly)
    throw UnsupportedSectorSizeHiddenVolumeProtection();
  if (options.NoKernelCrypto)
    throw UnsupportedSectorSizeNoKernelCrypto();

Given that TC_SECTOR_SIZE_LEGACY equals 512, it becomes clear that hidden volumes are unavailable as a whole with 4Kn on Linux, and encryption is completely unavailable altogether if kernel crypto isn’t there. So I checked out the Windows specific parts of the code, but couldn’t find anything suspicious in the source for data volume encryption. It seems 4Kn is not allowed for bootable system volumes (lots of “512’s” there), but for data volumes it seems TC is fully capable of working with variable sector sizes.

Now this code has probably never been run before on an actual SATA 4Kn drive, so let’s just give it a shot (click to enlarge):

Amazingly, Truecrypt, another software written and even abandoned by its original developers before the advent of 4Kn works just fine. This time, Windows does create the System Volume Information\ folder on the file system within the Truecrypt container, and fsutil.exe once again reports a sector size of 4096 bytes. This shows clearly that TC understands 4Kn and passes the sector size on to any layers above itself in the kernel I/O stack flawlessly (The layer beneath it should be either the NT I/O scheduler or maybe the storage controller driver directly and the layer above it the NTFS file system driver, if my assumptions are correct).

Two final tests for data integrities’ sake:

Both a binary diff and SHA512 checksums prove, that the data copied from a 512n medium to the 4Kn one is still intact

Both a binary diff and SHA512 checksums prove, that the data copied from a 512n medium to the 4Kn one is still intact

So, my final conclusion? Anything that needs to work with a raw block device on a sector-by-sector level needs to be checked out before investing serious money in such hard drives and storage arrays. It might be cleanly programmed, with some foresight. It also might not.

Anything that sits above the file system layer though (anything that reads and writes folders and files instead of raw sectors) will always work nicely, as such software does not need to know anything about sectors.

Given the possibly enormous amount of software with hardcoded routines for 512 byte sectors, my assumption would be that the migration to 4Kn will be quite a sluggish one. We can see that the enterprise sector is adapting first, clearly because Linux and UNIX systems adapt much faster. The consumer market however might not see 4Kn drives anytime soon, given 512 byte sectors have been around for about 60 years (!) now.

Update 2014-01-16 (Linux): I just couldn’t let it go, so I took the Toshiba 4Kn drive to work with me, and hot plugged it into an Intel ICH10R. So that’s the same chipset as the one I ran the Windows tests on, an Intel X58. Only difference is, that now we’re on CentOS 6.6 Linux running the 2.6.32-504.1.3.el6.x86_64 kernel.  This is what dmesg had to say about my hotplugging:

ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata3.00: ATA-8: TOSHIBA MG04ACA300A, FP2A, max UDMA/100
ata3.00: 732566646 sectors, multi 2: LBA48 NCQ (depth 31/32), AA
ata3.00: configured for UDMA/100
ata3: EH complete
scsi 2:0:0:0: Direct-Access     ATA      TOSHIBA MG04ACA3 FP2A PQ: 0 ANSI: 5
sd 2:0:0:0: Attached scsi generic sg7 type 0
sd 2:0:0:0: [sdf] 732566646 4096-byte logical blocks: (3.00 TB/2.72 TiB)
sd 2:0:0:0: [sdf] Write Protect is off
sd 2:0:0:0: [sdf] Mode Sense: 00 3a 00 00
sd 2:0:0:0: [sdf] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 2:0:0:0: [sdf] 732566646 4096-byte logical blocks: (3.00 TB/2.72 TiB)
sd 2:0:0:0: [sdf] 732566646 4096-byte logical blocks: (3.00 TB/2.72 TiB)
sd 2:0:0:0: [sdf] Attached SCSI disk

Looking good so far, also the Linux kernel typically cares rather less about the systems BIOS, bypassing whatever crap it’s trying to tell the kernel. Which is usually a good thing. Let’s verify with fdisk:

Note: sector size is 4096 (not 512)
WARNING: The size of this disk is 3.0 TB (3000592982016 bytes).
DOS partition table format can not be used on drives for volumes
larger than (17592186040320 bytes) for 4096-byte sectors. Use parted(1) and GUID 
partition table format (GPT).

Now that’s more like it! fdisk is warning me, that it will be limited to addressing 16TiB on this disk. A regular 512n or 512e drive would be limited to 2TiB as we know. Awesome. So, I created a classic MBR style partition on it, formatted it using the EXT4 file system, and mounted it. And what we get is this:

Filesystem            Size  Used Avail Use% Mounted on
/dev/sdf1             2.7T   73M  2.6T   1% /mnt/sdf1

And Intel is telling us that they don’t manage to give us any Windows drivers that can do 4Kn? Marvell doesn’t even comment on their inabilities? Well, suck this: Linux’ free driver for an Intel ICH10R south bridge (or any other that has a driver coming with the Linux kernel for that matter) seems to have no issues with that whatsoever. I bet it’s the same with BSD. Just weak, Intel. And Marvell. And all you guys who had so much time to prepare and yet did nothing!

Update 2014-01-20 (Windows XP 32-Bit): So what about regular 32-Bit Windows XP? There are stories going around that some USB drives with 3-4TB capacity would use a 4Kn emulation (or real 4Kn, bypassing the 512e layer by telling the drive firmware to do so?), specifically to enable XP compatibility without having to resort to special mapping tools.

Today, I had the time to install XP SP3 on a spare AMD machine (FX9590, 990FX), which is pretty fast thanks to a small, unused testing SSD I still had lying around. Before that I wiped all GPT partition tables from the 4Kn drive, both the one at the start as well as the backup copy at the end of the drive using dd. Again, for this test, the Areca ARC-1883ix-12 was used, now with its SCSI miniport driver, since XP 32-Bit does not support StorPort.

Please note, that this is a German installation of Windows XP SP3. I hope the screenshots are still understandable enough for English speakers.

Recognition and MBR initialization seems to work just fine this time, unlike on XP x64:

The 4Kn Toshiba as detected by Windows XP Pro 32-Bit SP3, again on an Areca ARC-1883ix-12

The 4Kn Toshiba as detected by Windows XP Pro 32-Bit SP3, again on an Areca ARC-1883ix-12 (click to enlarge)

Let’s try to partition it:

Partitioning the drive once more, MBR style

Partitioning the drive once more, MBR style

Sure looks good! And then, we get this:

A Master Boot Record, Windows XP and 4Kn: It does work after all

A Master Boot Record, Windows XP and 4Kn: It does work after all (click to enlarge)

So why does XP x64 not allow for initialization and partitioning of a 4Kn drive using MBR? Maybe because it’s got GPT for that? So in any case, it’s usable on both systems, the older NT 5.1 (XP 32-Bit) as well as the newer NT 5.2 (XP x64, Server 2003). Again, fsutil.exe confirms proper recognition of our 4Kn drive:

fsutil.exe reporting a 4kiB sector size, just like on XP x64

fsutil.exe reporting a 4kiB sector size, just like on XP x64

So all you need – just like on XP x64 – is a proper controller with proper firmware and drivers!

There is one hard limit here though that XP 32-Bit users absolutely need to keep in mind; Huge RAID volumes using LUN carving/splitting and software JBOD/disk spanning using Microsofts Dynamic Volumes are no longer possible when using 4Kn drives. Previously, you could tell certain RAID controllers to just serve huge arrays to the OS in 2TiB LUN slices (e.g. best practice for 3ware controllers on XP 32-Bit). Then, in Windows, you’d just make those slices Dynamic Volumes and span a single NTFS file system over all of them, thus pseudo-breaking the 2TiB barrier.

This can no longer be done, as Dynamic Volumes seemingly do not work with 4Kn drives on Microsoft operating systems before Windows 8, or at least not on XP 32-Bit. The option for converting the volume from MBR to GPT is simply greyed out in Windows disk management.

That means that the absolute maximum volume size using 4Kn disks on 32-Bit Windows XP is 16TiB! On XP x64 – thanks to GPT – it’s just a few blocks short of 256TiB, a limit imposed on us by the NTFS file systems’ 32-bit address field and 64kiB clusters, as 232 * 64KiB × 1024 × 1024 × 1024 = 256TiB.

And that concludes my tests, unless I have time and an actual machine to try FreeBSD or OpenBSD UNIX. Or maybe Windows 7. The likelihood for that is not too high at the moment though.

CC BY-NC-SA 4.0 The brave new world of 4Kn hard disks: A test with Windows (XP x64), Truecrypt, HDTune and others (Update: Now with Linux, XP 32-Bit) by The GAT at XIN.at is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

  18 Responses to “The brave new world of 4Kn hard disks: A test with Windows (XP x64), Truecrypt, HDTune and others (Update: Now with Linux, XP 32-Bit)”

  1. Great read !

    IsoBuster is one of those 3rd party tools that does low level communication, but I developed it such that it should work well with 4K (native) sectors as well. I say *should* because I have never had the chance to actually test this.

    Yesterday and today I have been looking to buy a 4Kn drive, but the only one I could find, that wasn’t too expensive, was a SAS drive and I need a SATA drive. Not too expensive because I probably will never use the drive for anything else than a few tests with the software, since I use only laptops these days.

    Anyway, if you ever plan to do more tests I would love to get feedback on IsoBuster, if there are issues etc. so that I can fix them and it’s probably a great tool for your investigations as well, to see the partition layout, NTFS, ExFAT, UDF information etc. and so on.

    • Hello Peter,

      Ah, crap. The 4Kn drive was plugged into a video processing workstation (CentOS Linux) and EXT4 formatted. Reason: While Intel controller drivers for Windows still can’t do 4Kn even today, the Linux kernel drivers have no problem with that. So it’s in use and I can’t easily remove it for examination in some Windows VM.

      Also, my only 4Kn capable hardware controller is now in use for my main RAID-6 storage and video processing subsystem, so I can’t use that physical controller for 4Kn tests anymore either (the RAID is based on 512e drives unfortunately).

      One possible way might be to use >2TiB USB drives. A lot of those still present 4Kn to the OS for Windows XP compatibility for larger drives. Mostly it’s 512e drives with the USB controller adding yet another emulation layer, so it becomes “true 4Kn” for the OS. And those are cheap as well. I just can’t name a model off the top of my head…

      The cheapest SATA 4Kn drive locally available (Austria, EU) would be the Seagate Enterprise Capacity 3.5 HDD 128MB 4Kn 2TB (“ST2000NM0004”) at 139,06€ lowest price and 162.89€ lowest price with immediate availability. Not exactly “cheap”, yeah, but maybe look out for that one? At least it’s normal SATA. But remember, you need a SATA controller with 4Kn capable drivers for Windows! I am not up-to-date when it comes to that…

      Sorry for not really being able to help out at the moment, I kinda regret that. :(

      • Hi Michael,

        > Mostly it’s 512e drives with the USB controller adding yet another emulation layer

        I had no idea ? I have a 3TB 512e drive here. I find it strange that XP has issues with 512e ? However I have no XP system anymore, only emulated via VM VirtualBox. I’ll see if I can play with that.

        I’ll look into the models you mentioned. Not cheap, but doable. The ones I found in Belgian online stores were more expensive.

        I had sort of given up on the physical hard drive hunt, so I decided to make 4Kn *.VHDX files in Windows10. I’m in the middle of testing that at the moment, but so far no problems with MBR & GPT in combination with UDF, NTFS, FAT/32 and ExFAT. Patting myself on the back at the moment :)
        Aside from working on the mounted volumes, I can now also load VHDX files in IsoBuster directly (implemented in the latest and greatest: http://www.isobuster.com/beta/ ) so that works great to test my native 4K support.

        PS. IsoBuster also supports EXT4, but doesn’t run in a Linux environment, only Windows.

        > you need a SATA controller with 4Kn capable drivers for Windows

        Right ! Reading about all the issues you encountered it’s probably best I stick with my emulated tests for the time being. I’m quite confident the real deal will work as well then.

        Thanks for the Hardware tips and you *were* of help, and if you ever decide to use IB as a tool in your published tests, prod me for a license. Cheers, Peter.

        • Hey,

          I had no idea ? I have a 3TB 512e drive here. I find it strange that XP has issues with 512e?

          XP 32-bit can work with 512e just fine, minus some possible alignment issues. The problem is the master boot record with its 32-bit address field. 232 = 4 binary billion sectors addressable, right? That’s 2TiB when each logical sector is 512 bytes large. As soon as you boost the sector size to 4096 bytes, the address space grows automatically, to 16TiB. There are always two ways of increasing addressable space: 1.) Increase the address field, e.g. from 32-bit to 64-bit or 2.) increase the smallest addressable atoms’ size, e.g. from 512b to 4k.

          And that’s why Windows NT5.1 / XP 32-bit needs 4Kn for making drives >2TiB fully usable. Because it can only use 32-bit MBR partitions. Windows NT5.2 / Server 2003 / XP x64 doesn’t have that problem, because it can use 64-bit GPT, at least for data volumes.

          Ah yes, I’ll go back to work starting tomorrow, I may be able to give you the model name of a cheap Western Digital (or was it a cheap Intenso? Does that brand even exist in all of Europe!?) USB drive that poses as 4Kn. That might be helpful for you. But I’ll have to retest that one just to make sure. Uh, I hope I still have one lying around in my office…

          But if you can create virtual 4Kn images on any storage backend, that’s also a sweet option of course.

          As for your offer regarding IsoBuster: Thanks a lot! I’ll have to politely decline for now though, I don’t wanna rob you of a license without any actual article planned to make it worthwile. This would call for something like a comparison between data recovery tools like your IsoBuster, GetDataBack, Testdisk and many others which can match IsoBusters’ seemingy wide array of applications, but I fear I can’t find the time to do that right now. :)

          Well, I’ll let you know about that USB drive, as long as they’re not all out in the field by now!

          • Thanks Michael,

            > Because it can only use 32-bit MBR partitions

            Ah right … no GPT yet.

            > I may be able to give you the model name of a cheap …

            Thanks. Take your time, I’m happy with emulation at the moment :)
            This morning the pressure was still on … now I feel better :-)

            > But if you can create virtual 4Kn images on any storage backend, that’s also a sweet option of course.

            Yes it turns out to work well.

            > a comparison between data recovery tools

            No, I wasn’t fishing for anything like that actually. I just meant that in your above analysis the use of IsoBuster *could* have been useful. So *should* you do something again were the use of IB could be useful, you never know, prod me, that’s all.

            Have a nice evening Michael.

            • Morning Peter,

              Ok, I still had one left! It turned out to be an Intenso Memory Point 4TB drive, Intenso part number “6031212”. This is what the drive reports on Linux:

              $ dmesg | grep -e sd.*4096.* | uniq
              sd 14:0:0:0: [sdd] 976754646 4096-byte logical blocks: (4.00 TB/3.63 TiB)
              # fdisk -l /dev/sdd | grep -i "sector size"
              Note: sector size is 4096 (not 512)
              Sector size (logical/physical): 4096 bytes / 4096 bytes

              And here’s what it looks like on Windows XP 32-Bit, 4TB are fully addressable as well, in this case for an English Windows with the drive formatted and mounted to “X:”:

              C:\>fsutil fsinfo ntfsinfo X: | findstr /I /R "bytes.*per.*sector"
              Bytes Per Sector  :               4096

              Looks like a win! If you wish for me to run any specific tests on that drive, I can also do it. It’s just that my choice of operating systems is a bit limited. But I think what I can do is native WinXP 32-bit (with POSReady2009 hack) and maybe USB passthrough to several VMs: XP x64/Server 2003, Windows 7 Pro x64 and Windows 10 Pro x64. So if you need any specific tests run, let me know! :) I have at least one physical machine avaiable with a 4Kn drive now after all, even if only with an ancient OS on it. But IsoBuster seems to support XP just as well anyway.

              • Hi Michael,

                That’s really cool.

                I’d appreciate it if you can run a few basic tests. Like:
                – Is the drive found by IsoBuster,
                – Does IsoBuster parse the MBR (I suppose no GPT) properly ?
                – Is or are the file-system(s) in the partition(s) properly seen ?
                – Do files match (e.g. a binary compare of what IsoBuster extracts against what Windows sees).
                Stuff like that !

                I feel bad asking you to extensively test, especially since I can do this myself via *.vhdx files, but whatever you feel like a good test to see if 4K sectors are properly supported in IsoBuster is great !

                Knowing that 4kn drives (the real hardware) is properly supported is enough and much appreciated.

                If you do, use the latest and greatest (uploaded about an hour ago) : http://www.isobuster.com/beta/ (IsoBuster 3.8 Beta).
                Because I found an issue with NTFS. Namely for smaller files that fit in the MFT record. They were not always correct (slightly corrupted), because NTFS has a weird mechanism to ‘patch’ (fixup) MFT records with a few bytes and IsoBuster used the sector size (4K) to apply the mechanism, yet it turns out NTFS uses hardcoded 512 bytes for that mechanism.

                Please send me an email for a Key ! Cheers.

                • Hey,

                  Ok, got it! I’m not completely sure I can do this by tomorrow, given that I’ll have an appointment which will consume all morning I guess, could even take a bit longer. Maybe in the afternoon, but surely on Friday!

                  Currently, the drive is MBR partitioned. I can also re-do all tests with GPT as well, if desired.

                  Ah yes, and I’ll drop you an email! ;)

                • Hello again Peter,

                  Ok, here we go! I’ve installed the 3.8 beta version and activated it. I decided to unmount the drive first, so it’s no longer visible to the user or any regular user space software, while doing the restore work. So, let’s start, first by picking the drive:

                  Picking the 4Kn drive in IsoBuster 3.8b
                  The 4Kn drive is clearly visible (click to enlarge)

                  Now let’s take a peek inside, shall we?

                  Traversing the file system structure (here: NTFS with 4kiB cluster size) seems to work just fine. The high LBAs / sector numbers of the small files seems to suggest that they were stored directly inside of the $MFT. (click to enlarge)

                  Let’s see if we can also restore some data:

                  Picking a restore target
                  The restore target drive we’re picking is an older 512n disk

                  Restoring data from 4Kn to 512n disks
                  Restoring data… Looks good so far?

                  Now, for the verification i couldn’t resort to my regular sha512sum, some weird library problem here, so i picked a GUI for that. But it’s highly solid SHA512 alright, and…

                  Comparing IsoBuster-restored data with data from the 4Kn source
                  The checksum verification shows, that both the large ISO file as well as the tiny text files with just 3-4 bytes content (1-2 digits plus two bytes for a single CRLF line break) restored perfectly from 4Kn to 512n! (click to enlarge)

                  Looks real nice! Now, for the final part I wanted to see how IsoBusters’ hexadecimal sector view would look like with both 512n (512e would look similar) and 4Kn. Regular 512n comes first:

                  Sector 63 on a 512n drive
                  IsoBuster is showing us sector #63 of a 512n drive, which is where NTFS partitions traditionally start when created by Microsoft tools – German ones in the given case, as one can see! This sector is 512 bytes large. (click to enlarge)

                  And now, the 4Kn drive:

                  Sector 63 of a 4Kn drive
                  Clearly, we can see the difference here; The 4Kn sector is eight times as large, and IsoBuster is handling that case neatly! (click to enlarge)

                  So there you have it! It’s looking pretty damn good so far! 8-) :mrgreen:

  2. Great article! I was looking at the new 8tb Seagate enterprise drives and wondering which one to get – the 4kn or 512e. One thing to consider is that the 512e version has PowerBalance technology, whatever that is. I am going to be using for storage of media files, for a critical business server, but with the ability to take the drive out and plug into a usb 3.0 Sata Dock Adapter, so I need to make sure it’s going to be compatible. I like the 4kn idea and keeping it simple without having to go through the emulation. But my pc’s and laptops that I need to be compatible are everything from Windows 7 64 bit to Windows 10 and I do use VirtualBox too with XP 32. I suppose for compatibility I should get the 512e version, but I’d rather get the 4kn. Too many questionable variables at this point, though.

    Thanks for the article!

    • Hi Fixer11,

      My guess is that the parts in the NT kernel responsible for handling physical block devices are ancient. I mean, in the meantime I was able to confirm that even Windows 2000 can use variable sector sizes – and thus 4Kn! I haven’t tried it myself, but somebody told me it even works with NT4…

      I mean, this stuff might even be original DEC code (the guys who developed the Alpha CPU architecture) before [the stuff became what is now essentially the NT kernel]. Even in the modern age, the kernel developers are probably the most competent at Microsoft, even if that’s just a gut feeling of mine.

      But of course, the controller drivers will be the main problem, even if the OS kernel is fine. I went for the Areca, and it can do the stuff just fine, but it ain’t trivial with USB docks and other “cheap” hardware like that. That Intel fucks this up is especially disappointing (they STILL don’t support 4Kn on Windows!), given that Linux and BSD ICH drivers can do it just fine. I mean, Intel should just take that code and backport it into their own Windows drivers! But nooo… pfh.

      It’s quite sad, but you’re still much better off with 512e, even today. At least on Windows, especially given your use case. Somebody should really go ahead and tell Intel, Marvell, Silicon Image and some others to wake up already…

      • Thanks for your input. 512e it is. At least for now, until Intel gets this sorted. I’ve had so many ridiculous battles with Intel RST when I got my first 3tb HDD…It’s hard to stay on the cutting edge of technology. Always some piece of the puzzle that just doesn’t fit!

      • What about 4Kn support on AMD in Windows?

        • Hi demon52,

          I can’t prove anything by myself right now, because my AMD 990FX platform is currently a production machine running FreeBSD UNIX, so I can’t change its OS or play around with any parallel OS installs right now. It’s loaded heavily most of the time as well.

          I took a look at some AMD FM2 (not sure which chipset) Windows RAID drivers from Foxconn though, [see here].

          When you unpack that RAID.zip file, you’ll find two subfolders. Open the file Legacy_Driver_6.1.3.035\ReadMe.rtf!

          There you’ll find the following statement in its revision history:

          RAID driver for AMD chipsets

          – Added 4KN Drive Support
          – Port Multiplier Support
          – Other minor Bug Fixes

          That seems to suggest at least some AMD storage drivers for Windows do support 4Kn disks. The same information can be obtained from the Crimson chipset drivers released at AMDs’ directly, but you have to search for the correct ReadMe.rtf after unpacking the installer with something like 7zip (yes, it works on that .exe file). It’s basically the same document. Strangely, that info can only be found for the RAID drivers, but not for the normal AHCI drivers. Those don’t even have any revision history or changelogs, or none that I can find at least.

          So based on that, I’m gonna say it’s rather likely to work, but I can’t be sure!

          I’m sorry, but I don’t have anything definitive right now. You could try to ask AMDs’ [support community] though!

  3. Wow! Great article! :-D

    (Serial Attached) SCSI drives sometimes have different sector sizes, but I’m not sure how much gets through the controller, or even out of the drive. There are sizes of 512, 520 and 528 bytes.
    http://majzel.blogspot.nl/2012/05/520-and-528-byte-sectors.html has some more information.

    BTW, what kind of OS are you going to run with that Areca controller? You know my stance on ZFS ;-)
    ZFS doesn’t care what the sector size is, and I wish my controller (LSI 1068e onboard) would know how to deal with 4K sectors. Installing on 512e sectors needs a hack to get the alignment right.

    • Hey,

      The OS is going to be XP x64. That may not stay like that forever, but in the future it may be anything really. I still have not decided on what to do after the XP x64 fallout in June/July 2015. By the way, I will update the article with Linux information (on a regular onboard controller!) in a few minutes! The results should make Intel pretty ashamed…

      As for the larger sectors, they also exist for SAS 4Kn (4096, 4112, 4160 and 4224 bytes). But that won’t affect the logical sector size as presented to the OS. Those drives can be low-level formatted to the higher sector sizes by special storage appliances like made by EMC² to accomodate additional checksums for their proprietary RAID solutions. Usually, the storage appliance would format it like that for you. After that’s done, you cannot put it back into a regular PC anymore, need to do another low-level format to make a 4096 byte drive out of an 4160 byte one. Or a 512 byte drive out of a 528 byte one.

      The Areca ARC-1883ix-12 cannot make use of such extra checksums, and it won’t do any low-level formats, so I’ll rely on regular RAID-6 with ECC and regular sector-level checksums with 4096 byte sectors. That’s, IF i decide to buy 4Kn drives. But I hate alignment problems just as much as you (align RAID stripes, align partitions and file systems, gnaah!). So from what I’m seeing, 4Kn seems to be the better option here when compared to 512e. So maybe I’ll get the Seagate 6TB 4Kn SAS drives. We’ll see. I keep pushing back the upgrade schedule. The very first plan had December 2013 in mind. ;) No we’re in 2015 already…

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre lang="" line="" escaped="" cssfile="">