mirror of
https://git.hardenedbsd.org/hardenedbsd/HardenedBSD.git
synced 2024-12-29 15:10:57 +01:00
HardenedBSD src tree
92ed385a09
Date: Thu, 16 Sep 93 01:35:10 +1000 Julian writes: >In fact DEVIDLE and FINDWORK ended up being basically equivalent. >the bit I wonder about, is the returning of 0.. What (other than >another request from somewhere else in the kernel) is going to start >work on the next item on the queue? I think removing FINDWORK would make things clearer. Nothing much is going to start work on the next item. However, it is pointless to continue processing the queue for the same unready drive. Aborting all reads and trying harder to perform all writes would be better. Julian writes. > no, actually it should be: > fdt = fd_data[FDUNIT(minor(dev))].ft; Fixed. From: bde@kralizec.zeta.org.au (Bruce Evans) Date: Thu, 16 Sep 93 22:56:01 +1000 The fd driver reported the wrong cylinder/head/sector numbers after an error (ST3 is only valid after a sense-drive command), and didn't report fs block numbers (diskerr was not used). There was an old problem with writes to block fd devices. Try this: 1. write protect floppy in fd0. 2. tar cf /dev/fd0a /dev/null. Repeat a few times. Later writes tend to terminate earlier. 3. un-write protect floppy. 4. repeat step 2. The writes tend to return 0, 2048, 4096, ... and then succeed. This was caused by a bug in vfs__bios.c. (The bug is fixed in NetBSD's vfs_bio.c.) fd.c sets bp->b_resid to nonzero after an error. vfs__bios.c was not initializing bp->b_resid. This causes some writes to terminate early (e.g., writes to block devices; see spec_write()). Related funnies: 1. Nothing tries to write the residual bytes. 2. The wd driver sets bp->b_resid to 0 after an error, so there's no way anything else could write the residual bytes. 3. I use the block fd device for tar because the raw device seemed to have more bugs long ago, and because it ought to be able to handle buffering more transparently (I don't want to have to know the device size). But spec_write() always uses the size BLKDEV_IOSIZE == 2048 which is too small. For disks it should use the size of one track (rounded down to meet the next track boundary or the i/o size). Here it would help if the DIOCGPART ioctl worked. But DIOCGPART is not implemented for floppies, and the disk size is ignored except for partitions of type FS_BSDFFS. Bruce |
||
|---|---|---|
| bin | ||
| etc | ||
| gnu | ||
| lib/csu/i386 | ||
| libexec/makekey | ||
| sbin | ||
| share/man/man4 | ||
| sys | ||
| usr.bin | ||
| usr.sbin | ||