[SLUG] RAID5 Woes

2010-04-17 Thread Kevin Fitzgerald
Hi All

I need advice. In a nutshell I have a customer with a 5 Disk Software RAID 5 on 
an old Fedora Box (The Archive Box). Recently, after a power failure, Two of 
the drives did  not re-join the Array when the machine came back up. DMESG 
tells me that they are Not Fresh.

So the Drives are working as far as I can tell and I want to re-build the array.

This machine was the companies Archive server and as a result has some Old Old 
Old Data that we need to recover. Backups were infrequent on this machine (It's 
the archive server right?..sigh) so I dont have a useable backup I can go 
from. The Painful irony is that I was about to Move all this old data onto a 
VMWare machine in the next month.sigh again.

Assuming the disks are there and OK, How do i "Freshen" them up and re-build 
the software RAID array?.  I need to be careful as I dont want to do more 
damage while trying to re-build.

And if I cant get any answers can anyone recommend a great Data Recovery mob in 
Sydney?

Kev

--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


Re: [SLUG] RAID5 Woes

2010-04-17 Thread Daniel Pittman
Kevin Fitzgerald  writes:

> I need advice. In a nutshell I have a customer with a 5 Disk Software RAID 5
> on an old Fedora Box (The Archive Box). Recently, after a power failure, Two
> of the drives did not re-join the Array when the machine came back up. DMESG
> tells me that they are Not Fresh.

Take an image of the disks, because if you mess this up you lose the data.
The cost of three new disks and copying them won't hurt that much.

[...]

> Assuming the disks are there and OK, How do i "Freshen" them up and re-build
> the software RAID array?

>From mdadm(8) in the 'Assemble' section:

  -f, --force
 Assemble  the  array even if the metadata on some devices appears to
 be out-of-date.  If mdadm cannot  find  enough  working  devices  to
 start the array, but can find some devices that are recorded as hav‐
 ing failed, then it will mark those devices as working so  that  the
 array can be started.  An array which requires --force to be started
 may contain data corruption.  Use it carefully.

> I need to be careful as I dont want to do more damage while trying to
> re-build.

Image the disks first.  There is no guarantee of safety in this.

Daniel

-- 
✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707
   ♽ made with 100 percent post-consumer electrons
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


Re: [SLUG] Debian Lenny HAL Config

2010-04-17 Thread Chris Perry

Rodolfo,
This did the trick.  You would not believe how close I was to working 
this out before.  I was just missing the "=".  Oh well.


The hal version:
peterpan:/etc/hal/fdi/policy# hald --version
HAL package version: 0.5.11

I guess the problem I am experiencing is a bug on the package.  Are you 
a good person to take this information to the appropriate Team?


I have spent some time attempting to figure out the relationship between 
udev and hal.  It seems that udev gets things first and passes a result 
to hal.  Right?  I say this because the last udev rule says:

RUN+="socket:/org/freedesktop/hal/udev_event"
It also seems to me that udev sets the group permissions for the mount 
command, but the config in gconf (as used by hal) was blanking it out.  
If this is right I must say I had lots of trouble working it out because 
I cannot figure how to insert and use debug statements to check things, 
or where low level logging might go.


If you could assist with a udev rule to permanently mount a usb card for 
my user, I would really appreciate it.  As I said I have made a few 
tentative additions to existing rules and observed no discernible change 
in system behavior.  I'm looking at:

http://reactivated.net/writing_udev_rules.html

Relevant output from udevinfo -a -p $(udevinfo -q path -n /dev/sdc1)
 looking at parent device '/devices/pci:00/:00:02.1/usb2/2-6':
   KERNELS=="2-6"   
   SUBSYSTEMS=="usb"

   DRIVERS=="usb"   <===
   ATTRS{configuration}==""
   ATTRS{bNumInterfaces}==" 1"
   ATTRS{bConfigurationValue}=="1"
   ATTRS{bmAttributes}=="80"
   ATTRS{bMaxPower}=="200mA"
   ATTRS{urbnum}=="370236"
   ATTRS{idVendor}=="0930"  <==
   ATTRS{idProduct}=="6545" <==
   ATTRS{bcdDevice}=="0110"
   ATTRS{bDeviceClass}=="00"
   ATTRS{bDeviceSubClass}=="00"
   ATTRS{bDeviceProtocol}=="00"
   ATTRS{bNumConfigurations}=="1"
   ATTRS{bMaxPacketSize0}=="64"
   ATTRS{speed}=="480"
   ATTRS{busnum}=="2"
   ATTRS{devnum}=="28"
   ATTRS{version}==" 2.00"
   ATTRS{maxchild}=="0"
   ATTRS{quirks}=="0x0"
   ATTRS{authorized}=="1"
   ATTRS{manufacturer}=="TOSHIBA"   <===
   ATTRS{product}=="TransMemory "   <===
   ATTRS{serial}=="0220787042A168B4"

BTW, what/why is there a difference between SUBSYSTEM and SUBSYSTEMS?

Regards,
Chris

Rodolfo Martínez wrote:

Hi Chris,

The line should be:

gid=

Note the '=' after 'gid'. The '=' means that HAL accept any value for that key.

And the gconf mount options should include  'gid=1004'.

  

On a related but different topic, how do I force hal to always mount the usb
card as me (chris).  I am not the only user on the console, I have to play
round robin and a game of chance for the card to be mounted under my uid.



The only solution for this is to specify the mount options (uid, gid,
etc.) in /etc/fstab. HAL will search for an entry that matches the
device that will be mounted, if none matches, it will mount the device
using the default values/options. The default is to mount the device
on behalf of the user that invoked the mount petition.

The problem is that the device block won't be always the same, it
could be /dev/sdc1, /dev/sdd1 and so on, but this can be easy
addressed with a udev rule, let me know if you need help with this.

BTW, what version of HAL are you using?


--
Rodolfo Martínez
  


--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html