jhood@biar.UUCP (John Hood) (07/06/89)
This was not fun to see... Over the weekend, I was at Dave Shevett's house. We were moving net software in every conceivable direction-- he has a 3b1 (labii), I have a 386 running Microport. I tried to make a cpio disk that the Xenix/386 machine he had around temporarily could read. I didn't know what device on the 3b1 corresponded to a plain, dumb block device with no funny volume header blocks, and the 3.5 manuals are no help. (Nor was Dave ;-) Eventually, I figured out that maybe I could format an 8 sector disk (FDnl), cpio to /dev/rfp020 and feed that to Xenix, using its /dev/fd048ds8. I noticed that after writing anything to the [r]fp020 device, the disk became unrecognizable by the 3b1, presumably because the volume header block gets stomped on. I think I was just getting close to succeeding in this quest when the 3b1 panicked with a bad block in the free list, halfway through cpio-ing to a disk. I let it go through the automatic reboot/fsck cycle (twenty-twenty hindsight shows that this was probably *NOT* a good idea), and when it came back up after two automatic reboots, most of /usr was in lost+found and some of it was gone, as was about 3/4ths of /etc. We spent a good ten or so hours picking up pieces, copying them off to floppy, and doing a complete reinstall. It will be a few days before Dave has his system back up on the net. It may well have been coincidence (the system had been acting a little bit weird), but needless to say, I didn't dare do anything even vaguely unusual with 3b1 floppies after that. Would somebody please explain how the floppies are laid out, what the two floppy devices do and what they're for, and how to get around the volume header block for 3b1 <-> PC-family disk transfer? (I vaguely recall that there is a utility out there that specifically handles PC-Unix style disks, but we didn't have it, and it would be nice to know a way to do without it.) And does anyone know whether the 3B1 is particular about the contents of the disks fed to it, to the point of tripping over itself and panicking on ones it doesn't like? And a final note: I suspect that the reason the machine lost files may have been that the lost+found directory was not large enough to accommodate all the recovered files, and fsck automatically threw files away. It was only 1024 bytes or 32 files long. Make sure your lost+found directory is at least as large as the largest directory on your system; it's cheap insurance. --jh -- John Hood, Biar Games snail: 10 Spruce Lane, Ithaca NY 14850 BBS: 607 257 3423 domain: jhood@biar.uu.net bang: anywhere!uunet!biar!jhood You may redistribute this article only to those who may freely do likewise.
psfales@cbnewsc.ATT.COM (Peter Fales) (07/07/89)
In article <730@biar.UUCP>, jhood@biar.UUCP (John Hood) writes: > > Would somebody please explain how the floppies are laid out, what the > two floppy devices do and what they're for, and how to get around the > volume header block for 3b1 <-> PC-family disk transfer? (I vaguely > recall that there is a utility out there that specifically handles > PC-Unix style disks, but we didn't have it, and it would be nice to > know a way to do without it.) I am perhaps not the best person to answer this, but I think I can shed a little light on the issue. When the 3b1 opens the floppy device, it reads the first two sectors on the disk and looks for a magic number. If it finds it, it loads the Volume Header Block (VHB) into memory. The VHB contains information about the physical layout of the disk (heads, cylinders, etc), and the logical format (partition sizes). If the driver it does not find a VHB on the disk, it initializes the in-memory copy to some default values (1 head, and 1 cylinder), and expects you to change them via an ioctl. John Milton posted an example of how to read non-standard disks this way a while back. As you surmise, /dev/rfp020 is the entire disk. Also, as you discovered writing to this partition is a no-no, as it overwrites the VHB. Reading from it is OK though. You may find it useful to compare an 'od -x' with the information in /usr/include/sys/gdisk.h. /dev/rfp021 is the partition which does not include the loader and VHB. This varies depending on the information on the VHB, but for the no-loader case (fdfmt.nl), it starts with head 1, cylinder 0, sector 8. For other types of disks, you can view the disk layout by with 'iv -tv /dev/rfp020' I would transfer files to a PC by writing them to /dev/rfp021 on the unix-pc. On the PC side I would use dd if=/dev/XXX skip=8 | cpio -icv ( or whatever) where /dev/XXX is the 40 track, double sided, 8 sector floppy device. The skip=8 skips over the eight 512-byte sectors containing the VHB and loader. > And does anyone know whether the 3B1 is particular about the contents > of the disks fed to it, to the point of tripping over itself and > panicking on ones it doesn't like? To the best of my knowledge, it will not. Normally, you are safe because the 3b1 will recognize a foreign disk by its magic number. If for some reason you had a disk with a valid magic number, you will get funny numbers for heads, cylinders, etc. that will confuse the floppy disk hardware, but I don't think it would panic. I am not going to go try the experiment on my own machine though :-) > And a final note: I suspect that the reason the machine lost files may > have been that the lost+found directory was not large enough to > accommodate all the recovered files, and fsck automatically threw > files away. It was only 1024 bytes or 32 files long. Make sure your > lost+found directory is at least as large as the largest directory on > your system; it's cheap insurance. Good idea!! -- Peter Fales AT&T, Room 5B-420 2000 N. Naperville Rd. UUCP: ...att!ihlpb!psfales Naperville, IL 60566 Domain: psfales@ihlpb.att.com work: (312) 979-8031
jrallen@devildog.UUCP (Jon Allen) (07/08/89)
I saw this very same thing happen to a friend of mine (even the panic). He was writing to the floppy, but accidently wrote to the raw hard disk entry. The system ran a bit, panic'd, and most of the system ended up in /lost+found. After that he (and I) added more sensible names for the floppy in the /dev directory to prevent this mistake from happening. -Jon Allen