This is not necessarily the case, and almost certainly wouldn't be the case for most installations/migrations. "Standard NTFS" would very *rarely* be using an allocation unit size of 512 bytes on most modern systems. The way NTFS figures out the default allocation unit size to use on a particular disk or volume-set is quite simple, if you can remember the "kilobyte to gigabyte" correlation that exists. Specifically, NTFS uses an allocation unit size of half a kilobyte on disks of half a gigabyte or less (rare these days, right? :-)), one kilobyte on disks of one gigabyte or less, two kilobytes on disks of 2 gigabytes or less, and 4 kilobytes thereafter. Unless you manually created your NTFS file systems using something along the lines of a:

to override the default and force an allocation unit size of 512 bytes, then your NTFS file system will likely be using the same default allocation unit size as WAFL uses (4Kb).

Also, don't forget the swings-and-roundabouts issues that are normally associated with small AU sizes. There's a reason that AU sizes generally get bigger as file system sizes increase. Smallers AU's cause most file systems to burn more AU's to keep track of the AU's, if you see what I'm saying? :-) It is often hard at best, and impossible at worst to accurately account for such matters in application level scripts that just read "visible stuff", but I don't think that you'll find that WAFL and NTFS are fantastically different space burners for the vast majority of situations.* If you do, well.... let me know, *especially* if WAFL proves far superior.... :-)