home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / os / linux / 20329 < prev    next >
Encoding:
Text File  |  1992-12-14  |  1.3 KB  |  38 lines
  1. Newsgroups: comp.os.linux
  2. Path: sparky!uunet!mcsun!julienas!jussieu!card
  3. From: card@masi.ibp.fr (Remy CARD)
  4. Subject: Re: ext fs question (.badblocks)
  5. Message-ID: <1992Dec14.133843.2536@jussieu.fr>
  6. Sender: news@jussieu.fr (Le Facteur)
  7. Nntp-Posting-Host: ares.ibp.fr
  8. Organization: Laboratoire MASI - Universite Pierre et Marie Curie - Paris - France
  9. References: <orman.724229253@vislab.me.iastate.edu>
  10. Date: Mon, 14 Dec 1992 13:38:43 GMT
  11. Lines: 25
  12.  
  13. In article <orman.724229253@vislab.me.iastate.edu> orman@iastate.edu (David L Orman) writes:
  14. >does mkefs still make a /.badblocks with the -c option?  I was
  15. >reinstalling and tried it and I didnt get a .badblocks  I got made
  16. >errors as the scan was done however, so I know there is some bad spots. 
  17. >the command I used was:
  18. >mkefs -c /dev/hdb1 xxxxxx
  19. >
  20. >I forget the number of blocks, anyway its an RLL drive with known bad
  21. >areas so whats the deal....  is it ok or not?
  22. >
  23.  
  24.     mkefs now uses a reserved inode (inode #2) to store the bad blocks.
  25. This inode does not appear in the filesystem tree any more because it was
  26. leading to problems (root could delete the .badblocks file or save it during
  27. a backup).
  28.  
  29.     So, even if you don't see a .badblocks file with ls, don't worry.  The
  30. bad blocks are recorded and won't be use in the fs.
  31.  
  32.  
  33.     Remy
  34. --
  35.  
  36.     Remy Card
  37.     card@masi.ibp.fr
  38.