Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: one remaining mystery about the FreeBSD domU failure on NetBSD XEN3_DOM0



So I wrote a little awk script so that I could write 512-byte blocks
with varying values of bytes.  (Awk is the only decent programming
language on the FreeBSD mini-memstick.img which I could think of that
would do something close to what I wanted it to do.  I could have
combined awk+sh+dd and done things faster, but I had all day to let it
run while I worked on some small engine repairs.)

https://github.com/robohack/experiments/blob/master/tblocks.awk

and then I used it to write 30GB to two different LVM LVs, each of
identical size, and each exported to the domU, one written on the dom0
and the other written on the domU.

Then I ran a cmp of both drives on each the dom0 and domU.

On the dom0 side were no differences.  All 30GB of what was written
directly in the dom0 to one of the LVs was identical to what was written
in the FreeBSD domU to the other LV.  I.e. the FreeBSD domU side seems
to be writing reliably through to the disk.

The FreeBSD domU though is _really_ slow at reading with cmp (perhaps
not unexpectedly given that it is using stdio to do the read and only
managing 4KB requests, at a rate of just under 500 requests per second
on each disk).

I'm going to send this and go to bed before it finishes, but I'm
guessing it's about 2/3's of the way through (it has run for nearly
11,000 seconds), and thus so far there are no differences from the
FreeBSD domU's point of view either.

Anyway, what the heck is FreeBSD newfs and/or fsck doing different!?!?!??

They're both writing and reading the very same raw device(s) that I
wrote and read to/from with awk and cmp.

These awk/cmp tests did very sequential operations, and the data are
quite uniform and regular; whereas newfs/fsck write/read a much more
complex data structure using operations scattered about in the disk.

These tests are also writing then reading enough data to flush through
the buffer caches in each dom0 and domU several times over.  The dom0
has only 4GB and the domU has 8GB, but Xen says it's only using under 2GB.

What else is different?  What am I missing?  What could be different in
NetBSD current that could cause a FreeBSD domU to (mis)behave this way?
Could the fault still be in the FreeBSD drivers -- I don't see how as
the same root problem caused corruption in both HVM and PVH domUs.

--
					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: pgpexFt4Y3KWw.pgp
Description: OpenPGP Digital Signature



Home | Main Index | Thread Index | Old Index