[gentoo-user] Re: How do I show list of bad blocks on a disk?

[Francesco Talamona]

On Sunday 06 March 2011, Florian Philipp wrote:
> Am 06.03.2011 18:07, schrieb Nikos Chantziaras:
> > Before leaving home, I started an fsck.ext4 on a filesystem (500GB)
> > that
> >
> > resides on a disk that I suspect is damaged:
> >   fsck.ext4 -c -c -f /dev/sdb1
> >
> > When I came back 10 hours later, it was still checking.  After 2
> > hours
> >
> > more (so it took 12 hours total) it finally finished.  The output was:
> >   e2fsck 1.41.14 (22-Dec-2010)
> >   Checking for bad blocks (non-destructive read-write test)
> >   Testing with random pattern: done
> >   Extra: Updating bad block inode.
> >   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
> >
> >   Extra: ***** FILE SYSTEM WAS MODIFIED *****
> >   Extra: 11/30531584 files (0.0% non-contiguous),
> >   1966902/122096638 blocks
> >
> > I'm not sure how to read this.  Were there any bad blocks or not?
> > Is there a way to query the filesystem for the now known bad
> > blocks?  (The "Updating bad block inode." message suggests that
> > such a list is stored directly inside the filesystem.)
>
> When there is nothing else reported, there was no error. "FILE SYSTEM
> WAS MODIFIED" usually just means that a directory "lost+found" was
> created.

That would be interactive, and it would show up in the console output:

fsck from util-linux-ng 2.18
e2fsck 1.41.12 (17-May-2010)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
/lost+found not found.  Create<y>? yes

Pass 3A: Optimizing directories
Pass 4: Checking reference counts
Pass 5: Checking group summary information

/dev/mapper/sda5: ***** FILE SYSTEM WAS MODIFIED *****
/dev/mapper/sda5: 177646/4481024 files (6.7% non-contiguous), 
10916521/17920370 blocks

Anyway I don't worry about the fact that the filesystem was modified, as 
long as the program doesn't ask for user intervention. As you can see in 
my case there was a directory optimization.

Fsck took a very long time because of "-c" option (you are not taking 
advantage of the fact that the disk is almost empty), and you specified 
it twice, so "the bad block scan will be done using a non-destructive 
read-write test." as stated in the man page, so in the end, nothing to 
worry about WRT filesystem. 

You should also check SMART status.

Bye
	Francesco

-- 
Linux Version 2.6.37-gentoo-r1, Compiled #4 SMP PREEMPT Sat Mar 5 
16:45:57 CET 2011
Two 2.8GHz AMD Athlon 64 Processors, 4GB RAM, 11255 Bogomips Total
aemaeth