I would like to ask whether the current version of VeraCrypt supports 4Kn hard drives (disks with native 4096 byte sectors). I have only found [this thread], which remained unanswered though.
I know people have tried this already, and I myself managed to make it work even with TrueCrypt. But years ago, a VeraCrypt supports person (or maybe developer?) told me that this is not expected to work, and may cause problems. According to that person, parts of the source code were hard-wired for 512 byte sectors.
Is 4Kn officially supported by now? And if yes, since which version of VeraCrypt?
I would like to go for 4Kn to get rid of at least some of the alignment headaches caused by 512e disks in RAID arrays with VeraCrypt on top.
Also: If the VeraCrypt header is written to the beginning of a GUID partition sitting on a 4Kn disk or array of disks, will the data area still sit at an offset of +128kiB from the start of the partition?
So, if the partition were aligned to +2048kiB (LBA 511 in the 4Kn case), would the data area of the VeraCrypt volume and hence the file system inside of it start at +2176kiB (LBA 544) counted from the start of the physical disk in such a case?
Thank you very much!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Alright, thanks. I just checked my mail database, and the developer who has responded to my original query about 4Kn support several years ago was Mounir Idrassi as well. Meanwhile I've sent them an eMail to their official address as well (before reading your reply), so I'll wait for a response for a while.
If I receive nothing for 2-3 weeks, I'll try to email him directly, as I still have his address.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Because of this unclear situation, I've built my current RAID-6 array with 512e disks, but aligning everything properly feels like rocket science to me considering the stack... 512e with 4kiB sectors underneath, GPT offset, size/offset of the VeraCrypt header (is it larger on 4Kn disks than it is in 512n/512e disks?), RAID strip size, etc.
Booting might be even trickier, it's only theoretically possible with 4Kn on BIOS+MBR setups, but I doubt BIOSes and bootloaders would be implemented intelligently enough especially on the Microsoft side of things. So how do UEFI and GPT handle booting from 4Kn? I have no idea. It problably depends on the individual UEFI firmware implementation?
It would be really nice to have this clearly documented, and of course supported in the first place. 4Kn drives have been around for more than half a decade (!) after all, so it's been a while.
I didn't manage to extract the information from the source code, as I found it too hard to understand.
Here is what Mounir Idrassi wrote to me about this issue in the year 2015, which is a while ago (I hope he won't be mad at me for quoting his eMail here):
"Thank you for your interest in the 4K issue in VeraCrypt and TrueCrypt. In the comment you are referring to, I said that "low level read/write operations always uses 512 bytes". This is true since the device drive code on Windows uses 512 as unit for XTS encryption but also as unit for read/write data fragment handling: in the code look for the constant ENCRYPTIONDATAUNITSIZE and you'll see that it has the value 512. This same constant is used in the function EncryptionThreadPoolDoWork (file EncryptionThreadPool.c, line 474) as a unit for data fragments and this is where the issue comes with certain drives: fragments will not be always multiple of 4096 and writing them in such case will cause trouble with certain type for firmware implementation.
You drive seems to handle this kind of situations very well but this is not the case of all drives.
For file containers, TrueCrypt and VeraCrypt always use 512 as sector size for the associated volume (constant TCSECTORSIZEFILEHOSTEDVOLUME) for compatibility reason on all drives. On 4K drives, this causes a loss in performance because of the buffering needed to align operations but there is no solution since the file container can be copied between different type of drives."
I will eMail him again right now. Let's see whether he'll have the time to respond once more.
Last edit: Michael Lackner 2021-11-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
you can also try DiskCryptor, it doesn't work for me but is said to support larger sector sizes. but do it on test system partition first as for me it was bugged and didn't decrypted when I entered correct password, so I had to install windows on another partition to install DC and decrypt drive from it
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would like to ask whether the current version of VeraCrypt supports 4Kn hard drives (disks with native 4096 byte sectors). I have only found [this thread], which remained unanswered though.
I know people have tried this already, and I myself managed to make it work even with TrueCrypt. But years ago, a VeraCrypt supports person (or maybe developer?) told me that this is not expected to work, and may cause problems. According to that person, parts of the source code were hard-wired for 512 byte sectors.
Is 4Kn officially supported by now? And if yes, since which version of VeraCrypt?
I would like to go for 4Kn to get rid of at least some of the alignment headaches caused by 512e disks in RAID arrays with VeraCrypt on top.
Also: If the VeraCrypt header is written to the beginning of a GUID partition sitting on a 4Kn disk or array of disks, will the data area still sit at an offset of +128kiB from the start of the partition?
So, if the partition were aligned to +2048kiB (LBA 511 in the 4Kn case), would the data area of the VeraCrypt volume and hence the file system inside of it start at +2176kiB (LBA 544) counted from the start of the physical disk in such a case?
Thank you very much!
Please accept my apologies for pushing this, but I'm still looking for this information, and I still don't understand the source code enough. ;)
Thanks!
And (almost) another year since the last push, so I'll allow myself to push this again, as it still remains unanswered.
Thanks.
Best keep a look out to see when the VeraCrypt developer Mounir IDRASSI is online; see if he's replied to forum posts recently.
Alright, thanks. I just checked my mail database, and the developer who has responded to my original query about 4Kn support several years ago was Mounir Idrassi as well. Meanwhile I've sent them an eMail to their official address as well (before reading your reply), so I'll wait for a response for a while.
If I receive nothing for 2-3 weeks, I'll try to email him directly, as I still have his address.
Same request from me, I also have 4Kn hard disk and can't encrypt system partition :/
Because of this unclear situation, I've built my current RAID-6 array with 512e disks, but aligning everything properly feels like rocket science to me considering the stack... 512e with 4kiB sectors underneath, GPT offset, size/offset of the VeraCrypt header (is it larger on 4Kn disks than it is in 512n/512e disks?), RAID strip size, etc.
Booting might be even trickier, it's only theoretically possible with 4Kn on BIOS+MBR setups, but I doubt BIOSes and bootloaders would be implemented intelligently enough especially on the Microsoft side of things. So how do UEFI and GPT handle booting from 4Kn? I have no idea. It problably depends on the individual UEFI firmware implementation?
It would be really nice to have this clearly documented, and of course supported in the first place. 4Kn drives have been around for more than half a decade (!) after all, so it's been a while.
I didn't manage to extract the information from the source code, as I found it too hard to understand.
Here is what Mounir Idrassi wrote to me about this issue in the year 2015, which is a while ago (I hope he won't be mad at me for quoting his eMail here):
"Thank you for your interest in the 4K issue in VeraCrypt and TrueCrypt. In the comment you are referring to, I said that "low level read/write operations always uses 512 bytes". This is true since the device drive code on Windows uses 512 as unit for XTS encryption but also as unit for read/write data fragment handling: in the code look for the constant ENCRYPTIONDATAUNITSIZE and you'll see that it has the value 512. This same constant is used in the function EncryptionThreadPoolDoWork (file EncryptionThreadPool.c, line 474) as a unit for data fragments and this is where the issue comes with certain drives: fragments will not be always multiple of 4096 and writing them in such case will cause trouble with certain type for firmware implementation.
You drive seems to handle this kind of situations very well but this is not the case of all drives.
For file containers, TrueCrypt and VeraCrypt always use 512 as sector size for the associated volume (constant TCSECTORSIZEFILEHOSTEDVOLUME) for compatibility reason on all drives. On 4K drives, this causes a loss in performance because of the buffering needed to align operations but there is no solution since the file container can be copied between different type of drives."
I will eMail him again right now. Let's see whether he'll have the time to respond once more.
Last edit: Michael Lackner 2021-11-22
you can also try DiskCryptor, it doesn't work for me but is said to support larger sector sizes. but do it on test system partition first as for me it was bugged and didn't decrypted when I entered correct password, so I had to install windows on another partition to install DC and decrypt drive from it
I'm trying to solve diskcryptor issue, but it's propably using VeraCrypt bootloader, and it's probably the cause :/