ntfsclone (ntfsprogs) utility won't convert between partitions of different sector-size (e.g.: 512B to 4KB, or vice-versa)

[mzcs]

a Few Days Ago I've Been Fiddling Quite a Bit With Cloning a NTFS Partition, From an Older (512B Sectors) To a Newer (4KB Sectors) SSD, To Preserve a 'Windows 10' OS Setup In a Good Working State.

Thru Much Experimentation (I've Used 'SystemRescueCD v10.02/amd64' Dist.), I've Discovered That 'Windows 10' OS Recognize NTFS Partitions, Cloned Between Different Sector-Sized Drives - With No Related Conversion, As Damaged & Unusable : Classifying These as 'RAW' (Unformatted) .

a Related Conversion Option, Added To 'ntfsclone' Utility, Would Make It Usable For Such Tasks Too, Removing The Need To Turn To Proprietary-Software Tools (Some Unreliable and/or Pricey)... Given The Lack of a Usable F/OSS Alternative ! :)

[Super-Pizza]

I’ve had the same issue cloning from a NVMe drive to a SATA SSD. The partition becomes unusable in windows

[unsound]

I can see how this can be a problem. However sometimes you can't trivially convert an NTFS volume from one sector size to another, but other times you can. I've created a patch to add a new option to ntfsclone, --adjust-sector-size, which adjusts the sector size to suit the target device if it's possible to do so in a simple non-destructive manner: https://github.com/tuxera/ntfs-3g/commit/1c19e59ff723a8ce88b9f857c419d3c1ca56abb6 Feedback would be appreciated. I've tested this only with a few very simple test volumes.

Patch: 0001-ntfsclone.c-Add-option-to-adjust-NTFS-sector-size-af.patch

[jpandre]

@unsound maybe you should use ioctl(BLKPBSZGET) instead of ioctl(BLKSSZGET) to get the physical sector size, see https://mail.gnu.org/archive/html/bug-parted/2012-10/msg00018.html (I have no 4k sectored disk and cannot check the difference).

[mzcs]

@unsound: 1st, I'd Like To Say a Big Thank You ! :)

2nd, Until I'd Get To Test It Myself ( On a Computer I Can Compile 'ntfsclone'... ) , I'd Like To Share My Idea of a Test Case : I) Creating a New NTFS On a 512B-Sector Disk Partition. II) Unpacking a Huge Source Archive ( +1M Files of Many Different Sizes, Some Recent 'gcc' - Perhaps ? ) Onto It. III) Utilizing 'ntfsclone', With The New 'adjust-sector-size' Patch, To Clone/Convert It To a 4KB-Sector Disk Partition. IV) Comparing The Hash of Every File (e.g.: by 'SHA1') On The Cloned/Converted NTFS - With It's Archived Counterpart.

On 'Windows', I Find 'Arsenal Image Mounter' As a Very Handy Tool For Such Experiments (Just Be Sure To Select The Desired Sector-Size Upon Image Mounting). While On 'Linux', 'losetup -f -b 512 imagefile' (or '-b 4096') Is Just As Useful :)

[unsound]

@jpandre:

@unsound maybe you should use ioctl(BLKPBSZGET) instead of ioctl(BLKSSZGET) to get the physical sector size, see https://mail.gnu.org/archive/html/bug-parted/2012-10/msg00018.html (I have no 4k sectored disk and cannot check the difference).

Thanks for checking. I'll have to validate what Windows does here, but from what I recall from memory the sector size stored in the NTFS boot sector is the logical sector size (e.g. BLKSSZGET), not the physical sector size (e.g. BLKPSSZGET), in which case the call to ntfs_device_sector_size_get should produce the right result. The physical sector size is mostly useful for optimizing alignment of data and partitions to avoid performance loss on emulated 512-byte sector drives.

(In fact if the physical sector size was being used in the NTFS boot sector then you couldn't move volumes between native 512-byte sector drives and emulated 512-byte sector drives with 4k physical sector size so that wouldn't make much sense from a practical perspective since the whole selling point of these drives is to maintain compatibility with 512-byte sector drives.)