[gentoo-amd64] fsck seems to screw up my harddisk

[gentoo-amd64] fsck seems to screw up my harddisk

[Guido Doornberg]

hello everybody =),

About three months ago I decided to upgrade my desktop, in fact it was
more like buying a complete new one because I only kept the case and
the DVD-drive.
Anyway, my PC now contains an Athlon X2 4200+, a Samsung SP2504 250 GB
SATA2 harddisk and an Asus M2NPV-VM motherboard.

As OS I chose Gentoo (obviously) 2006.0, and partitioned my hd as follow:
/dev/sda1	ext2	/boot	32mb
/dev/sda2	swap		 512mb
/dev/sda3	ext3	/	  everything left

Took me much time to configure, but finally it was the way I wanted
it, accept for the fact that I had to use the acpi=off and noapic
parameters to get the kernel working.

So the system worked perfect every time until fsck started checking my
harddisk ("30 times mounted without being checked, check forced" In
the beginning everything seemed alright but at 18.7% the checking
freezed and a couple of minutes later fsck reported that my fs was
corrupted and that it couldn't be fixed "try fsck manually etc...." So
after this i did try fsck manually but everytime exact the same
story... I tried to mount the fs with the livecd but got an "can't
mount corrupted fs" (or something similar).

I couldn't figure out why this happened because everything worked
perfect and I hadn't done anything 'strange' with my pc. So, searched
google and various forums but couldn't find a solution to fix my fs,
so i formatted the complete disk and re-installed gentoo. Again, took
me a lot of time, but after all the work it worked even better then
the first time =).... well, at least until I had booted 30 times
without checking the filesystem. Fsck again began 'doing his job',
freezed at 18.7%, my filesystem was corrupted, couldn't mount it with
my live-cd etc.
This time I even had used my pc, just wanted to reboot, and at once my
filesystem was corrupted :S,

Well, I want to use Gentoo but i don't realy like the idea of spoiling
my weekend by installing an OS thats gonna stop working 30 times
booting later.
So, does anyone know whats wrong here and how i can prevent that it
happens again?

thanks =)
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] fsck seems to screw up my harddisk

[Richard Fish]

On 11/27/06, Guido Doornberg <guidodoornberg@gmail.com> wrote:
> Well, I want to use Gentoo but i don't realy like the idea of spoiling
> my weekend by installing an OS thats gonna stop working 30 times
> booting later.

I doubt this is really Gentoo-specific.

> So, does anyone know whats wrong here and how i can prevent that it
> happens again?

What kernel are you using?  Can you post your emerge --info?

My initial guesses are one of:

1. You are using some experimental kernel that is corrupting the filesystem

or

2. That your old power supply is not sufficient for your new
components, and this is showing up as an occasional IO/DMA error on
the hard disk.

-Richard
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] fsck seems to screw up my harddisk

[Alexander Gabert]

Richard Fish wrote:
> On 11/27/06, Guido Doornberg <guidodoornberg@gmail.com> wrote:
>> Well, I want to use Gentoo but i don't realy like the idea of spoiling
>> my weekend by installing an OS thats gonna stop working 30 times
>> booting later.
> 
> I doubt this is really Gentoo-specific.
Me too, i don't think it's Gentoo making this break.
> 
>> So, does anyone know whats wrong here and how i can prevent that it
>> happens again?
See below.
> 
> What kernel are you using?  Can you post your emerge --info?
> 
> My initial guesses are one of:
> 
> 1. You are using some experimental kernel that is corrupting the filesystem
He said he was installing 2006.0 so i doubt he was going for ~arch and
testing kernel.
> 
> or
> 
> 2. That your old power supply is not sufficient for your new
> components, and this is showing up as an occasional IO/DMA error on
> the hard disk.
This could be the reason.

3. another reason: did you actually run a mke2fs with disk checking when
creating the huge partition during installation?  Could be your Samsung
spinpoint is just broken somewhere at the 50GB region and the "simple
and fast" mke2fs just creating the inode table is not noticing this for
a weird reason.

from man mke2fs:

       -c     Check  the  device  for bad blocks before creating the
file system.  If this option is specified twice,
              then a slower, read-write test is used instead of a fast
read-only test.

Please try this and report back if you found something.
There is also low level test programs of disk vendors where you can
stress test the brick to make sure it's not faulty.

After all: sorry for the inconveniences you had, but this looks like a
real bad hardware issue rather than a notoric software misbehaviour :)


