Re: large ufs2 partitions and 'df'

From: Paul Richards <paul_at_freebsd-services.com>
Date: 12 May 2003 21:12:21 +0100
On Mon, 2003-05-12 at 20:33, Kirk McKusick wrote:
> 	Date: Mon, 12 May 2003 07:53:49 -0700
> 	From: Terry Lambert <tlambert2_at_mindspring.com>
> 	To: Kirk McKusick <mckusick_at_mckusick.com>
> 	CC: Julian Elischer <julian_at_elischer.org>, freebsd-current_at_freebsd.org
> 	Subject: Re: large ufs2 partitions and 'df'
> 	X-ASK-Info: Whitelist match
> 
> 	Kirk McKusick wrote:
> 	> Julian Elisher wrote:
> 	> > I think that swithing to a new syscall with a fixed structure
> 	> > and using the rules you mention above to populate the structure in
> 	> > an ostatfs call might be the best answer.
> 	> > Old binaries probably only need to know that there is > X blocks
> 	> > free and not necessarily the correct number.
> 	> > New binaries can use the new syscall.
> 	> 
> 	> So right you are. It would be possible to get the space by nibbling
> 	> a bit more space from MNAMELEN, but at some point we need to just bite
> 	> the bullet and define a new structure. I am leaning towards believing
> 	> that time is now. If we do define a new structure, I would like to
> 	> clean up the existing one a bit. I would propose this:
> 
> 	If you're going to change the structure, please put a version
> 	number as the first field, so that it's never a problem again.
> 
> 	Also, put a spare field on the end (64 bits) to allow for
> 	future expansion that maintains binary compatability (by way
> 	of choice about what to copy in).
> 
> 	-- Terry
> 
> There are already ten spare 64-bit numbers in the middle of the 
> proposed new structure. They are there where they are guaranteed
> to be 64-bit aligned rather than at the end where there is danger
> of them being aligned differently on different architectures since
> they follow character arrays.

A version number would be a good idea though so apps have some chance of
knowing what fields are being used in the future.

-- 
Paul Richards <paul_at_freebsd-services.com>
Received on Mon May 12 2003 - 11:17:11 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:07 UTC