that while modstat and modunload and builtin modules work exactly
the same as in the host case, modload loads file system kernel
modules from the rump kernel namespace. By default, archs which
have rump support for the kernel kernel ABI have the host module
directory mapped into the rump kernel namespace at the same location
(/stand/...). Therefore, if the *host* module directory is populated,
"rump.modload foo" will work as expected. Otherwise, RUMP_MODULEBASE
can be used to point to the module directory.
and depending on file system data, can actually be a false error.
Fixes what I was actually testing for in bin/44209, though the
actual problem was not what I originally described.
copy appropriate data to where they are expected in the updated superblock.
When writing the updated superblock, move the updated values back to the
old ffsv1 superblock locations. Also check for old superblock format when
updating the last cylinder group and adjust cg_old_ncyl appropriately.
Derived from how mksf sets them. Should address PR bin/44209.
to ensure it's been properly extended. Clears up some problems at certain
blocksizes which showed up during creation of atf tests, which is done
using file-backed file systems.
when testing that the last sector of the new size is writeable, make
sure we're ACTUALLY writing in the new space, instead of possibly
overwriting something in the existing fs.
Discovered while writing tests - tests which uncovered file corruption at
certain block sizes.
XXX should rewrite writeat() to expect fs blocks instead of disk blocks.
OK mlelstv@
for KEYGEN_RANDOMKEY.
Print a warning if such a refusal is made---this will help the user understand
why there is an error.
Patch provided by: Taylor R Campbell <campbell+netbsd@mumble.net>.
- sync usage comment with current reality
- sort includes
- wrap lines
- use EXIT_FAILURE consistently
- make error messages consistent: Cannot->Can't
- Remove "Old FFSv1 macros" in favor of system macros in ufs/ffs/fs.h .
Leave dblksize() because it uses the on-disk dinode structure.
More cleanup is needed.
No functional changes intended.
were commented out with XXX and a notation to "fix once fsck is fixed."
fsck seems to have been fixed for this particular issue sometime in the
7 years since the code was brought into the tree.
Update cg_old_niblk instead of cg_ni_blk, since this tool
currently supports ffsv1 only.
With these two changes, I can grow a file system and have the result
be clean according to fsck_ffs. Shrinking still results in an unclean
file system.
OK mhitch@
While I'm here, fix a typo in an error message.
The server must of course have some disks configured. Let's say
we have this simple server with disks as a few sparse host files:
main()
{
rump_init();
rump_pub_etfs_register("/disk1", "./disk1.img", RUMP_ETFS_BLK);
rump_pub_etfs_register("/disk2", "./disk2.img", RUMP_ETFS_BLK);
rump_pub_etfs_register("/disk3", "./disk3.img", RUMP_ETFS_BLK);
rump_pub_etfs_register("/disk4", "./disk4.img", RUMP_ETFS_BLK);
pause();
}
And we run the server:
mainbus0 (root)
Kernelized RAIDframe activated
/disk1: hostpath ./disk1.img (97 GB)
/disk2: hostpath ./disk2.img (97 GB)
/disk3: hostpath ./disk3.img (97 GB)
/disk4: hostpath ./disk4.img (97 GB)
We can then configure the raid against the server:
> ./raidctl -c theraid.conf raid0
And lo, we have evidence of a level1 raid in the server dmesg:
raid0: RAID Level 1
raid0: Components: /disk1 /disk2 /disk3 /disk4
raid0: Total Sectors: 409599744 (199999 MB)
yea, i initialized it already in a previous run:
> ./raidctl -S raid0
Reconstruction is 100% complete.
Parity Re-write is 100% complete.
Copyback is 100% complete.
current testing purpose is to create a file system with
block size > MAXPHYS.
(the check doesn't make that much sense anyway in these days of
mobile file systems, since we're interested in MAXPHYS where we
attempt to mount the file system, not where we happen to create it)
This is useful for automated environments where everything (rpcbind,
mountd, nfsd and the client) is started in parallel in a split
second and there is a small chance we will race in there before
everything has been communicated to rpcbind.
