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
