At 2004-08-08T20:54:06+1200, Volker Kuhlmann wrote: > Obviously badblocks multiplies the start/end numbers by block size. > Because disk blocks and LBAs are always 512 it can be useful to use -b > 512 and /dev/hda and not /dev/hda5. There are many ways to skin a cat, > none is better than the others. Either way you end up converting > someway.
Correct, and if you'd said that originally I wouldn't have bothered explaining why your use of '-b 512' is potentially wrong unless you understand exactly what you're doing and what the result will be. There's still no real proof that your run of badblocks was performed correctly, yet you complain to the list about the tool. I don't even know why you're wasting time running (and talking abut running) the badblocks program, because in your case you already know where the error(s) are on disk. Map them out using the filesystem's bad blocks list, or bin the drive. Using half-assed hacks like trying to keep a portion of a file on disk to ensure the damaged blocks are in-use is not the best solution in your case, and it also shows that you're making dangerous assumptions about the on-disk filesystem format. > The large bandwidth taken by badblocks rather slows the machine too > much, perhaps later. A limit option would be handy so one can keep > working. Try running it with a positive nice value--that will have some effect on the amount of I/O that it can perform when competing with other processes. If you were running a 2.6 kernel it should be less of a problem anyway, since the I/O scheduling is quite a bit better. If you're running 2.6 and it's still a problem, it may indicate a problem with your configuration or hardware. Of course, during the time that badblocks is accessing the damaged sectors, you can't expect decent performance on that IDE channel. That's just a fact of life with IDE, though. > Well, I provided all needed info for the question I asked. You could The original question was answered, at which point the thread drifted to different but related topics. Each time something is suggested, you provide a small amount of additional information as part of the "but this won't work" reply. If you provided such information up front, people won't need to make assumptions about so much when trying to suggested general solutions. And while you did provide enough information to answer the initial generic question, once you explained why you wanted to do what you had originally asked about, a better solution was presented for your specific case. > You made implicit assumptions on no info, resulting in blanket > statements which aren't always correct without further qualifications > or conditions. Correct. This is a mailing list, and I don't have access to your machine to perform any investigative work of my own. Any help you recieve from members of the list is provided on their own time, for free. As a result of this, we have to rely on information you provide, requested or otherwise. The more information you provide up front, the easier it is for other's to make suggestions. You (and the list in general) might benefit from reading Tatham's write-up[0] on reporting bugs effectively, and Raymond's write-up[1] on how to ask questions the smart way. > I appreciate you trying to be helpful, but you can't blame me for > "drip-feeding" you info about problems I don't have and questions I > haven't asked. E.g. you shouldn't be needing a clueless person (your I'm not sure what you mean when you refer to 'problems you don't have'. > words) to explain possible scenarious for the "strange" results if > you're that clued up about hard disk failures yourself ;))) We're not talking about 'possible scenarios' here. Up until this point, you hadn't explained what you had observed happening with the drive (i.e. that you could write a sector without problems, but that reading it an hour later would fail), so it's not possible for an outsider to do much more than guess. [0] http://www.chiark.greenend.org.uk/~sgtatham/bugs.html [1] http://www.catb.org/~esr/faqs/smart-questions.html -mjg -- Matthew Gregan |/ /| [EMAIL PROTECTED]
