X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D3C38385841F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1701427414; bh=gTV3OO8QtSNQJ4ZY/2Y03/gHYjZDDWyu3upCl93JXkA=; 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=MftLr2dApgSrPgB4T11d3iZ/NvNuq6Izzcf2MSrzVpeiNp3fzSP84l8WizEdCVUEO JuOF+d3pBoZjbwFaFbULH/OhIU1GITKQ52XQnwy6Ax774S/dm3c409H4ckvCYSHwnJ zQn9nyfscRyoI362way5TmmIVW/X/P8sI4SCpXI8= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9E1873858CDB Date: Fri, 1 Dec 2023 11:43:17 +0100 To: cygwin AT cygwin DOT com Subject: Re: Comment about "Cygwin: sparse support: enable automatic sparsifying of files on SSDs", extend feature to VMware/qemu disks? Message-ID: Mail-Followup-To: cygwin AT cygwin DOT com References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BeenThere: cygwin AT cygwin DOT com X-Mailman-Version: 2.1.30 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Corinna Vinschen via Cygwin Reply-To: cygwin AT cygwin DOT com Cc: Corinna Vinschen 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" 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 -- 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