From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <corinna@sourceware.org>
Received: by sourceware.org (Postfix, from userid 2155)
	id 9E1873858CDB; Fri,  1 Dec 2023 10:43:20 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9E1873858CDB
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1701427400;
	bh=FYahrQDCNsf8zCLYIhzwx33XwBKZ35sS+i/odSKQhvY=;
	h=Date:From:To:Subject:Reply-To:References:In-Reply-To:From;
	b=v31eZRsaZNfIrUy/nC9+nf4yvHtjDeI1kCxH7DngxW0kLk7dOm80GroMvNOIyn6M4
	 jtf72wXTtnlEnVwbWFTkzgY5AOapSFRbT/jZNnAcLnhNrLwzZMeBlEk4E+v7X+vdao
	 cbh6/Ucsj/UQQiO9E/CvS5MERt7RlUbrcGeg4gEw=
Received: by calimero.vinschen.de (Postfix, from userid 500)
	id CE396A80C05; Fri,  1 Dec 2023 11:43:17 +0100 (CET)
Date: Fri, 1 Dec 2023 11:43:17 +0100
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: Comment about "Cygwin: sparse support: enable automatic
 sparsifying of files on SSDs", extend feature to VMware/qemu disks?
Message-ID: <ZWm4xf0yfNjYqL-V@calimero.vinschen.de>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
References: <CALXu0Udckh5XVXr23yaz1Fg1DoJ_12jE+XKo-jukDPoeL_vdZA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CALXu0Udckh5XVXr23yaz1Fg1DoJ_12jE+XKo-jukDPoeL_vdZA@mail.gmail.com>
List-Id: <cygwin.cygwin.com>

On Dec  1 11:12, Cedric Blancher via Cygwin wrote:
> Good morning!
> 
> Small comment about 3.5.0 commit "Cygwin: sparse support: enable
> automatic sparsifying of files on SSDs"
> https://cygwin.com/git/?p=newlib-cygwin.git;a=commit;h=832e91422c4ae9b2dcd0c307779f3dd53ee9c0ac
> 
> Can this functionality be extended to VMware and QEMU virtual disks, please?

Not without a complete rewrite and lots of slowing down code.

  VMware and QEMU virtual disks are not exposed to the OS as VMware and
  QEMU virtual disks as far as the volume and filesystem information is
  going.  They are just some arbitrary harddisks managed by some
  arbitrary driver.

  What Cygwin gets to see is that you want to access a file on some
  disk.  It opens the file and fetches volume information.  So it finds:

  - The filesystem returns the FILE_SUPPORTS_SPARSE_FILES

    So we can create sparse files.

  - The volume returns the SSINFO_FLAGS_NO_SEEK_PENALTY flag.

    So we're on a drive having no seek penalty.  This is *probably*
    an SSD, but may be some other type of drive.

That's it!

So the decision made is now:

- Does the current file action (fallocate, write after lseek)
  create a hole in the file which is big enough to fit a sparse
  block into it?

- If yes, does the filesystem support FILE_SUPPORTS_SPARSE_FILES?

  - If yes, is it on a volume having no seek penalty?

    - If yes, make the file sparse.

    - If no, is the "sparse" mount option set?

      - If yes, make the file sparse.

> Also, does Cygwin have a syslog where people can check whether the
> feature is on or off?

We have a syslog API for applications, like services, which utilze it.
The Cygwin DLL itself doesn't use it.  That would flood either a syslog
daemon, or the Windows logs with 99.9% unnecessary info.


Corinna