Good luck,

Alex
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] fsck seems to screw up my harddisk

[Guido Doornberg]

"> Well, I want to use Gentoo but i don't realy like the idea of spoiling
> my weekend by installing an OS thats gonna stop working 30 times
> booting later.

I doubt this is really Gentoo-specific."
- you're right on that, I love gentoo, but I hope you understand what I mean.

1. My kernel version is gentoo-2.6.17-r7 - so it isn't an experimental kernel

I can't post my emerge-info now because I don't have everything needed
for booting (monitor and stuff)

2. You really made me doubt about that, but I don't think that is the
problem. I'll do some more research on that.

3. I'll look for that next weekend =)

Thank you =)
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] fsck seems to screw up my harddisk

[Bernhard Auzinger]

Am Montag 27 November 2006 20:32 schrieb Guido Doornberg:
> "> Well, I want to use Gentoo but i don't realy like the idea of spoiling
>
> > my weekend by installing an OS thats gonna stop working 30 times
> > booting later.
>
> I doubt this is really Gentoo-specific."
> - you're right on that, I love gentoo, but I hope you understand what I
> mean.
>
> 1. My kernel version is gentoo-2.6.17-r7 - so it isn't an experimental
> kernel
>
> I can't post my emerge-info now because I don't have everything needed
> for booting (monitor and stuff)
>
> 2. You really made me doubt about that, but I don't think that is the
> problem. I'll do some more research on that.
>
> 3. I'll look for that next weekend =)
>
> Thank you =)

Maybe you could try another filesystem. I don't think that your issues depend 
on the choosen filesystem. But trying another one may gives you further hints 
what is really going on.

rgds

Bernhard
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] fsck seems to screw up my harddisk

[Richard Freeman]

[-- Attachment #1: Type: text/plain, Size: 1022 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alexander Gabert wrote:
> from man mke2fs:
> 
>        -c     Check  the  device  for bad blocks before creating the
> file system.  If this option is specified twice,
>               then a slower, read-write test is used instead of a fast
> read-only test.
> 
> Please try this and report back if you found something.
> There is also low level test programs of disk vendors where you can
> stress test the brick to make sure it's not faulty.
> 

Uh, just keep in mind that if you do this you won't have much of a
chance of recovering what used to be on the drive.  I'm not sure that
the FIRST thing I'd try doing is wiping the filesystem.  There are other
tools that can do a disk scan non-destructively (spinrite, etc).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFa2m/G4/rWKZmVWkRAtYKAJ9qvMWhYEZu/SuDv8Q+N5Ilw8D37gCfes0Q
IGHI9iGKtkNBTFzCcAVkldI=
=FQqi
-----END PGP SIGNATURE-----

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3875 bytes --]

Re: [gentoo-amd64] fsck seems to screw up my harddisk

[Richard Fish]

On 11/27/06, Guido Doornberg <guidodoornberg@gmail.com> wrote:
> 1. My kernel version is gentoo-2.6.17-r7 - so it isn't an experimental kernel

Ok, just wanted to make sure. ;-)  I've obviously been spending _way_
too much time browsing the gentoo forums, as I'm starting to suspect
*everybody* is a "ricer".

-Richard
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] fsck seems to screw up my harddisk

[Guido Doornberg]

Hi again,

Well, I downloaded and started a fresh 2006.1 livecd, repartitioned de
hdd, started mke2fs and this time with the -c option.

So, it started checking and after about 15 minutes this kept on
showing up on my screen:

ata1: error=ox40 {uncorrectable error}
ata1: translated ATA stat/err 0X51/40 SCSI SK/ASC/ASCQ 0x3/11/04

after a while i got a couple of other messages,
and now it keeps on talking about Buffer I/O error on device sda3, and
after that various sectors and blocks are called.

I did look after my power supply and I'm for 99% sure that's not the
problem. So, correct me if i'm wrong but that would mean my harddisk
is the problem? But how than is it possible that I can use it normally
if I don't let fsck check it?

I know this isn't really gentoo specific anymore, but if anyone knows
what to do i'm happy to hear it.
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: fsck seems to screw up my harddisk

[Duncan]

"Guido Doornberg" <guidodoornberg@gmail.com> posted
eb2db630612030540k38b658b2q3571a712efc510d0@mail.gmail.com, excerpted
below, on  Sun, 03 Dec 2006 14:40:11 +0100:

