Tag Info

Hot answers tagged

10

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 ...


9

I just had a similar problem to what you describe, though for me it happened when I was attempting to install the new Ubuntu 11.10 Oneiric Ozelot to an LVM volume. I had done the following to set lvm up on a live boot system (the logical volumes I needed were already present): apt-get install lvm2 vgscan --mknodes -v Now lvscan -v showed my volumes but ...


9

Use mdadm, check the manpage. However, I will list one gotcha here. If you do this and really want reliability, you should make sure your master boot record is copied to both drives. By default it will likely only get copied to one drive. If that drive dies, you cannot boot from the other drive, even though all your data is safe. To copy the mbr to both ...


8

Open the /etc/mdadm/mdadm.conf file, find the line that begins with ARRAY /dev/md1 and remove the line immediately following which states 'spares=1'. Then restart mdadm service. If you did a mdadm --examine --scan to retrieve the array definitions while the md1 array was still rebuilding, one partition was seen as spare at that moment.


7

Q#1: Can you set up a RAID system using USB sticks as the storage media You should be able to use any block storage devices in a RAID. Any standard directions for setting up a RAID using SATA HDD's should be applicable when using USB storage as well. You'll have to set it up so that the USB devices are assembled as members of the RAID array. Q#2: ...


6

You can create an mdraid RAID-1 array starting with an existing partition. First, you need to make room for the mdadm superblock, which means you need to shrink your filesystem a little. At the moment, the normal superblock format is 0.9. Its location is between 128kB and 60kB from the end of the partition, it is 4kB long, and it starts on an address that ...


6

All these "poke the sector" answers are, quite frankly, insane. They risk (possibly hidden) filesystem corruption. If the data were already gone, because that disk stored the only copy, it'd be reasonable. But there is a perfectly good copy on the mirror. You just need to have mdraid scrub the mirror. It'll notice the bad sector, and rewrite it ...


6

The right thing to do is something like mdadm --add /dev/md0 /dev/sdb1. Use the correct array in place of md0 and the correct partition in place of sdb1. The key thing is the array is running. Its completely unambiguous which data to copy: the data that is currently running. If you have bitmaps enabled, the resync will be fairly fast as it'll only copy what ...


6

Simply run mdadm --build -l1 -n2 /dev/md0 /dev/dm-10 /dev/dm11 to get your data back. Verify that the devices are correct (or use the aliases from /dev/mapper) before doing this! Also, if your kernel has already used (or is using) one of these devices, data will be inconsistent. You should set up the second device as a degenerate 1.2 array, copy the data ...


5

Yes grub2 is fully raid ( and LVM ) aware. In fact you do not need a separate /boot partition at all; you can just put everything on the raid5. Ideally you want to not install with a /boot partition at all, but removing it after the fact simply means copying all of the files to the root partition, and reinstalling grub, like this: umount /boot mount ...


5

Assuming this is linux, this is doable and pretty easy actually. It is covered on the software raid wiki but the basic steps are: Fail and remove drive. Replace with a larger drive. Partition the drive so the partitions are the same size or larger than the ones in the existing software raid partition. Add the partitions to software RAID and wait for it to ...


5

Chunk size does not apply to raid1 because there is no striping; essentially the entire disk is one chunk. In short, you do not need to worry about the 4k physical sector size. Recent versions of mdadm use the information from the kernel to make sure that the start of data is aligned to a 4kb boundary. Just make sure you are using a 1.x metadata format.


4

These days /dev is on tmpfs and is created from scratch each boot by udev. You can safely reboot and these links will come back. You should also find LVM symlinks to the /dev/dm-X nodes in the /dev/<vg> directories, one directory for each volume group. However, those nodes re-created by vgscan --mknodes will also work fine, assuming they have the ...


4

I've just had pretty much the same problem with a RAID1 array. The bad sector was right at the beginning of one of the partitions - sector 16 of /dev/sdb2. I followed the instructions above: after verifying that logical block 2 was not in use by the file system and being careful to get dd seek and skip the right way around, and zeroed out 1 file system ...


4

Linux mdraid has several metadata formats. Formats 0.9 and 1.0 put the metadata at the end of the containing device, and the payload (the filesystem) starts at the beginning of the device and can be accessed directly without going through the raid layer. Formats 1.1 and 1.2 put the metadata at the middle and beginning of the containing device respectively, ...


4

