archer%segin4.segin.fr@relay.prime.com (Vincent Archer) (09/20/90)
I reformatted my HD this week-end. After this, I tried to run diskcheck on
my Minix partitions. It failed, saying it couldn't purge the disk cache. Of
course it couldn't: it does this by reading NR_BUFS from /dev/ram, and I
have no ramdisk! So I fixed diskcheck; it will now print a warning, then
continue (if you get this warning, you might get wrong results as reads are
now cached).
While I was fixing the cache code, I improved the cache use: If you use a
raw device (like /dev/rh1b - rhd1 for PCs), no cache purging is necessary
anymore. And a last cosmetic change: at the end, a \n is printed, leaving
the prompt below the status line.
table
!"#$%&'()*+,-./0123456789:;<=>?
@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_
begin 644 dskchk.cdif.Z
M'YV-*@*"<.'B10P7-5Z,>=.F31@W9.:\()-FSIHQ:,J,6>-B3((I==R :!(Fz
M#X@8,T#(@*$#I8X:.4[FR %#08N;("A:Q*B1H\<F;T1.*0/GY V5,72L?!E#y
M)DT% :-*G:H"JL 8+&R D&H3)]:C-V\J 'BA8J<%2]FW BB!0@Z9>;0 1$&x
MK4409M[( 2$F#!F^;-YLG),@2!TZ:/3J !$$HDDJ#\NXZ5NGS=878T%D'I'&w
MS1@V=<B4 <%C3AZ)=/+ B>L"C0\%*T!P]@Q:-&G3$N6&H=/Z-=G9GT./+IWFv
MC)LP;'IO[AS<-H\R<N2X>:/\-_/:P\V,<4,GN6NK5,.#5VF#Q8RF7,.JO&$^u
M9=@6F4/.*>ZFS%_H<O3.V9$@@5G9(."G'PASO(%7&'NI@!E9\M%G'PACT,%?t
M?_^- )A@:\P!@AQE^$6@@68@>%EFG<U5HAELA''&A/Z=-4<9<]V1D4CS&8<<s
M@65(-F)L)6X8QAVBV<'B?R_&.",(2;SP1$Y!C1:4CW?D5(8=:8PQFH*9E8$'r
M7-(%&-UT.V06F!MG@ #'&_MEAI&(*L!1AQQGE&%&&FR,U@,((DPTY0MRA-&&q
M"&&&)^AX,Y1'@U;IX30##BS40$-;866V1V8,NE%C?7^)$2999/681IBQD267p
M''5$2" =NQ&X*:=VO)'&7V/LAA$**:Q**8'T(8?"%$D<D8035+ H:QHU'KKo
MI;KR>D045201[+!T8&0LIR"D808(*"!XQA@@A' G#2F 4,<<*I9!*ZB<6HNMn
M;G1D"Z<=6\30A; FS)%"N)/&E@ <<IR(@@A#/#3=7.R"4,(<7+@A@K#:PBNOm
ML?IJF4:[,4#,:1^P<=HGD%."<.<47R0QQ1!(2('"'"[(]44;;X@V;;K7HH""l
M&7_=^<9J;KA[AL/S@O#$%U(0<844]Y(& @SX9K9OO]R9\6_ ;@P,PLTZ'ISPk
MPG2]&V\7+R<@,<7&"BI>5"#<0 ,+-\24J%LXR, "#CA *A:U&)-U+*ITC'MNj
MQF3QZZ\(5[],UM<H(+UJW9J)3=5X,>!07@PS;1559F["6<87L?)$JZ29_4>$i
M@9*]4<<9:&S8841OH9$J8J-EGE&U&E8>)QDNC!B"9K=WRAT(=9I!A[ +A?3[h
MAF'>?BL<-'L\-<XHR"XGG64(^W/03SC!1!:"\R[G7'<Z(<470E1AQ!2KDB4Cg
M]-CV/I</1R=-5@+![WXG"NH;[00(/VCO.PB+.=&UNC+;RYTXY)?FT4Q8SA-#f
M'<P /-'M[BQ"8,(3AK"$+_!*"T4HFK<@Y,"Y0%""%+1@$C#H/A#TQV]-^U<1e
MI""%)TAA,?&C0P]*\!?]R9"&&YHA[<B"M1@*2WW"DD/7$A B5+'A:0)[PUR<d
M-RR>U,Y+TGG#G;"&G^ET#6/J@5P-6""#&#SJ/91[4YPP%P;-I8!S9/$<Z*8Sc
MNM(1$'6(6=WK7#>:BIA)C/:I'99R=ZK=5*E:N[L#@C"E/!@4+UV[ R('A1?$b
M0RJ CP#<6)#"Q:&\2:=\9DJ>S9CGO#G527I (T+UKI>]^G7O>^$;'R;/5Z?Ta
M;0\$[$,:"";UOA@JCWZOY $([I>_^O7O?S%#@0!-5T#DD0&!>%0@ Q?Y0!!$z
M<((5O& &P[5!6WX0FB(DX2PSUI](>NQ.LLR7";L9LQ (4CKV"1<*Z> T$5PAy
M"%)PPJ^.L!BH28V)='1!X-#5GP2<DY!WB@$_^R,& JYAH(@[(=/8J4(6NA"&x
J'=0A6=0G43GH\(D][. /MQ?$(1915P!+XA+QV,2,/+&*4L23L%!Z104 w
v
end
_________
|\___/| Vincent Archer
| \ / | Email: archer%segin4.segin.fr@relay.prime.com
| /|\ |
|// \\|
-+-----+- "Time is running fast..."meulenbr@cst.philips.nl (Frans Meulenbroeks) (09/21/90)
archer%segin4.segin.fr@relay.prime.com (Vincent Archer) writes:
]I reformatted my HD this week-end. After this, I tried to run diskcheck on
]my Minix partitions. It failed, saying it couldn't purge the disk cache. Of
]course it couldn't: it does this by reading NR_BUFS from /dev/ram, and I
]have no ramdisk! So I fixed diskcheck; it will now print a warning, then
]continue (if you get this warning, you might get wrong results as reads are
]now cached).
Just a thought:
wouldn't it be better to read NR_BUFS from /dev/null or /dev/mem?
--
Frans Meulenbroeks (meulenbr@cst.philips.nl)
Centre for Software Technology
( or try: ...!mcsun!phigate!prle!cst!meulenbr)unix3@ce.chalmers.se (Unix Internt. Labgrupp 3) (09/22/90)
>]I reformatted my HD this week-end. After this, I tried to run diskcheck on >]my Minix partitions. It failed, saying it couldn't purge the disk cache. Of >]course it couldn't: it does this by reading NR_BUFS from /dev/ram, and I >]have no ramdisk! So I fixed diskcheck; it will now print a warning, then >]continue (if you get this warning, you might get wrong results as reads are >]now cached). >Just a thought: >wouldn't it be better to read NR_BUFS from /dev/null or /dev/mem? I have been thinking about this ever since I first saw the diskcheck source. Why is there a need for messing with NR_BUFS? I presume there is one, as you are not using a simple sync() ... Perhaps you could explain this or if it would suffice why it isn't there?! With My Regards, Andrew Olausson
archer%segin4.segin.fr@relay.prime.com (Vincent Archer) (09/23/90)
Of course, i should have tought of it. Reading from /dev/mem (or rather /dev/kmem) would be very nice. /dev/null is out of question, you CAN'T read anything from it. In fact, it would be exactly as it is now, reading from /dev/ram (which is empty). To answer another question, why do we read NR_BUFS instead of just doing a sync That's for emptying the buffer cache of FS, that's why. sync does the writing, not the reading. That's needed because diskcheck verifies that what was written can be read back. But if the sector is still in the cache, you will ALWAYS read back what you wrote... because it won't be read, it will be taken from the disk cache! The real thing is to solve the cache matter once for all. Use the raw device, which bypass the cache entirely. _________ |\___/| Vincent Archer | \ / | Email: archer%segin4.segin.fr@relay.prime.com | /|\ | |// \\| -+-----+- "Time is running fast..."
evans@syd.dit.CSIRO.AU (Bruce.Evans) (09/25/90)
In article <31035@nigel.ee.udel.edu> archer%segin4.segin.fr@relay.prime.com (Vincent Archer) writes: >While I was fixing the cache code, I improved the cache use: If you use a >raw device (like /dev/rh1b - rhd1 for PCs), no cache purging is necessary Raw disk devices are not implemented on PCs. They almost work anyway. You can try mknod'ing the disk devices as character devices as well as block devices. Various things go wrong. The drivers that use DMA (floppy, xt_wini, bios_wini for XT controllers) will fail when the user buffer crosses a 64K DMA boundary. The floppy and xt_wini drivers will panic from this; bios_wini will return an error. The at_wini driver works. All the drivers require a too-small i/o size of 1K. This results in the raw at_wini driver being about 25% of the speed as the block at_wini driver on my system. -- Bruce Evans evans@syd.dit.csiro.au
sgerakin@hawk.ulowell.edu (Steve Gerakines) (09/28/90)
In article <31216@nigel.ee.udel.edu> unix3@ce.chalmers.se (Unix Internt. Labgrupp 3) writes: > I have been thinking about this ever since I first saw the diskcheck source. Ouch. diskcheck makes me too uneasy to use. The thought of a program writing to, and fiddling with every sector on a partition makes me feel a little uneasy... I usually just use readall to give it a quick check-up. Of course, diskcheck is better at finding sectors that are on their way out. readall could be made much more useful if two small enhancements were made to them. First is that most hard drive controllers (and the kernel) can recover from touchy sectors that it reads. For example on my hard drive, I *know* there are a few bad sectors because when they're read, my hard drive makes kind of a buzzing noise. After multiple re-tries, it will finally, and successfully, read the sector. Maybe if there was a timer when a sector is read, if the timer went off, then the sector read would be considered bad, and reported. The other small enhancement is that (I think) errors are reported as sector numbers, instead of block numbers. If they were in blocks, it would be more useful with the badblocks program. I know it's easy to figure out which sector maps to which block, but as far as my hard drive goes, I don't like leaving anything to the imagination. :-) -Steve Gerakines ---------------------------------------------------------------------------- | Usenet: sgerakin@hawk.ulowell.edu | SteveNet: GENESIS:Steve2 | | UUCP: ...!harvard!swan!sgerakin@hawk | "My kingdom for a smoke!!!" | ----------------------------------------------------------------------------
evans@syd.dit.CSIRO.AU (Bruce.Evans) (10/04/90)
In article <31308@nigel.ee.udel.edu> archer%segin4.segin.fr@relay.prime.com (Vincent Archer) writes: >Of course, i should have tought of it. Reading from /dev/mem (or rather >/dev/kmem) would be very nice. /dev/null is out of question, you CAN'T read It would have to be /dev/bmem = /dev/mem as a block device since /dev/mem is a character device and reading it would not affect the cache. /dev/kmem as a block device would probably be too small. >The real thing is to solve the cache matter once for all. Use the raw device, >which bypass the cache entirely. Yes, except raw disk devices are not implemented for Minix-1.5-PC. Thrashing the cache on purpose makes using the block device extremely slow. I have just modified the PC AT driver to handle raw devices. This involved replacing the fixed sector count BLOCK_SIZE/SECTOR_SIZE by the number of sectors asked for, and changing some checks. -- Bruce Evans evans@syd.dit.csiro.au