| 1 |
Nikos Chantziaras writes: |
| 2 |
|
| 3 |
> Before leaving home, I started an fsck.ext4 on a filesystem (500GB) that |
| 4 |
> resides on a disk that I suspect is damaged: |
| 5 |
> |
| 6 |
> fsck.ext4 -c -c -f /dev/sdb1 |
| 7 |
> |
| 8 |
> When I came back 10 hours later, it was still checking. After 2 hours |
| 9 |
> more (so it took 12 hours total) it finally finished. The output was |
| 10 |
|
| 11 |
Anything about erros in dmesg or syslog? |
| 12 |
|
| 13 |
> e2fsck 1.41.14 (22-Dec-2010) |
| 14 |
> Checking for bad blocks (non-destructive read-write test) |
| 15 |
> Testing with random pattern: done |
| 16 |
> Extra: Updating bad block inode. |
| 17 |
> Pass 1: Checking inodes, blocks, and sizes |
| 18 |
> Pass 2: Checking directory structure |
| 19 |
> Pass 3: Checking directory connectivity |
| 20 |
> Pass 4: Checking reference counts |
| 21 |
> Pass 5: Checking group summary information |
| 22 |
> |
| 23 |
> Extra: ***** FILE SYSTEM WAS MODIFIED ***** |
| 24 |
> Extra: 11/30531584 files (0.0% non-contiguous), |
| 25 |
> 1966902/122096638 blocks |
| 26 |
> |
| 27 |
> I'm not sure how to read this. Were there any bad blocks or not? Is |
| 28 |
> there a way to query the filesystem for the now known bad blocks? (The |
| 29 |
> "Updating bad block inode." message suggests that such a list is stored |
| 30 |
> directly inside the filesystem.) |
| 31 |
|
| 32 |
dumpe2fs -b /dev/sdb1 probably also works for ext4. |
| 33 |
|
| 34 |
bablocks /dev/sdb2 will do a read-only check of the whole partiton for |
| 35 |
bad blocks. Use option -n for a non-destructive write mode. |
| 36 |
I qalso like to add options -s and -v to see the progress. I redirect |
| 37 |
the output into a file then, because output of progress and bad blocks |
| 38 |
will overlap: badblocks -sv /dev/sdb1 > sdb1.bad |
| 39 |
See man badblocks for more information. |
| 40 |
|
| 41 |
Wonko |
Archives