> Well, I downloaded and started a fresh 2006.1 livecd, repartitioned de
> hdd, started mke2fs and this time with the -c option.
> 
> So, it started checking and after about 15 minutes this kept on showing up
> on my screen:
> 
> ata1: error=ox40 {uncorrectable error} ata1: translated ATA stat/err
> 0X51/40 SCSI SK/ASC/ASCQ 0x3/11/04
> 
> after a while i got a couple of other messages, and now it keeps on
> talking about Buffer I/O error on device sda3, and after that various
> sectors and blocks are called.
> 
> I did look after my power supply and I'm for 99% sure that's not the
> problem. So, correct me if i'm wrong but that would mean my harddisk is
> the problem? But how than is it possible that I can use it normally if I
> don't let fsck check it?
> 
> I know this isn't really gentoo specific anymore, but if anyone knows what
> to do i'm happy to hear it.

Your suspiciouns seem correct to me as well.

I've had several hard drives go partially bad over the last several years. 
The last one I know was due to heat as I'm in Phoenix, AZ, with highs in
the summer approaching 50 C (122 F), and my AC went out.  Since it
followed the same basic pattern of another one previous to that, I expect
the problem with the previous one was heat as well tho I'm not positive.

What happens when the drives overheat is the platters expand and the heads
crash into them, thereby digging grooves (which I could see taking the
drive apart later) in the platters.  Of course, the data will be destroyed
at for those disk cylinders, basically wherever the head seeked to
while the platter was hot enough to crash it, but the rest of the drive is
recoverable, and from my experience, somewhat stable, provided the drive
doesn't overheat again.  Due to the way I have my system setup (see below)
and what was damaged, I was actually able to continue to use the system
for some time.  Never-the-less, get anything you want saved off it ASAP,
preferably leaving it shut off until you can, just in case, after which
you can work around the problem if you wish, marking badblocks, and use
the disk for either temp stuff only or always backed up stuff, from then
on.

It's possible for particularly drives used for mobile applications to have
similar head-crashes, due to dropping the laptop or whatever, and there
may be other ways to generate that pattern as well.

How to work around the issue?  First, as I said, backup the disk, or at
least anything of value on it.  Of course, this likely won't apply since
you were setting up a new system on it anyway, but for completeness... If
you run into areas that won't easily copy, and you want to recover the
data if possible, there's a package, sys-apps/dd-rescue, or it should be
available on any good recovery LiveCD.  (I doubt it's on the Gentoo
install CDs, but you can check). dd_rescue is the same idea as the normal
Unix dd utility, but the rescue version is designed to try from the
beginning of a partition forward until it runs into problems, then from
the end backward, then in the middle of anything still left unread, until
it has copied as much of the partition as possible. You can then fsck the
recovered copy and see what can be repaired.  Note, however, that this is
a process that will take awhile, hours, possibly days, depending on how
much of the disk is damaged, as the drive tries several times to read the
data, and if it fails the software will have it try /again/ several times.
 Depending on your i/o system, you aren't likely to be able to do much
else with the system while this is going on, as it'll tend to lock things
up pretty badly during the try and fail and try again phase.  Of course,
this will be repeated for each bad block, so it WILL take awhile if more
than a handful of blocks are damaged. Recovery of all the data is
obviously not guaranteed in any case, and you may simply decide it's not
worth the hassle.  Google or see the dd_rescue manpage for details.

It should be noted that dd_rescue can be configured to report the
badblocks as it goes, so you can skip the badblocks mapping step below if
you use it to recover existing data, and save its badblocks report to be
reused later.

If you skip data recovery attempts, or simply want to test any disk before
you use it, you'll want another app, badblocks, likely installed already as
a part of sys-fs/e2fsprogs. badblocks can scan the disk in either
(non-destructive) read/read-over/compare mode, non-destructive
read/write-back/read-back/compare mode, or destructive
write-pattern/read-back/compare mode.  Do NOT use the destructive mode if
there's stuff on the partition you want to keep, as it WILL overwrite it.

However you generate the badblocks report, using either the output of
dd_rescue or badblocks, you then use this information when setting up your
disk again.  It's probably wise to setup multiple partitions, leaving the
large bad areas unpartitioned.  For smaller bad areas of just a handful of
blocks, one of the parameters you can feed mkfs is a badblocks list. 
Again, check the manpages or google for the details, but when you are
done, you should be left with a working and fsck-able set of partitions
once again, since the badblocks are either excluded from the area you
partitioned, or listed as badblocks in the superblock area of the
filesystem you created using that parameter with your mkfs, and therefore
avoided.

