RE: Is there a "make hole" (truncate in middle) syscall?

["Hua Zhong" <hzhong@cisco.com>]

Sorry for digging out this old discussion.

This would be a tremendous enhancement to Linux filesystems, and one of
my current projects actually needs this capability badly.

The project is a lightweight user-space library which implements a
file-based database. Each database has several files. The files are all
block-based, and each block is always a multiple of 512 byte (and we
could make it a multiple of 4K, in case this feature existed).

Blocks are organized as a B+ tree, so we have a root block, which points
to its child blocks, and in turn they point to the next level. There is
a free block list too.

The problem is with a lot of add/delete, there are a lot of free blocks
inside the file. So essentially we'd have to manually shrink these files
when it grows too big and eats up too much space. If we could just "dig
a hole", it would be trivial to return those blocks to the filesystem
without doing an expensive defragmentation.

> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org 
> [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Rob Landley
> Sent: Thursday, December 04, 2003 12:32 PM
> To: linux-kernel@vger.kernel.org
> Subject: Is there a "make hole" (truncate in middle) syscall?
> 
> 
> You can make a file with a hole by seeking past it and never 
> writing to that 
> bit, but is there any way to punch a hole in a file after the 
> fact?  (I mean 
> other with lseek and write.  Having a sparse file as the result....)
> 
> What are the downsides of holes?  (How big do they have to be 
> to actually save 
> space, is there a performance penalty to having a file with 
> 1000 4k holes in 
> it, etc...)
> 
> Rob
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>