Prev: Tar to another computer follow up: The semaphore timeout periodhas expired
Next: I don't get ssh.. more secure? Making better passwords.
From: The Natural Philosopher on 22 Jun 2010 11:18 J G Miller wrote: > On Tue, 22 Jun 2010 17:32:35 +0300, Stuart Gall wrote: > >> With this in mind and also possible disk hardware problems. I ran >> >> badblocks -s -w /dev/sdb >> >> To check and completely erase the disk. No bad blocks. >> >> After that, reformatted and it works fine.?!!? >> >> Must have got some data somewhere which confused udev. > > Is this in fact because it has forced the hard drive firmware > to remap the bad block as being unusable so they OS no longer > tries to use them? > > So your available disk space will be just slightly less > than it was before? ??? he says there were no bad blocks! I suspect its more a question of something I have occasionally seen: Fdisk doesn't entirely recreate everything. Total erasure often works.
From: Pascal Hambourg on 22 Jun 2010 11:57 Hello, J G Miller a �crit : > On Tue, 22 Jun 2010 17:32:35 +0300, Stuart Gall wrote: > >> With this in mind and also possible disk hardware problems. I ran >> >> badblocks -s -w /dev/sdb >> >> To check and completely erase the disk. No bad blocks. >> >> After that, reformatted and it works fine.?!!? >> >> Must have got some data somewhere which confused udev. Maybe an old RAID superblock at the end of the disk as suggested by David. > Is this in fact because it has forced the hard drive firmware > to remap the bad block as being unusable so they OS no longer > tries to use them? Quite unlikely. You can check with smartctl. > So your available disk space will be just slightly less > than it was before? Unlikely too. Remapped sectors are taken from reserved spare sectors, not from the end of usable sectors.
From: J G Miller on 22 Jun 2010 13:13 On Tue, 22 Jun 2010 16:18:36 +0100, The Natural Philosopher wrote: > he says there were no bad blocks! Ah sorry, I had erroneously interpreted that as meaning that there were no badblocks after running the procedure. Thanks for your explanation and that of Pascal Hambourg in the accompanying posting.
From: David W. Hodgins on 22 Jun 2010 14:14 On Tue, 22 Jun 2010 10:32:35 -0400, Stuart Gall <stuart(a)otenet.gr> wrote: > To check and completely erase the disk. No bad blocks. > After that, reformatted and it works fine.?!!? > Must have got some data somewhere which confused udev. The data most likely was the superblock, near the end of the device. Think about how a raid array is normally used. Multiple partitions on multiple devices appear as a single device, /dev/md0. In an attempt to reduce the chance for corruption, the underlying partition devices are hidden, by the kernel. When you decide to remove a device from a raid array, you have to erase the superblock. If you still have the version of mdadm that was used to create the array, you can use mdadm with the --zero-superblock option, to erase it. If you don't have the same version of mdadm, or don't know which version was used, you have to erase the beginning and ending parts of the device. In this case, you previously used dd to erase the beginning, and now used badblocks to erase the end, so the superblock is now gone, and the kernel no longer hides the partition device. Regards, Dave Hodgins -- Change nomail.afraid.org to ody.ca to reply by email. (nomail.afraid.org has been set up specifically for use in usenet. Feel free to use it yourself.)
From: Pascal Hambourg on 22 Jun 2010 18:47
David W. Hodgins a �crit : > > Think about how a raid array is normally used. Multiple partitions > on multiple devices appear as a single device, /dev/md0. In an > attempt to reduce the chance for corruption, the underlying partition > devices are hidden, by the kernel. IME, RAID partitions are not hidden. However when a whole disk (instead of a RAID partition) is used as part in a RAID device, then its partition table is ignored because even the first sector of the disk, which contains the partition table, is now part of the RAID device. |