From mboxrd@z Thu Jan 1 00:00:00 1970 From: Howard Chu Subject: Re: truncate head of file? Date: Thu, 21 Aug 2014 11:59:50 -0700 Message-ID: <53F641A6.90100@symas.com> References: <53F435EC.4030601@symas.com> <53F447A8.8020804@symas.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: =?windows-1252?Q?Luk=E1=9A_Czerner?= , linux-fsdevel To: Andreas Dilger Return-path: Received: from zill.ext.symas.net ([69.43.206.106]:53000 "EHLO zill.ext.symas.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752475AbaHUS74 (ORCPT ); Thu, 21 Aug 2014 14:59:56 -0400 In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Andreas Dilger wrote: > > On Aug 20, 2014, at 1:00 AM, Howard Chu wrote: >> For example - we have a logfile (opened O_APPEND) that grows continuously. We want to delete some old log info from the head of the file. We could use "hole punching" to cause a specific range of data to be freed, but that just leaves a sparse file. If we were to cat this file the read() would have to advance thru all of that empty space before arriving at actual log data. We want both the data to be freed and for the logical beginning of the file to be moved forward, to match the location of where the remaining data begins. > > It would also be possible to use fallocate(FALLOC_FL_PUNCH_HOLE) > to punch out the processed records, and seek(SEEK_DATA) to find > the first record that has not been processed. That would avoid > problems with the file size changing and O_APPEND. That would be OK, except that we want the file size to decrease. Otherwise the logical size grows without bound and eventually we'd have to recreate the file anyway. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/