---
*  For reliability purposes, I had my system setup with multiple copies of
most of my partitions.  The idea was periodically, when the system seemed
stable, I'd backup my main working copy of all the critical partitions,
and could therefore boot a not-too-old backup copy in the event something
broke on my main working copy.  Basically, all it took (and all it
continues to take) is appending a different root= parameter to the kernel
command line, to boot the rootmirror.  Thus, when portions of the drive
were damaged, they were naturally the portions the head had tried to seek
to during the time the drive was overheated, which means they were in the
partitions mounted at the time.  The unmounted partitions were therefore
undamaged and after finding the system crashed due to the overheating,
once I cooled things back down, I could boot to the backup partitions and
resume from there.  As it happened, only a couple of my working partitions
were damaged, and I was able to use the working copy of all the other
partitions.

In terms of partitioning strategy... with my old system I made the mistake
of separating /var and /usr onto their own partitions, and then trying to
mix and match backup partitions with working copy partitions.  That didn't
work so well, because the portage records of what were installed were from
the backup and therefore outdated /var partition, while /usr and root were
the working copies, so portage had the wrong package versions as being
installed.  Since I had use FEATURES=buildpkg and had all the packages
available in binary format, it was easy to simply reinstall everything
from them, updating the portage database, but because it wasn't accurate,
it couldn't unmerge the non-existing old versions, so I ended up with a
bunch of stale and orphaned files strewn around.

When I upgraded from that disk, which I did as soon as I could since I
didn't trust it even tho it was working, I therefore setup things a bit
differently.  What I'd suggest today would be keeping /var and /usr on
your root partition, but putting /var/log and /var/tmp and /usr/portage
and /usr/src, as well as stuff such as /home, on on other  partitions. 
(You can use one and either use mount --move or simply symlink, if you
want to put several dirs from different places in the tree on the same
partition.)

Basically, anything that portage installs stuff to, along with its
database in /var/db, should be kept on the same partition, so every backup
of that partition will have the portage database in sync with what's
actually installed, since it's the same partition.

Here, my / partition and backup snapshots are 10 GB each.  That's plenty
of room to spare for me, since less than two GB are actually used.  I'd
recommend a total of three copies of it, the working or main copy, and two
snapshot backups of the same exact partition size.  The idea being that
you can alternate backups, so even if something happens after you've
erased the one backup in preparation for copying over the working system
as a new snapshot, so that backup is erased or incomplete at the
same time the working copy dies, you'll still have the other backup to fall
back to.

Similarly with partitions such as /home and /usr/local that hold data I
want to be sure and keep.  2-3 copies of each, a working and 1-2 backup
copies.  /var/log you probably don't need a copy of.  Same with wherever
you have your portage tree, since you can always just sync it to get
another if it's destroyed, and with /tmp and /var/tmp, since that's temp
data anyway and doesn't need a redundant copy kept.

