Tag Info

New answers tagged

0

Typically you install a specific controller tools such as LSI's MegaCLI in your case (just google it, LSI's download site is ... peculiar), and then a generic server monitoring system such as Nagios, Icinga, Zabbix, ... which in turn includes plugins that regularly check your controller using MegaCLI. The Icinga and Nagios exchange sites show numerous ...


5

Yes, sdb3 is available for you to use as you wish. In your example the MD devices would probably be md0 and md1 rather than md0p1 and md0p2.


1

If you're using metadata 1.2 (4K from the start), maybe there's old filesystem metadata in those 4K that aren't used by mdadm. You could zero those: dd bs=4k count=1 if=/dev/zero of=/dev/sde1 And see if that gets rid of the offending message. In the future use wipefs on a partition before using that partition for anything else (mdadm, pvcreate, mkfs, ...


0

Turns out there was a cron job running sync; every 60 seconds. It was producing so many zombie processes, that it was slowing down the RAID array to a crawl. Moral of the story: check your cron jobs.


2

My answer has 2 parts: investigation of the block device driver; an optimisation worth looking at with your use case. Investigation of Hardware I understood that for the same application but on 2 different hardware the performance is very different and you would like to understand why. Therefore I propose first a mean to help you find an answer for the ...


0

jbd2 process is for ext4 journalling. It is logical that filesystem needs to write into journal during mysql commits, this should not be reason for any worries. The amount of load caused by jbd is influenced by your mount parameters for dm-10-8 and dm-14-8 partitions. It is probably desirable to have very conservatiove journalling at database partition to ...


2

I speak about Linux sofware RAID. When you look into the code, you see the md driver is not fully optimized: when multiple contiguous requests are made, the md driver doesn't merge then into a bigger one. This lead to massive overhead in some common situations. Big reads or writes are optimized: they are cut down to several requests egal to the stripe ...


1

In the mdadm.conf you only need the UUID, like so ARRAY /dev/md0 UUID=d8b8b4e5:e47b2e45:2093cd36:f654020d All other conditions can prevent the RAID from being assembled. For (deprecated) auto assembly, you need: partition type fd metadata 0.90 either no initramfs at all, or make sure the initramfs does raidautorun /dev/disk If auto assembly fails, ...


1

Two issues spring to mind You've got duplicate array definitions in mdadm.conf. Replace (or comment out) the block of three lines following # definitions of existing MD arrays so that each array is declared by your most recent scan. A typical scenario for RAID arrays that fail to build on boot is that either they have not been updated in the initramfs or ...


0

As with all things, there's a happy medium. But I would suggest have a look at RAID2 and RAID3 - both types that are rarely used - to get an understanding of the nature of the problem. However it's basically boils down to latency of IO and concurrent data transfer. Every read IO operation has an overhead of several milliseconds for the heads to seek and the ...


3

As far as I know the issue has never been to do with head movements and all simply due to more overheads. For a given sequential read or write a 4KB stripe size results in sixteen times more operations than a 64KB stripe size. More CPU time, more memory bandwidth, more context switches, more I/Os, more work for the kernel I/O scheduler, more merges to ...


1

Mount /dev/md2 first as something like /srv/DataNew, run a 1st round of copy as root (actually I'd suggest rsync, IMHO it's better for this kind of job): rsync -a --delete /srv/Data/ /srv/DataNew Optionally you can re-run the cmd - the 2nd execution should be faster (rsync is capable of skipping files already copied and up2date) and will give you a rough ...


1

In a word, yes. More specifically, you need to mount the new array somewhere else ( can't mount two things in the same place ), copy the files, unmount both, then set your system to mount the new raid in that location ( edit /etc/fstab ).


0

You don't actually need to partition a drive if you want to add it in its entirety to a RAID device; you can specify the whole device (/dev/disk/by-uuid/...) as a component for mdadm. If you still want to use a partition, run wipefs -a on the device, and create the partition with a recent version of cfdisk or parted; they will do the right thing as far as ...


0

Depends what was on it. If it was LUKS encrypted, the LUKS header is gone and so is your data (unless it is still in luksOpened state in which case you should grab the output of dmsetup table --showkeys). Unencrypted, photorec might carve some things for you. It finds unfragmented files of known types, not just photos. If there were partitions that ...


1

Your new disk is a little over 1MB smaller than the existing one. This may be a different model (despite having the same identification, it might have been manufactured in a different factory, to slightly different specifications), or it might have a few more defective sectors noticed during the factory tests. On sdb, you have a partition sdb1 which spans ...


-1

Simply create a partition on sdc identical to sdb I know this trick(first make a backup and avoid partition span outside the disk,for example,2 disk 220G sdb 210G sdc,make two partitions under 210G,maybe two identical partition of 199G in this case) sfdisk -d /dev/sdb > part_table sfdisk /dev/sdc < part_table And then retry to add sdc1


4

976766976 from /dev/sdb is smaller than 976771072 from /dev/sdc. It's not an identical drive.


1

Stephen Kitt already answered your question properly, but since you mentioned 'constraints of using software RAID', there is one other issue that can waste a bit of space and that's the size of the RAID metadata. In theory RAID metadata is really small, a few kilobytes at most. In practice mdadm reserves quite a lot of space for its metadata. In your case ...


1

There are a couple of reasons for the confusion here. SSD drives are often advertised as "raw" capacity, which includes all the overprovisioning for faulty sectors. So a 64GB device might actually have only 60GB usable space. Disks are specified in 10^n units, so 64GB is (64*10^9) bytes. Memory and computer users' frequent expectations are based around 2^m ...


4

Your drives aren't set up entirely as RAID10 devices. Each of your four drives is partitioned into three partitions, one containing approximately 16.8GB (I'm using SI GBs here), one containing 524MB, and one containing 45.7GB. The set of four 16.8GB partitions is assembled into md1, a 16.8GB RAID1 device (md1: active raid1; all four partitions are mirrored, ...



Top 50 recent answers are included