| To: | Eric Sandeen <sandeen@xxxxxxx> |
|---|---|
| Subject: | Re: "badblocks" for XFS? |
| From: | Florian Weimer <Weimer@xxxxxxxxxxxxxxxxxxxxx> |
| Date: | Thu, 16 May 2002 17:29:51 +0200 |
| Cc: | "Jonathan F. Dill" <dill@xxxxxxxxxxxx>, Stefan Smietanowski <stesmi@xxxxxxxxxx>, Mike Burger <mburger@xxxxxxxxxxxxxxxxx>, Linux XFS Mailing List <linux-xfs@xxxxxxxxxxx> |
| In-reply-to: | <1021311815.3935.206.camel@stout.americas.sgi.com> (Eric Sandeen's message of "13 May 2002 12:43:34 -0500") |
| References: | <Pine.LNX.4.44.0205130653090.3542-100000@burgers.bubbanfriends.org> <3CDFB2A0.9020700@stesmi.com> <1021296035.1577.9.camel@localhost.localdomain> <1021311815.3935.206.camel@stout.americas.sgi.com> |
| Sender: | owner-linux-xfs@xxxxxxxxxxx |
| User-agent: | Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.1 (i686-pc-linux-gnu) |
Eric Sandeen <sandeen@xxxxxxx> writes: > As I understand it, all modern drives do defect management internally, > remapping data blocks as they go bad. If you're actually seeing a bad > block from the outside, that probably means that the drive has run out > of blocks to remap to, and it's all downhill from there. There is one case in which you'll see actual bad blocks with (some) modern drivers: if a sector has not been fully written during power down. The sector carries bad check sums, and you get hard errors when trying to read it. However, writing to the block should correct the checksum and remove the bad block. -- Florian Weimer Weimer@xxxxxxxxxxxxxxxxxxxxx University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: 2.4.19-pre6aa1 oops, Stephen Lord |
|---|---|
| Next by Date: | Re: 2.4.19-pre6aa1 oops, Andrea Arcangeli |
| Previous by Thread: | Re: "badblocks" for XFS?, Jonathan F. Dill |
| Next by Thread: | new mirror in Slovakia, lubos klokner |
| Indexes: | [Date] [Thread] [Top] [All Lists] |