About USB hard drives and errors
in [Debian]
|
Prev: ditching mutt
Next: Ubuntu vs Debian forums (was recompiling the kernel with a different version name)
From: Paul E Condon on 9 Apr 2010 12:10 On 20100409_102442, Ron Johnson wrote: > On 2010-04-08 20:27, Ron Johnson wrote: > >On 2010-04-08 19:44, Paul E Condon wrote: > >>I want to use the low cost high capacity hard drives that are > >>for sale in places like Best Buy and Costco. I have put ext3 on > >>several of them and started experimenting. The results so far > >>are puzzling. > >>I do get errors. So I decided to do scans for bad blocks. The drives > >>I'm using are all Western Digital because they have been the lowest > >>cost at the times I buy at Costco. Also all are 500GB. > >>e2fsck -c <device> is supposed to scan for bad blocks and allocate them > >>to a special inode so that they cannot be used. It runs for 3 to 4 > >>hours and then says its finished with no indication of how many bad > >>blocks it found. > >> > >[snip] > >> > >>Has anyone ever used these programs? Have you ever seen useful output? > >>What SHOULD they do (with a little more specificity and believability)? > >> > > > >Not a direct answer to your question, but: I never leave home > >without -vfFC0. (The Unix Way is to "say something" only upon > >failure, but I like continuous feedback.) > > > > (The "dumpe2fs -b" command should show you all your bad blocks.) > > Here's the result of me checking for bad blocks: > > # e2fsck -c -vfFC0 /dev/mapper/main_huge_vg-main_huge_lv > e2fsck 1.41.10 (10-Feb-2009) > Checking for bad blocks (read-only test): done > > BIG_LV: Updating bad block inode. <<<<<<<<<< Note!! > Pass 1: Checking inodes, blocks, and sizes > Pass 2: Checking directory structure > > Pass 3: Checking directory connectivity > > Pass 4: Checking reference counts > > Pass 5: Checking group summary information > > > > BIG_LV: ***** FILE SYSTEM WAS MODIFIED ***** > > 301084 inodes used (0.12%) > 14172 non-contiguous files (4.7%) > 121 non-contiguous directories (0.0%) > # of inodes with ind/dind/tind blocks: 0/0/0 > Extent depth histogram: 294700/6219 > 560591687 blocks used (58.03%) > 0 bad blocks > 128 large files > > 292926 regular files > 7972 directories > 0 character device files > 0 block device files > 0 fifos > 0 links > 177 symbolic links (155 fast symbolic links) > 0 sockets > -------- > 301075 files > Thanks Ron. Your option strings will do wonders for future e2fsck runs. But ... Why does the output say that the disk was modified during the run? There were no badblocks found. What needed modification? Do you have similar magic for dumpe2fs? Of course your output presented here indicates that you HD is not one on which you can verify badblock printing, since your disk has no badblocks. -- Paul E Condon pecondon(a)mesanetworks.net -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/20100409160423.GB5664(a)big.lan.gnu
From: Ron Johnson on 9 Apr 2010 13:20 On 2010-04-09 11:04, Paul E Condon wrote: [snip] > > But ... Why does the output say that the disk was modified > during the run? There were no badblocks found. What needed > modification? Good question. > Do you have similar magic for dumpe2fs? Nope. > Of course your output presented here indicates that > you HD is not one on which you can verify badblock > printing, since your disk has no badblocks. > I could have done a -cc test (which the man page says is a "non-destructive read-write test") but I don't want to take the chance of making a mistake or there being a bug and having it foul the partition. -- Dissent is patriotic, remember? -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/4BBF6045.6030706(a)cox.net
From: Clive McBarton on 10 Apr 2010 03:30 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul E Condon wrote:> > dumpe2fs -b <device> is supposed to print the bad blocks that have > been marked on a device. When I run it, it prints nothing. I find it > hard to believe that a 500GB HD contains ZERO bad blocks. Every HD that is even remotely close to being usable will always have zero bad blocks when seen from outside the HD. All HDs have error recognition and error correction and automatic replacement of faulty sectors with spare ones. A HD will only show bad blocks after all of its remapping area is used, at which point it is far beyond being usable. In other words, scanning for bad blocks on a HD cannot work. You can see the internal count of the remapped sectors with SMART, as others have already pointed out here. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvAJssACgkQ+VSRxYk4408n6gCgrLFCZRpvissG4/Q8WXoAHnHU E1sAnRmcsZbxX1Bei7JYD0ZNhGaXVCrC =GN/u -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/4BC026CC.8000704(a)web.de
From: Ron Johnson on 10 Apr 2010 09:50 On 2010-04-10 02:20, Clive McBarton wrote: > > Paul E Condon wrote:> >> dumpe2fs -b <device> is supposed to print the bad blocks that have >> been marked on a device. When I run it, it prints nothing. I find it >> hard to believe that a 500GB HD contains ZERO bad blocks. > > Every HD that is even remotely close to being usable will always have > zero bad blocks when seen from outside the HD. All HDs have error > recognition and error correction and automatic replacement of faulty > sectors with spare ones. A HD will only show bad blocks after all of its > remapping area is used, at which point it is far beyond being usable. > > In other words, scanning for bad blocks on a HD cannot work. > > You can see the internal count of the remapped sectors with SMART, as > others have already pointed out here. Interesting. So what is /badblocks/ for, and should it be removed in order to remove useless complexity? -- Dissent is patriotic, remember? -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/4BC080F6.60005(a)cox.net
From: Hugo Vanwoerkom on 10 Apr 2010 10:20
Ron Johnson wrote: > On 2010-04-10 02:20, Clive McBarton wrote: >> >> Paul E Condon wrote:> >>> dumpe2fs -b <device> is supposed to print the bad blocks that have >>> been marked on a device. When I run it, it prints nothing. I find it >>> hard to believe that a 500GB HD contains ZERO bad blocks. >> >> Every HD that is even remotely close to being usable will always have >> zero bad blocks when seen from outside the HD. All HDs have error >> recognition and error correction and automatic replacement of faulty >> sectors with spare ones. A HD will only show bad blocks after all of its >> remapping area is used, at which point it is far beyond being usable. >> >> In other words, scanning for bad blocks on a HD cannot work. >> >> You can see the internal count of the remapped sectors with SMART, as >> others have already pointed out here. > > Interesting. So what is /badblocks/ for, and should it be removed in > order to remove useless complexity? > And I thought I had something good when all the badblock counts were 0... Hugo -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/hpq16b$79k$1(a)dough.gmane.org |