On Apr 3 10:14, Corinna Vinschen via Cygwin wrote:
>
> https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntddk/ns-ntddk-_file_fs_sector_size_information
>
> If the filesystem is local and SSINFO_FLAGS_NO_SEEK_PENALTY is set, we
> could stick to 64K.
>
> Otherwise the PhysicalBytesPerSectorForPerformance member might be
> helpful I guess. Needs checking, of course.
It's not helpful. This is the output for NTFS:
(gdb) p ffssi
$5 = {LogicalBytesPerSector = 512, PhysicalBytesPerSectorForAtomicity = 512,
PhysicalBytesPerSectorForPerformance = 512,
FileSystemEffectivePhysicalBytesPerSectorForAtomicity = 512, Flags = 11,
ByteOffsetForSectorAlignment = 0, ByteOffsetForPartitionAlignment = 0}
D'oh
> If this isn't any good, we can still fallback to
> FILE_FS_FULL_SIZE_INFORMATION as in fhandler_base::fstatvfs_by_handle,
>
> https://cygwin.com/cgit/newlib-cygwin/tree/winsup/cygwin/fhandler/disk_file.cc#n661
So ffsi.BytesPerSector * ffsi.SectorsPerAllocationUnit is it then.
But:
> On Apr 3 00:35, Martin Wege via Cygwin wrote:
> > While I can understand the motivation, FAT32 on multi-GB-devices
> > having 64k block size, and Win32 API on Win95/98/ME/Win7 being
> > optimized to that insane block size, it is absolutely WRONG with
> > today's NTFS and even more so with ReFS.
So this has supposedly changed with Win8. Where's that publically
documented?
Corinna
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
