Tag Info

Hot answers tagged

11

First check the disks, try running smart selftest for i in a b c d; do smartctl -s on -t long /dev/sd$i done It might take a few hours to finish, but check each drive's test status every few minutes, i.e. smartctl -l selftest /dev/sda If the status of a disk reports not completed because of read errors, then this disk should be consider unsafe for ...


5

You have a fake hardware raid controller. In reality it is a pure software raid, that happens to have bios support. If you do not need to dual boot with Windows, then you are better off not using it, and instead using pure Linux software raid, which has far better support. To rebuild the system that way, first delete the raid array in the bios utility, ...


5

In case of a software raid setup on Windows this is probably a fake-raid. You should install the package dmraid which will handle access to such raid-5 systems. Do make a backup of your data before you start. You can try out dmraid by booting from CD and installing it, without any need to change the Windows setup. dmraid probably only works on the hardware ...


3

Yes, you can (provided you have a 3.2+ kernel). First, add a new drive as a spare: mdadm /dev/md0 --add /dev/sdc1 (replace md0 and sdc1 with your RAID and disk device, respectively). Then, initiate a copy-replace operation like this: echo want_replacement > /sys/block/md0/md/dev-sdd1/state Where md0 is, again, your RAID device, and sdd1 is the ...


3

How did you partition the disks the first time? If you used fdisk, you may have limited yourself to just the first 2 TB of each disk, as that's the maximum partition size you can create with fdisk. As such, your raid device probably looks more like a RAID5 of 3 * 2TB disks. Use parted to create your larger than 2TB partition. Example: [root@evil ...


3

In RAID-5, unless your write was large enough to cover all data chunks for a given parity chunk, it has to read the missing data chunks in order to be able to recalculate and update parity. Thus a relatively small write on a RAID-5 can turn into a large read operation. RAID-1 does not need such additional reads, as there is no parity, it just writes to all ...


3

So you're inside a rescue system now? You need mount all these LVs somewhere, for example to /mnt/target: lv_root -> /mnt/target/ lv_boot -> /mnt/target/boot lv_home -> /mnt/target/home ... Then you need to bind-mount the kernel filesystems: for i in proc sys run dev; do mount --bind /$i /mnt/target/$i; done Now you can change into this "dead" system ...


2

If you actually have a RAID configured through hardware (i.e., the operating system sees fewer physical disks than you actually have) there's no hardware to software conversion method. You have to back up the data to an alternate location, convert the RAID manually, and restore.


2

I assume Linux's software RAID is as reliable as a hardware RAID card without a BBU and with write-back caching enabled. After all, uncommitted data in a software RAID system resides in the kernel's buffer cache, which is a form of write-back caching without battery backup. Since every hardware RAID-5 card I have ever used allows you to enable write-back ...


2

RAID should only resync after a server crash or replacing a failed disk. It's always recommended to use a UPS and set the system to shutdown on low-battery so that a resync won't be required on reboot. NUT or acpupsd can talk to many UPSes and initiaite a shutdown before the UPS is drained. If the server is resyncing outside of a crash, you probably have ...


2

If you don't mind running RAID-6 (2 parity disks rather than 1), and if you're running mdadmin 3.1.x or higher, you could convert your RAID-5 array to RAID-6 to add an additional parity disk. This will will place the array under stress during the rebuild, however. And it has some performance implications since there are more parity disks to update during ...


2

Using mdadm 3.3 Since mdadm 3.3 (released 2013, Sep 3), if you have a 3.2+ kernel, you can proceed as follows: # mdadm /dev/md0 --replace /dev/sdd1 --with /dev/sdc1 sdd1 is the device you want to replace, sdc1 is the preferred device to do so and must be declared as a spare on your array. The --with option is optional, if not specified, any available ...


1

Basically, everything except for /boot & update initramfs is the same. I'll assume that your old boot is /dev/sda1. These steps should look familiar if you've ever used a live CD/USB as a rescue disk: # mount /dev/vg0/root /mnt # or whatever your vg/lv name is. # mount --bind /dev /mnt/dev # make these available inside of /mnt # mount --bind ...


1

Safest solution might be to configure your RAID5/LVM disks then reboot the system using a live cd having gparted on it (see http://gparted.sourceforge.net/). You can then clone your partitions onto the LVM volumes quite easily.


1

You could simply do a 'rsync' from the old disk to the new disk. Something like this should work: rsync -rtv "/mnt/old_drive" "/mnt/new_drive" You would replace the above locations with the mount points of your disks on your computer. To find where your disks are mounted to or what device they are showing up as you can use: df -h and... cat ...


1

This may be possible meeting the requirements online don't stress any disk except for the one which is to be replaced But even if the following may work you will probably not find any recommendation of that kind "in the books"... Idea: Take disk OLD out of the array (for a short moment): mdadm --manage /dev/raid5 --fail /dev/OLD Create a new md device ...


1

Assuming the RAID doesn't have any files on it yet; you'd format it using LUKS for encryption: cryptsetup luksFormat /dev/md42 then you'd open the LUKS container crytpsetup luksOpen /dev/md42 luks42 if you want to use LVM with that, you'd turn it into a Physical Volume: pvcreate /dev/mapper/luks42 and if you want to add that to your existing volume ...


1

I'd just wait for the RMA. If you try to reformat and rebuild the array, you'll be putting extra stress on the two good disks for (probably) no good reason which is risky. If it's a server, leave the disk in there for air flow until the new disk arrives.


1

I experienced many problems while I used mdadm, but never lost data. You should avoid the --force option, or use it very carefully, becasuse you can lose all of your data. Please post your /etc/mdadm/mdadm.conf


1

This seem trivial, which probably means I misunderstood it. If I understand it correctly: One disk with /, /boot and swap. One disk on a RAID array with other directories, such as /var, /srv etc. What prevents you from booting, mounting the disksand creating soft links from / to the folders on the RAID array? Or did you make separate partitions from ...


1

I have a similar setup and I can recommend to have a complete Linux on the small partition of each drive and not mirror those small partitions, but have them separately completely boot-able. You can sync the setup excluding a few crucial files (/etc/fstab, grub configuration). This takes more space than just /boot but saves a lot of time when troubles hit. ...


1

The short answer is: yes, it is possible. Linux software RAID writes some meta information on the devices such that you can easily plug them into another system (using another controller and so on) and use them there. Before doing any assembling, you can query the devices (status, look what Linux think what part of what RAID this device was etc.). When you ...


1

What you should do here is trigger a SMART self-test on the bad drive(s). That will pull a lot of the controller/motherboard pieces out of here and give you a better reading on the underlying disks having issues. It's possible for non-drive failure to give wrong results there--power supply failure is the most common cause--but it's a good start. It will ...


1

SW RAID does have a failure mode - if the server goes down halfway through a write you can get a corrupted stripe. A HW RAID controller with a BBU isn't all that expensive, and it will retain dirty blocks until you can restart the disks. The BBU on the cache does not guarantee writes in the event of power failure (i.e. it does not power the disks). It ...


1

Just a warning notice : RAID-5/6 write operations take a significant CPU time while your array is degraded. If your server is already fully loaded when a disk comes to fail, it may drop into an abyss of unresponsiveness. Such problem won't happen with a hardware RAID controller. So I'd strongly advise against using software RAID-5/6 on a production server. ...



Only top voted, non community-wiki answers of a minimum length are eligible