From mboxrd@z Thu Jan 1 00:00:00 1970 From: Howard Chu Subject: Re: truncate head of file? Date: Wed, 20 Aug 2014 01:33:22 -0700 Message-ID: <53F45D52.70001@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: QUOTED-PRINTABLE Cc: linux-fsdevel To: =?windows-1252?Q?Luk=E1=9A_Czerner?= Return-path: Received: from zill.ext.symas.net ([69.43.206.106]:55166 "EHLO zill.ext.symas.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750809AbaHTIdZ (ORCPT ); Wed, 20 Aug 2014 04:33:25 -0400 In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Luk=E1=9A Czerner wrote: > On Wed, 20 Aug 2014, Howard Chu wrote: > >> Date: Wed, 20 Aug 2014 00:00:56 -0700 >> From: Howard Chu >> To: Luk=E1=9A Czerner >> Cc: linux-fsdevel >> Subject: Re: truncate head of file? >> >> Luk=E1=9A Czerner wrote: >>> On Tue, 19 Aug 2014, Howard Chu wrote: >>> >>>> Date: Tue, 19 Aug 2014 22:45:16 -0700 >>>> From: Howard Chu >>>> To: linux-fsdevel >>>> Subject: truncate head of file? >>>> >>>> Was thinking it would be very handy to have a truncate() variant t= hat >>>> deletes >>>> pages from the head of a file. This could be leveraged to make log= files >>>> easier >>>> to maintain, as an example. Anyone else interested, think this wou= ld be >>>> nice >>>> to have? >>>> >>>> (Note - not the same as just punching holes in the beginning of th= e file - >>>> we >>>> want the beginning of the file to advance as well, past the delete= d >>>> pages.) >>> >>> I am not really sure I understand the behaviour you'd like to see. >>> Can you please explain the behaviour including more concrete use >>> case ? >> >> For example - we have a logfile (opened O_APPEND) that grows continu= ously. 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 ju= st 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. >> >> Freeing the space would be simplest if we just deallocate X pages fr= om the >> file, and then the beginning of the file becomes the beginning of th= e first >> remaining page of the file. > > Ok, now I understand. It is exactly what FALLOC_FL_COLLAPSE_RANGE is > for. It has been merged into mainline with commit v3.14-rc1-1-g00f5e6= 1 Ah, thanks for the tip. > However it will not work with O_APPEND nor does any other fallocate > flag except pure fallocate, so not even punch hole would have > worked. Hm, that's a little bit inconvenient. What if the process calling fallo= cate()=20 is different from the one appending to the log (i.e., using two separat= e file=20 descriptors)? Also, when a range is collapsed, are all processes with=20 descriptors opened on the file updated - are their seek positions corre= ctly=20 decremented? I dug up the patches and didn't see any code to handle thi= s but=20 may have missed it. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html