filesystem expands the inode to 256 bytes to make space for 64-bit
block pointers. It also adds a file-creation time field, an ability
to use jumbo blocks per inode to allow extent like pointer density,
and space for extended attributes (up to twice the filesystem block
size worth of attributes, e.g., on a 16K filesystem, there is space
for 32K of attributes). UFS2 fully supports and runs existing UFS1
filesystems. New filesystems built using newfs can be built in either
UFS1 or UFS2 format using the -O option. In this commit UFS1 is
the default format, so if you want to build UFS2 format filesystems,
you must specify -O 2. This default will be changed to UFS2 when
UFS2 proves itself to be stable. In this commit the boot code for
reading UFS2 filesystems is not compiled (see /sys/boot/common/ufsread.c)
as there is insufficient space in the boot block. Once the size of the
boot block is increased, this code can be defined.
Things to note: the definition of SBSIZE has changed to SBLOCKSIZE.
The header file <ufs/ufs/dinode.h> must be included before
<ufs/ffs/fs.h> so as to get the definitions of ufs2_daddr_t and
ufs_lbn_t.
Still TODO:
Verify that the first level bootstraps work for all the architectures.
Convert the utility ffsinfo to understand UFS2 and test growfs.
Add support for the extended attribute storage. Update soft updates
to ensure integrity of extended attribute storage. Switch the
current extended attribute interfaces to use the extended attribute
storage. Add the extent like functionality (framework is there,
but is currently never used).
Sponsored by: DARPA & NAI Labs.
Reviewed by: Poul-Henning Kamp <phk@freebsd.org>
the author obviously meant a void since he doesn't return any values.
One caveat, http_request has three return()'s, but doesn't do anything
with it. Either the code needs to be rewritten to take care of proper
error handling on that point, or the returns ripped out. I made it void
for now.
We had to give up DDB and grep this time...
Add a hint in "config" on how to increase the image size so
we can stuff more things in the image (mostly for use on a CDROM).
directories when writing to disk.
Use the (yet to be committed) sysctl variable kern.bootdevname
to derive the device name, fallback to /dev/fd0 if kern.bootdevname
is unset or not available.
closer to doing "the right thing".
The structure is now the following:
* /etc/rc (from MFS) loads the rest of /etc and /root from
/fd and then from floppy (if present), then transfers control
to /etc/rc1
* /etc/rc1 loads defaults from /etc/rc.conf.defaults, tries to
set the hostname basing on the MAC address of the first ethernet
interface, and then sources /etc/rc.conf and /etc/rc.conf.local
for local configurations
* The rest of the startup process is then performed (rc.network and so on).
Everything except the initial /etc/rc (from MFS) can be overridden with
a local version loaded from floppy. But in most cases, you should only need
to customize the following files in /etc:
rc.conf rc.firewall hosts
Previously there were a number of inconsistencies in the calling
between files, and also a lot of clutter in rc.conf and rc.firewall.
Also, "rc1" was called "rc" and would overwrite the initial /etc/rc
from MFS, making it really hard to figure out what was going on in
case of bugs.
+ fix some dialog entries to correctly modify variables instead of working
in a subshell
+ add a logverbose function for debugging purposes
+ force 512/4096 blocks on filesystems
+ use 'auto' for disklabel so it works irrespective of the floppy size.
This is useful for larger images than 1720k
and disable telnet and friends in favour of ssh/sshd/scp.
Pull out a few NIC drivers from the config file to make the
image fit into a 1.44 image again. I have left "lnc" in as that is
emulated by vmware so this can be booted there.
"top" does (thinking of it, i could have as well used the same format line!)
This only makes sense when "-w" option is also specified, because the
load is computed as the difference between subsequent samples.
I think this (and the "-d" feature which shows differences in the
network statistics counts) would also make sense in the standard
vmstat and netstat.
only once into an array of shell variables, and then scan the array
to find entries matching the MAC address.
Associative arrays would really be handy here...
