X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C7FF73846420
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1712144750;
	bh=MDVVUT+DYcTS/i1bQLeMCCaQ3+H3/ot4yixvja0HBRU=;
	h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe:
	 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:
	 From;
	b=YfJiTPimCwAUk2ltBZ70gaf5jrARnmTcQ+yOjA/AKwfCHcwc7qH3jdKl7xd/dCfoN
	 q+9mPLt7DnjksZ/kq9GavAI2U8F9ZnhIdvGGKJaRA/0QkThaIDy33wp7ixJTQ5rGSR
	 RC0/+WbLYC6jyKBsYZ1Oqxo/W6J1OnkdEfGA73VQ=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 602683847718
Date: Wed, 3 Apr 2024 13:44:49 +0200
To: cygwin AT cygwin DOT com
Subject: Re: Cygwin&Win32 file prefetch, block sizes?
Message-ID: <Zg1BMelQusmzuhmK@calimero.vinschen.de>
Mail-Followup-To: cygwin AT cygwin DOT com
References: <CANH4o6Mxai4_C=d1P93Prrimb8_H=trTwm-Eg+WBwpomN3tNJw AT mail DOT gmail DOT com>
 <ZgwFNde2z804koS_ AT calimero DOT vinschen DOT de>
 <CANH4o6P8cts9TJgpdjR4mi+sj2YvuDa=d49XLcEVvYnRB81KRw AT mail DOT gmail DOT com>
 <Zg0P-JRyEyiyZJCP AT calimero DOT vinschen DOT de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <Zg0P-JRyEyiyZJCP@calimero.vinschen.de>
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.30
Precedence: list
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe: <https://cygwin.com/mailman/options/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From: Corinna Vinschen via Cygwin <cygwin AT cygwin DOT com>
Reply-To: cygwin AT cygwin DOT com
Cc: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT 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

-- 
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