home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / os / linux / 20796 < prev    next >
Encoding:
Text File  |  1992-12-17  |  1003 b   |  28 lines
  1. Newsgroups: comp.os.linux
  2. Path: sparky!uunet!news.claremont.edu!ucivax!ucla-cs!twinsun!junio
  3. From: junio@twinsun.com (Jun Hamano)
  4. Subject: Re: ext fs question (.badblocks)
  5. In-Reply-To: erc@unislc.uucp's message of Wed, 16 Dec 1992 05:48:31 GMT
  6. Message-ID: <bk-+-2$`@twinsun.com>
  7. Sender: usenet@twinsun.com
  8. Nntp-Posting-Host: bo
  9. Organization: Twin Sun, Inc. (El Segundo CA)
  10. References: <1992Dec15.084358.17478@jussieu.fr> <1992Dec16.054831.5078@unislc.uucp>
  11. Date: Thu, 17 Dec 1992 09:58:30 GMT
  12. Lines: 14
  13.  
  14. In article <1992Dec16.054831.5078@unislc.uucp> erc@unislc.uucp (Ed Carp) writes:
  15.  
  16.    Unfortunately, this doesn't work - the kernel never reports read or write
  17.    errors, so efsck -t won't work.
  18.  
  19. If `efsk -t' won't work because a user process won't be notified
  20. disk read/write error by the kernel, then how does another user
  21. process `mkefs -c' can find bad blocks and link them together?  I
  22. really don't understand.
  23. --
  24.       |
  25.    __-+-__      Jun Hamano
  26. _-+ (|o|) +-_   junio@twinsun.com
  27.   !   .   !
  28.