First, you create the raid array. Assuming the new drives are sdc, sdd, and sde, and you don't already have any raid arrays, and you have created a single raid partition on each, do: sudo -s mdadm --create /dev/md0 -n 3 -l raid5 /dev/sd[cde]1 mdadm --detail --scan >> /etc/mdadm/mdadm.conf Then you add it to the vg, move the logical volumes over, ...


4

If it's RAID 1 with 0.90 superblock, you should be able to mount directly without using the RAID layer at all. Data starts without offset at the beginning of the disk, so there should be no problem. Use the read-only mount option or a read-only loop device for the experiment just in case. If that works, the simplest method would be to use the other disk to ...


4

Given that chunks can be quite big and that the parity information is simple XOR (i.e. does not affect data before or after the piece in question) the assumption that only complete chunks can be written does not make sense to me. Chunks are the unit in which data is spread over the volumes. One chunk of continuous data is written to a certain volume, the ...


3

I poked around /sys and got a lot closer to the answer. # cd /sys/block/md0/md # cat component_size 2147479552 That agrees with what we have seen before. But this: # grep . dev-sd*/size dev-sdc/size:2147482623 dev-sdd/size:2147482623 dev-sde/size:2147482623 dev-sdf/size:2930265560 dev-sdg/size:2147482623 dev-sdh/size:2147482623 dev-sdi/size:2147482623 ...


3

I think during creation the size of the device was registered somewhere in the metadata. Changing the controller doesn't change the metadata. Remove the spare from the md, then re-add it to the RAID set as a new drive. You probably have to remove the metadata (check man page for --zero-superblock or wipe the whole disk). If that works for a single disk, ...


3

RAID is resyncing HDD There are 2 hints: "State : active, resyncing" "Rebuild status : 17% complete" It seems that your system is rebuilding your array (or it did not finished syncing it during installation). It should be bootable again once the array is finished rebuilding. For the time being, you could ty to boot in degraded mode at least. You can ...


3

However, there is no big difference in raid0 and lvm stripe; seems lvm is better choice. raid0 with mdadm supports drives with different size and its size equals to sum capacity of drives. Unfortunately raid0 mdadm can't add new drives without rebuilding the whole raid, however lvm does.


3

Okay, clearly one of your disks is not active in the array right now. Let's say, under the current enumeration, that /dev/md0 is missing /dev/sdb1. To add /dev/sdb1 back in its former state: mdadm -a --re-add /dev/md0 /dev/sdb1 You may want to re-check the array to make sure the data is all consistent. echo check >>/sys/block/md0/md/sync_action ...


3

To my surprise, I was/am able to recover the data by simply using foremost. The help received here was invaluable. After trying a variety of suggested combinations, as well as my own mix-ins, the ideal method (to mount and use the disk as normal) didn't seem like an option any more. Resorting to data recovery is my solution in this case.


3

If you have configured your RAID-1 to use a bitmap (see man page) then --re-add is a lot faster because just the areas written after the connection breaking have to be written. In any way (even without a bitmap an full synchronization) you can more easily than with dd configure the sync speed via /sys/block/md0/md/sync_speed_* Synchronization with dd would ...


3

If it's RAID 1, and if you know the data offset (e.g. 2048 sectors, you can usually find out the exact data offset by mdadm --examine /dev/sdb1), then you can create a read-only (to be safe) loop device like so: # losetup --find --show --read-only --offset $((2048*512)) /dev/sdb1 /dev/loop7 And then try to check then mount the printed loop device: # ...


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

Putting your zpool as files on an existing file system means you're relying on that file system to provide consistency (which sounds dangerous at best) and also that ZFS can't take good advantage of caching. I'm not sure how well ZFS would handle the transfer from files to physical devices; the file system itself probably wouldn't have any real complaints, ...


3

If the bitmap has not changed when the old disk was replaced by the new one, it should work to mark the disk as failed and remove it from the array. mdadm -f /dev/md0 /dev/sda1 mdadm -r /dev/md0 /dev/sda1 Then replace the disk and add the old one to the array: mdadm --add /dev/md0 /dev/sde1 I think that shutting down the machine and replacing the disks ...


3

If you're using LVM for the primary partition you can always add another disk to the pool and then extend into it. Given you're using CentOS I would assume that the system was setup so that you have an LVM partition providing your storage and then their are logical volumes coming from LVM for /home and /. Example Here on this CentOS 6.x system I have the ...



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