Re: Tool for detecting partition superblocks needed
Wow, Benjamin, your effort to help is definitely more than I could
expect from a mailing list .. :)
Thanks for lot: I think I learned a few things with your explanations
...
On Fri, Oct 03, 2008 at 12:16:17AM +0200, Benjamin Cama wrote:
> Le jeudi 02 octobre 2008 à 20:17 +0200, Wolfgang Pfeiffer a écrit :
> > Could this also be a simple file system damage?
>
> Errors like that (i.e. in the middle of a DMA interrupt) are not simple
> FS damage, I am pretty sure.
>
> > I was hoping it was just something like that, because this hopefully
> > could be "fixed" with a reinstall, and with a previous low-level
> > formatting like
> >
> > dd if=/dev/urandom of=/dev/hda (not being sure whether the syntax is
> > correct .. )
>
> For this kind of low level formatting, I would advise you to dd
> from /dev/zero, as the hard drive controller can try to replace bad
> sectors if needed when it sees that an all-0 block is written. But when
> some sectors begin to fail, others will soon come, in general.
That's exactly why I will replace that disk. I shall not take any
risks like having to re-install again in a few weeks just because
other disk sectors start to break at some point in the future ...
>
> > Oh, and the Fedora smartctrl found (surprise, surprise .. :) a failure on
> > LBA 76724676 and 76724678, too (please see the old log above) ...
>
> Well, this confirm that the error lies in hardware, not in the file
> system itself.
>
> > I attach the log made on the broken machine via
> > smartctrl -a /dev/hda
>
> So, the very high numbers like Raw_Read_Error_Rate and Seek_Error_Rate
> are meaningless, I think, but the numbers in Offline_Uncorrectable and
> UDMA_CRC_Error_Count show that some sectors have already been lost. But
> what worries me most is the Load_Cycle_Count value : 2898441 is far too
> high for a disk, but may look real, as your disk as been spinning for
> quite some time (10000+ hours). This roughly corresponds to a
> load/unload every 15s : do you here some light "tic tac" sound from your
> disk every 15s or so ?
IIRC: yes, I think so. Currently 'tho, with the machine being booted
via the Fedora CD, I don't hear any clicks, although hdparm -I reports
the Advanced power management level being set to 128 ...
> For reference, mine, which has a 8000+ hours lifetime, has a count
> of 268656 (ten times less ...). If you take the specs from seagate
> for your hard drive (
> http://www.seagate.com/docs/pdf/datasheet/disc/ds_momentus5400.2_120gb.pdf
> ), you'll see it's made for at most 600000 load/unload cycles.
That's why I'll want a Seagate again: Just think about what might have
happened with disk settings changed to no power management, like you
suggested below, with hdparm -B .. :)
>
> I am worried about it because this is what I saw from a lot of apple
> laptops, and as you may have understood, from one of my lost iBook's
> hard drive. This made the news some time ago, not especially for apple's
> disks, but when Ubuntu was said to be killing hard drives : some vendor
> BIOSes did not set the power saving mode of the hard drive "correctly",
> which led them to load/unload too often, and kill the hard drive in a
> very short time.
The first disk shipped with my old Titanium IV PB broke after around 2
years, IIRC ... and the current one (a replacement disk) in that
machine, with more than 7100 Power_On_Hours, and a with a
Load_Cycle_Count of 366793 probably might fail in the near future,
with all the ugly sound I hear from the machine while it is up .. and
I disabled Power Management on this machine via hdparm now ... let's
see .. :)
> AFAIK, OpenFirmware does not set any power saving mode
> at all, and neither does OSX, and by default a lot of disk are in a
> "maximum" power saving mode, which unloads the hard drive head very
> often, thus consuming less energy but shortening the life of the hard
> drive. [ ... ]
> You can change these settings with the -B option of hdparm, for
> example :
> hdparm -B254 /dev/hda
Let's see whether this is preserved and kept over reboots ... :)
> disables power management on most hard drive (the value is drive
> dependant, most of the time 255 or 254 disables power savings). I think
> this is what is done in laptop-mode package when you set your hard drive
> in "no PM" mode.
>
> > > What do you mean by "see hda7" ?
> >
> > to "see" in the sense of to "detect" ...
> > mac-fdisk detected the damaged partition in the Debian installer, IIRC
> > ..
>
> What I meant is that, if you can "see" some partition in mac-fdisk, you
> can see them all. But this doesn't mean the FS on them is not
> failing.
parted detects that partition, but does not "see" any FS on it, that
is, when I type "print" in parted for /dev/hda, there's an empty space
for the column where parted is supposed to report the FS for 7 (which
should be /dev/hda7).
FS is reported for 6 (/home), 5 (/var) and swap for 4. Even hfs+ is
detected correctly for #2, where the small OS X partition sits ...
> When you said you didn't see hda7 but you did with the others, it
> sounded strange to me.
>
> > No, not that easily .. It's a Powerbook5,8: if I manage to remove the
> > disk from it (there must be instructions somewhere on www) I'll
> > reinstall a new one. No time to waste, because my old tibook, where
> > I'm typing this email, is making strange noises already. Looks like
> > I'm in need of quick decisions, besides working hardware ... :)
>
> Well, the instructions from macfixit are good, I already disassembled a
> 12" iBook and a 15" PB with them. And it looks like you will need them
> soon ...
I found out in the mean time I have bought an extended warranty (3
yrs) from the reseller (Gravis, in DE) where I bought the machine
... let's see what they say when I report them OS X boots, and Linux,
on other partitions, does not ...
But I'll scrub the whole disk with a dd if=/dev/urandom, and see
whether OS X is able to install to it. If it can't, I should be a
candidate for warranty, I think ..
Thanks again, to everyone :)
Benjamin, you helped me learn: Thanks .. :)
Regards
Wolfgang
--
heelsbroke.blogspot.com
Reply to: