Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!att!att!dptg!ulysses!andante!alice!andrew
From: andrew@alice.att.com (Andrew Hume)
Newsgroups: comp.unix.internals
Subject: Re: holes in files
Summary: worms
Message-ID: <11753@alice.att.com>
Date: 28 Dec 90 06:32:13 GMT
References: <1820@b15.INGR.COM> <2809@cirrusl.UUCP> <11749@alice.att.com> <1990Dec26.190535.25820@Think.COM>
Organization: AT&T Bell Laboratories, Murray Hill NJ
Lines: 22



	i am on the ansi committee working on worm fs standards and
the problem of reserving space on worms is understood and provided for.
It is a little moot how you can do it with vanilla unix but at the file
system driver level, you can allocate arbitrary (well, limited by 2^64 bytes
and the world's production of media) extents for future use. presumably
clever vendors will add ioctl's or fcntl's to do such.
	as for being clever about adding 1 bits etc, forget it. it is
true at the innermost hardware level but user-level access requires turning
off ECC and VERY few drives provide even plausible performance without ECC.
It is unlikely you will ever find a rewrite of a block such that the new
data + new ECC == old data + old ECC plus some ones, particularly on
disks like SONY (12in) which has 512 bytes of ECC for each 1024 byte sector.


	returning to the original point, i don't care what the file system
does behind my back. i do care about being able to reserve space on the file system
that no other user can eat.

	andrew hume	(908) 582-6262
	andrew@research.att.com