Re: File questions: Head truncate? sharing FDs between procs?

From: Erez Zadok (ezk@cs.columbia.edu)
Date: Wed May 24 2000 - 19:30:47 EST


In message <20000523164728.C17536@thepuffingroup.com>, willy@thepuffingroup.com writes:
> On Tue, May 23, 2000 at 11:50:55AM -0600, Ian S. Nelson wrote:
> > I think I know the answer to this first question already. Is there a
> > head trunc function? I don't think there is but you never know. The
> > situation is like this: we've got a large file (multiple gigs) and at
> > some point while still writing data to it we realize that we don't want
> > the first 500MB so we want to trunc it off the front of the file will
> > keeping it open and keep writing to it. Anyone want head trunc if I get
> > strapped in to writing it?
>
> Hm. You really don't want to truncate the first 500MB and juggle
> pointers; a better solution would be to make a hole in the file for the
> first 500MB. I think your best bet for implementing this is to create a
> ->zero inode operation which a fs which supports holes can implement by
> unmapping previously allocated blocks and dain-bread fs' can write zeroes.
> What the userspace API to this function would be, I'm not sure.

Yeah shifting data like that can be costly, but it is doable. My stackable
compression file system, gzipfs, does just that when you write data in the
middle of the file. We also had to write a rather complex truncate routine
that can punch holes, and shift data arbitrarily outward or inward. In
other words, if Linux might provide some general purpose functions to
"sparsify" a file and/or shift data around, I sure would make use of it.

Erez.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:13 EST