X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4F3233858415 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1701428584; bh=Zml5kTO1b7xqX7yM8d1DTKhJCJbZrwfJhmzLukZWUzk=; 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=x+sKxQSHt4f7B8xDCT2B7RspsanfPGKwOg3l6xKKpqUxfFWtwWHJgYlFjD03HajtU fuTb5htr7qC2Fh3IrlfKYQurxdkEgFb5oCrY1BE/7G0LQtrtYHaMYzo12DDSLVgfZc Zs4naTKar1LekjQN6c17BAZbLrRqAS1DM+n7aAi4= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7B6CF3858CDB Date: Fri, 1 Dec 2023 12:02:12 +0100 To: cygwin AT cygwin DOT com Subject: Re: Cygwin api to punch a hole into a file? 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:22, Cedric Blancher via Cygwin wrote: > I see the value of 128k (128*1024 bytes) quite often in your sparse > file commits. Yes, but they have been removed. Read the patches again, especially commit 65831f88d6c4. > Can you please make this value a per filesystem tunable? No, because we don't have a facility for that. > Not all filesystems have a 128k block/stripe size, and certainly most > filesystems have smaller minimum hole sizes than 128k (e.g. 512bytes > is common, ref pathconf _PC_MIN_HOLE_SIZE). There's no _PC_MIN_HOLE_SIZE in Linux or POSIX. In Windows, a sparse file uses chunks of 64K. You can see this even with a file of just a single block. Try this: $ touch x $ chattr +S x $ echo 1234567890123456789012345678901234567890123456789012345678901234567890123456789 >> x $ ls -ls x 1 -rw-r--r-- 1 corinna vinschen 80 Dec 1 11:56 x [repeat echo and ls -ls until...] $ echo 1234567890123456789012345678901234567890123456789012345678901234567890123456789 >> x $ ls -ls x 1 -rw-r--r-- 1 corinna vinschen 720 Dec 1 11:56 x $ echo 1234567890123456789012345678901234567890123456789012345678901234567890123456789 >> x $ ls -ls x 64 -rw-r--r-- 1 corinna vinschen 800 Dec 1 11:56 x2 ^^ This I don't know how Windows stores short files, maybe they are part of the metadata up to a point or some such. However, as soon as you raise the size over a given point, the *allocation size* will be rounded up to 64K and from that point on, it will be in 64K chunks. Also sparsifying and desparsifying of blocks only works in 64K chunks. 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