So, with the vnd(4) issue more or less sorted, there seems to be one
major mystery remaining w.r.t. whatever has gone wrong with the ability
of NetBSD-current XEN3_DOM0 to host FreeBSD domUs.
I still can't create a clean filesystem on a writeable disk. The
"newfs" runs fine, but a subsequent "fsck" finds errors and cannot fix
them (though the first run does change one or two things).
I can't even get a clean fsck of the running system's root FS:
(the "ada0: disk error" after I hit ^C is because the underlying disk
(vnd0d) is exported read-only to the domU)
# fsck -v /dev/ufs/FreeBSD_Install
start / wait fsck_ufs /dev/ufs/FreeBSD_Install
** /dev/ufs/FreeBSD_Install
SAVE DATA TO FIND ALTERNATE SUPERBLOCKS? [yn] n
ADD CYLINDER GROUP CHECK-HASH PROTECTION? [yn] n
** Last Mounted on
** Root file system
** Phase 1 - Check Blocks and Sizes
PARTIALLY TRUNCATED INODE I=28
SALVAGE? [yn] n
PARTIALLY TRUNCATED INODE I=112
SALVAGE? [yn] ^Cada0: disk error cmd=write 8145-8152 status: fffffffe
***** FILE SYSTEM MARKED DIRTY *****
#
Most mysteriously this filesystem is in use as the root FS and all the
files in it can be found and read! Presumably they are all intact too
-- no programs have failed or behaved mysteriously (except fsck) and all
the human readable files I've looked at (e.g. manual pages) all seem
fine. In fact it only seems to be fsck that complains, possibly along
with any attempt to write to a filesystem, that causes problems. (I
believe writing to a filesystem appears to corrupt it but that is only
according to fsck. I do seem believe there was an eventual crashes of a
system that had been running with active filesystems, but I have not got
far enough again since to reproduce this, due to the fsck problem.)
# mount
/dev/ufs/FreeBSD_Install on / (ufs, local, noatime, read-only)
devfs on /dev (devfs, local, multilabel)
tmpfs on /var (tmpfs, local)
tmpfs on /tmp (tmpfs, local)
# df
Filesystem 512-blocks Used Avail Capacity Mounted on
/dev/ufs/FreeBSD_Install 782968 737016 -16680 102% /
devfs 2 2 0 100% /dev
tmpfs 65536 232 65304 0% /var
tmpfs 40960 8 40952 0% /tmp
# time -l sh -c 'find / -type f | xargs cat > /dev/null '
38.58 real 1.36 user 18.30 sys
4872 maximum resident set size
13 average shared memory size
5 average unshared data size
215 average unshared stack size
1906 page reclaims
0 page faults
0 swaps
14024 block input operations
0 block output operations
0 messages sent
0 messages received
0 signals received
12348 voluntary context switches
33 involuntary context switches
In fact I can put a copy of the FreeBSD img file into an LVM LV, attach
it to the running FreeBSD domU, mount it (without an FSCK, since the
FreeBSD_Install filesystem comes clean from the factory), then do
"diff -r -X /mnt -X /dev / /mnt" and find only the expected differences.
So, what could be different about how fsck reads v.s. the kernel itself?
If indeed writing to filesystem corrupts it, how and why?
It seems NetBSD can make sense of the BSD label inside the FreeBSD
mini-memstick.img file, e.g. when accessed through vnd(4), but it can't
seem to make sense of the filesystem(s) inside (which I guess might be
expected?):
# file -s /dev/rvnd0f
/dev/rvnd0f: DOS/MBR boot sector, BSD disklabel
# disklabel vnd0
# /dev/rvnd0:
type: vnd
disk: vnd
label: fictitious
flags:
bytes/sector: 512
sectors/track: 32
tracks/cylinder: 64
sectors/cylinder: 2048
cylinders: 387
total sectors: 791121
rpm: 3600
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0 # microseconds
track-to-track seek: 0 # microseconds
drivedata: 0
6 partitions:
# size offset fstype [fsize bsize cpg/sgs]
d: 791121 0 unused 0 0 # (Cyl. 0 - 386*)
e: 1600 1 unknown # (Cyl. 0*- 0*)
f: 789520 1601 4.2BSD 0 0 0 # (Cyl. 0*- 386*)
disklabel: boot block size 0
disklabel: super block size 0
# fsck -n /dev/vnd0f
** /dev/rvnd0f (NO WRITE)
BAD SUPER BLOCK: CAN'T FIND SUPERBLOCK
/dev/rvnd0f: CANNOT FIGURE OUT SECTORS PER CYLINDER
--
Greg A. Woods <gwoods%acm.org@localhost>
Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost>
Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpO_x9pIBiIi.pgp
Description: OpenPGP Digital Signature