From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <corinna@sourceware.org>
Received: by sourceware.org (Postfix, from userid 2155)
	id 602683847718; Wed,  3 Apr 2024 11:44:51 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 602683847718
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1712144691;
	bh=WM9yhBzNNbC9VQmdYv3xpHRp2MGxzEIeihD0+X9G22k=;
	h=Date:From:To:Subject:Reply-To:References:In-Reply-To:From;
	b=HMbGltjX5XOFjSZo9WofUD74QtnLPA1EB3nreUy7JNBC72X+hbvDhry8f9VFxkN1n
	 ESpQT6GNH9EgT5X8ERpSUBycTmhz/XwIIl9kyZNLPgU/CWB1cJIwS9MNEgoYmmqFnj
	 NYXAYth7l9ZLYtlnWgNlb+XFehRAN2e+ZymrqgG4=
Received: by calimero.vinschen.de (Postfix, from userid 500)
	id 65B04A80C2F; Wed,  3 Apr 2024 13:44:49 +0200 (CEST)
Date: Wed, 3 Apr 2024 13:44:49 +0200
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: Cygwin&Win32 file prefetch, block sizes?
Message-ID: <Zg1BMelQusmzuhmK@calimero.vinschen.de>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
References: <CANH4o6Mxai4_C=d1P93Prrimb8_H=trTwm-Eg+WBwpomN3tNJw@mail.gmail.com>
 <ZgwFNde2z804koS_@calimero.vinschen.de>
 <CANH4o6P8cts9TJgpdjR4mi+sj2YvuDa=d49XLcEVvYnRB81KRw@mail.gmail.com>
 <Zg0P-JRyEyiyZJCP@calimero.vinschen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <Zg0P-JRyEyiyZJCP@calimero.vinschen.de>
List-Id: <cygwin.cygwin.com>

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