Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 24 Nov 2002 22:19:00 -0800
From:      Kirk McKusick <mckusick@beastie.mckusick.com>
To:        Julian Elischer <julian@elischer.org>
Cc:        current@freebsd.org, Robert Watson <rwatson@tislabs.com>, re@freebsd.org
Subject:   Re: Update to UFS2 Superblock Format 
Message-ID:  <200211250619.gAP6J059068226@beastie.mckusick.com>
In-Reply-To: Your message of "Sun, 24 Nov 2002 21:28:38 PST." <Pine.BSF.4.21.0211242120160.34466-100000@InterJet.elischer.org> 

next in thread | previous in thread | raw e-mail | index | archive | help
Some of these fields could usefully be made unsigned others not
(for example fs_pendingblocks and fs_pendinginodes). So just
going through and making everything unsigned is not the right
approach. I will make a pass through and consider changing some
of these fields once the tree opens back up, but not at this
point in time when we are trying to keep changes to a minimum
and do not have time for extensive testing.

	Kirk McKusick

=-=-=-=-=

Date: Sun, 24 Nov 2002 21:28:38 -0800 (PST)
From: Julian Elischer <julian@elischer.org>
To: Kirk McKusick <mckusick@mckusick.com>
cc: current@freebsd.org, Robert Watson <rwatson@tislabs.com>, re@freebsd.org
Subject: Re: Update to UFS2 Superblock Format
In-Reply-To: <200211250511.gAP5BU59067794@beastie.mckusick.com>
X-ASK-Info: Whitelist match

I do have one question re: UFS2, not specifically about this change
however..

I notice that the fields of the disk structure are signed.
Wouldn;t it make more sence at this early stage to declare them as
unsigned?
For example 
take this snippet from struct fs
        int64_t  fs_size;               /* number of blocks in fs */
        int64_t  fs_dsize;              /* number of data blocks in fs
*/
        ufs2_daddr_t fs_csaddr;         /* blk addr of cyl grp summary
area */
        int64_t  fs_pendingblocks;      /* blocks in process of being
freed */
        int32_t  fs_pendinginodes;      /* inodes in process of being
freed */
        int32_t  fs_snapinum[FSMAXSNAP];/* list of snapshot inode
numbers */
        int32_t  fs_avgfilesize;        /* expected average file size */ 
        int32_t  fs_avgfpdir;           /* expected # of files per
directory */
        int32_t  fs_save_cgsize;        /* save real cg size to use
fs_bsize */
        int32_t  fs_sparecon32[27];     /* reserved for future constants
*/
        int32_t  fs_contigsumsize;      /* size of cluster summary array
*/
        int32_t  fs_maxsymlinklen;      /* max length of an internal
symlink */
        int32_t  fs_old_inodefmt;       /* format of on-disk inodes */
        u_int64_t fs_maxfilesize;       /* maximum representable file
size */
        int64_t  fs_qbmask;             /* ~fs_bmask for use with 64-bit
size */
        int64_t  fs_qfmask;             /* ~fs_fmask for use with 64-bit
size */
        int32_t  fs_state;              /* validate fs_clean field */
        int32_t  fs_old_postblformat;   /* format of positional layout
tables */
        int32_t  fs_old_nrpos;          /* number of rotational
positions */


How can any of these values be meaningfully -ve?

Making them signed just gives fsck a harder time to check the values.
(as we saw this week).


I have run a system with many of these made unsigned and it made
no difference to the system. It was binarily compatible too.
i.e it mounted existing filesystemd with no problems.

julian




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200211250619.gAP6J059068226>