Re: 3100/80: 4G disk limit?
Mouse <[email protected]> Mon, 27 Apr 2026 08:24:27 -0400 (EDT)
| Newsgroups | gmane.os.netbsd.ports.vax |
|---|---|
| Message-ID | <[email protected]> |
>> I've got a 3100/80. [...disk access clipping at 4G...hardware or >> software?...] > Sounds very much more like a software problem. New observation, pointing even more towards software IMO: last night I tried to back up its current disk state. I did this by running dd if=/dev/rsd0a bs=65536, piped into a network send program. I left this going overnight; the rate it was going, my predictor said it should finish around one in the morning. sd0 is 8467200 sectors, 4134 MB, and sd0a is exactly 4G, 8388608 sectors. But this morning I woke up to discover that it had copied over 20 billion bytes, over four and a half times what it should have, and still going. (Interestingly, after I killed it with ^C to dd, the resulting file is 20078894688 bytes, but dd reported only 20078854144 bytes transferred. I don't know where the other 40544 bytes came from.) I broke it into five pieces, four 4G and one 2899025504 bytes, for comparison; turns out I have four and a half copies of the same 4G of data. Something is clearly wrapping in the disk I/O pathway - but, unless 1.6.2 has regressed as compared to 1.4T, it's in MD code; one of my 1.4T SPARCs has no problems with a 268435456-sector partition (128G). I'm moderately sure no relevant fix is part of my 1.4T changes, though that's relying on wetware memory. I'll definitely have to investigate more. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML [email protected] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B