Actually, while that can be implemented well on one or two disks, here, I
got tired of hard drive problems, and I'm now running a four-disk kernel
based SATA RAID, Seagate drives, 5-yr warrantee, altho they aren't quite
as fast as some of the others you can buy.  Booting requires RAID-1 so I
have a small RAID-1 partition mirrored across all four drives.  That's
/boot. Most of my system is RAID-6, which in a four-way system is
effectively a two-way stripe with two parity stripes as well.  Thus, I can
lose any two of the four drives and anything on the RAID-6 will still be
recoverable.  Stuff like /tmp, the portage tree, etc, that's either easily
redownloaded off the net or is temporary anyway, is on a 4-way RAID-0 for
speed.  If any of the four drives goes down, all that data is lost, but
that's fine, since it's either temporary or easily recovered anyway. 
Likewise, my swap is four-way striped.  Disk read/write speed on this
four-way striped area is incredibly fast (for hard drive access), since
drives are so much slower than the bus connecting them to the system,
meaning the system can keep the bus busy doing i/o to all four devices
instead of just to one, and then having to wait for the slow drive.  The
problem with RAID-0, however, is that while it's far faster, it's also far
riskier, since you lose it if you lose any of the component devices. 
Fortunately, the data that is easiest to replace is also generally the
most speed critical, so it works out quite well. =8^)  I have RAID-1
mirrored for /boot, RAID-6 for safety for most of my system, and RAID-0 for
speed where I don't care if the data dies.  On top of that, for the parts
of the system I really care about, I keep several snapshots around on the
RAID-6, thus protecting me both from fat-finger syndrome deletions (where
RAID won't help, unfortunately) with the multiple snapshots, and from
device failure with the RAID-6.  As an added bonus, since I'm running
kernel-RAID, it's not hardware specific, so if the SATA chip dies, all I
have to do is buy a new 4-way SATA board, plug the existing drives into
the new board, and compile a new kernel (from a liveCD or whatever) with
the appropriate new SATA drivers, and I'm up and running again.  If I had
gone hardware RAID and it died, I'd have to get another one like it to
plug into, if I wanted to recover my data, something I don't have to worry
about with kernel-raid. =8^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: fsck seems to screw up my harddisk

[Drake Donahue]

----- Original Message ----- 
From: "Duncan" <1i5t5.duncan@cox.net>
To: <gentoo-amd64@lists.gentoo.org>
Sent: Sunday, December 03, 2006 12:04 PM
Subject: [gentoo-amd64] Re: fsck seems to screw up my harddisk


> "Guido Doornberg" <guidodoornberg@gmail.com> posted
> eb2db630612030540k38b658b2q3571a712efc510d0@mail.gmail.com, excerpted
> below, on  Sun, 03 Dec 2006 14:40:11 +0100:
>
>> Well, I downloaded and started a fresh 2006.1 livecd, repartitioned de
>> hdd, started mke2fs and this time with the -c option.
>>
>> So, it started checking and after about 15 minutes this kept on showing 
>> up
>> on my screen:
>>
>> ata1: error=ox40 {uncorrectable error} ata1: translated ATA stat/err
>> 0X51/40 SCSI SK/ASC/ASCQ 0x3/11/04
>>
>> after a while i got a couple of other messages, and now it keeps on
>> talking about Buffer I/O error on device sda3, and after that various
>> sectors and blocks are called.
>>
>> I did look after my power supply and I'm for 99% sure that's not the
>> problem. So, correct me if i'm wrong but that would mean my harddisk is
>> the problem? But how than is it possible that I can use it normally if I
>> don't let fsck check it?
>>
>> I know this isn't really gentoo specific anymore, but if anyone knows 
>> what
>> to do i'm happy to hear it.

visit
http://www.samsung.com/Products/HardDiskDrive/warranty/index.htm
and get replacement
current crop of spinpoint is getting bad reports for reliability 

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] fsck seems to screw up my harddisk

[Peter Humphrey]

On Tuesday 28 November 2006 01:49, Richard Fish wrote:

> I'm starting to suspect everybody is a "ricer".

Er, what's one of those? I assume it's an Americanism.

-- 
Rgds
Peter
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] fsck seems to screw up my harddisk

[Jesús Guerrero]

El Mon, 4 Dec 2006 10:16:58 +0000
Peter Humphrey <prh@gotadsl.co.uk> escribió:

> On Tuesday 28 November 2006 01:49, Richard Fish wrote:
> 
> > I'm starting to suspect everybody is a "ricer".
> 
> Er, what's one of those? I assume it's an Americanism.
> 
Nah, it is a word that people around use to use to name those persons
that think that any hyper patched kernel is the best thing to make your
computer like 10 times faster. Those use also to have an insane amount
of custom cflags, ldflags and the like. Of course, for a ricer is also
important to run ~arch for most packages, except for system packages
and the toolchaing, where they usually prefer to use something like
gcc-7.0_alpha1 releases (joking, of course).

It somewhat a word play, with "racer", like if all these so-called
"optimizations" made your box go at the speed of light :P

You can find a funny thread about ricers and "ricing" in general in the
gentoo forums:

http://forums.gentoo.org/viewtopic-t-309752-highlight-ricer.html

Jesús.

-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: fsck seems to screw up my harddisk

[Duncan]

Peter Humphrey <prh@gotadsl.co.uk> posted
200612041016.58159.prh@gotadsl.co.uk, excerpted below, on  Mon, 04 Dec
2006 10:16:58 +0000:

> On Tuesday 28 November 2006 01:49, Richard Fish wrote:
> 
>> I'm starting to suspect everybody is a "ricer".
> 
> Er, what's one of those? I assume it's an Americanism.

The term is borrowed from the automotive scene, where "ricer" refers to
those that are into the performance scene -- particularly mods like racing
decals, dual exhaust pipe ends, and the like, that are designed to /look/
impressive (to that set, anyway), but don't actually raise performance.

Wictionary and Wikipedia both have entries in this context:

http://en.wiktionary.org/wiki/Ricer

Unfortunately, use in this context apparently hasn't made it into most
dictionaries (at least those listed at onelook.com), as most only list the
term in the sense of wiktionary definition 1 (a cooking utensil).

http://en.wikipedia.org/wiki/Ricer

It's quite popular among users of binary distributions to mock Gentoo as a
ricer distribution.  One must admit such folks will be attracted to
Gentoo, but of course as users, we know there are other reasons to use it
as well -- including on the technical side the amount of possible
customization, thus appealing to the power user who likes being in
control, regardless of how interested in performance they may or may not
be, and on the social side, a relatively large/active/helpful user
community and rather more (quantity) and more useful documentation than is
available for many/most distributions.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] fsck seems to screw up my harddisk

[Boyd Stephen Smith Jr.]

[-- Attachment #1: Type: text/plain, Size: 603 bytes --]

On Monday 04 December 2006 04:16, Peter Humphrey <prh@gotadsl.co.uk> wrote 
about 'Re: [gentoo-amd64] fsck seems to screw up my harddisk':
> On Tuesday 28 November 2006 01:49, Richard Fish wrote:
> > I'm starting to suspect everybody is a "ricer".

Gentoo *is* rice, optimized. ;)

> Er, what's one of those? I assume it's an Americanism.

http://funroll-loops.org/

-- 
"If there's one thing we've established over the years,
it's that the vast majority of our users don't have the slightest
clue what's best for them in terms of package stability."
-- Gentoo Developer Ciaran McCreesh

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-amd64] fsck seems to screw up my harddisk

[Guido Doornberg]

So, here I am again,

now without the samsung drive, but this time (same system), with a
software RAID-1, on 2 Western Digital Caviar Disks, working with ext2
on the boot-, and reiserfs on the rootpartition.

Anyway, every time the system shuts down, the last things my pc tells me are:

* Unmounting filesystems ...						[ ok ]
* Shutting down RAID devices (mdadm) ...
md: md1 stopped.
md: unbind<sdb1>
md: export_rdev(sdb1)
md: unbind<sda1>
md: export_rdev(sda1)
md: md2 stopped.
md: unbind<sdb2>
md: export_rdev(sdb2)
md: unbind<sda2>
md: export_rdev(sda2)
md: md3 still in use.
md: md3 still in use.
md: md3 still in use.
mdadm: stopped /dev/md1
mdadm: stopped /dev/md2
mdadm: fail to stop array /dev/md3: Device or resource busy		[ !! ]
* Remounting remaining filesystems readonly ...				[ ok ]
md: stopping all md devices.
md: md3 still in use.
Synchronizing SCSI cache for disk sdb:
Synchronizing SCSI cache for disk sda:
System halted.

So, my question is quite simple i guess; Is it normal that my array
(/dev/md3) doesn't like to be stopped? And if it isn't, how can I make
it stop?

btw, if you think I should post this kind of questions somewhere else,
I'd be happy to hear so...

thanks
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] fsck seems to screw up my harddisk

[Adam James]

On Fri, 12 Jan 2007 16:38:21 +0100 "Guido Doornberg"
<guidodoornberg@gmail.com> wrote:

> So, my question is quite simple i guess; Is it normal that my array
> (/dev/md3) doesn't like to be stopped? And if it isn't, how can I make
> it stop?

It would be helpful if you told us what filesystems you have mounted
on '/dev/md3'.

If it is your root partition, then it makes sense that it cannot be
unmounted, as the programs and files used in the shutdown are located
on it! This is not a problem however, as part of the shutdown process is
to remount as read-only any filesystems that cannot be cleanly
unmounted.

> * Remounting remaining filesystems readonly ...				[ ok ]

This prevents any further writes to the disk, while still allowing
processes access to their data.

> Synchronizing SCSI cache for disk sdb:
> Synchronizing SCSI cache for disk sda:

Disk buffers are then synchronised to disk, removing any risk of data
corruption, and the system is halted.

> System halted.

So in answer to your question, it is quite normal and is not a problem.
If '/dev/md3' does not house your root partition, then it probably
contains a daemon that is refusing to shutdown in an orderly
manner. Running `lsof /partition` might help you track it down.

-atj
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] fsck seems to screw up my harddisk

[Guido Doornberg]

Great =), that's one problem less to worry about then...

thank you =)
-- 
gentoo-amd64@gentoo.org mailing list