Mailinglist Archive: opensuse (982 mails)

< Previous Next >
[opensuse] Re: Hard Disk Upgrades
Greg Freemyer wrote:
On Wed, Sep 10, 2014 at 5:56 PM, Paul Groves <paul.groves.787@xxxxxxxxx> wrote:
I have no clue what to do for the RAID. My MoBo supports RAID, should I use
this functionality or set up a software RAID with opensuse?

That's the first thing you need to decide.

Is your MoBo raid real hardware raid or fake raid?

http://serverfault.com/questions/9244/how-do-i-differentiate-fake-raid-from-real-raid

If fake raid, I would ONLY use it if I needed to be windows
compatible. ie. You need to setup a dual boot windows/opensuse setup.
----
I disagree, *depending* on what type of RAID you want.
If you want RAID0 or RAID1, my experience with BIOS raid for those 2 types
is that is more versatile, reliable and software transparent. Since you want RAID1, assuming you are talking SATA or SAS, both
disks can be written-to at the same time by the controller and it will look like a single disk to windows and linux (and any other OS).

I've seen and had linux SW RAID5 (as well as HW), and with the same
power and software interruptions, the SWRAID was more vulnerable to hard
corruptions. W/SW RAID, you can't have a battery-backed up ram that will
write to the disk when the OS comes up -- because the memory will be purged.

As for the new disks... 1. Do them 1 at a time.
Since you are going for different hard disks you would want
to use a full disk backup and restore so the new disks
will have a minimal amount of fragmentation.

*IF*, you are using xfs...you can use xfs_dump+xfs_restore
to dupe a hard disk (won't make it bootable, but for data
it's fine). (don't use the xfs_copy routine, as that is basically
like a "dd" but doesn't dup the diskid (i.e. no defrag or
"relayout).

A trivial script that should hit ~ 75% of disk throughput is
one I use w/xfs (I called it xfscopy). If you don't use
xfs you might be able to adopt the concepts to your fs's
similar dump/restore util...

Need to be root or have unimpeded sudo access.
It does some runtime io & cpu prioritizing to optimize things.
Just added a few runtime checks - args, privs.. but the
rest I've used for ages...

#xfscopy---
#!/bin/bash -u
# trival fulldisk copy using xfs_{dump,restore} & mbuffer - lwalsh
# sets cpu and iopriorities to optimize copy speed
# $1=source
# $2=target

# ensure enough args
if (($#!=2)) ; then
echo "xfscopy needs source and target mount points"
exit 1
fi
PATH="/usr/sbin:/sbin:/usr/bin:/bin:$PATH" #ensure util paths are first

# ensure privs (root or sudo)
export sudo="$(type -P sudo)"
function sudo {
if (($(id -u))); then
[[ ! $sudo ]] && return 1
$sudo -n -- "$@"
else
exec "$@"
fi
}
export -f sudo

read uid < <(sudo id -u)
if [[ $uid != 0 ]]; then echo "Must have admin privs"; exit 1; fi


# xfsdump ops:
# -b = blocksize
# -l = level (0=all)
# -J = inhibit inventory update
# -p = progress report every # seconds
# next to last arg is '-' for stdout/in & out
# last arg is for source or destination mount points

mbuffer_size=1024M
xfs_bs=128k
xfs_report_interval=300

# setting restore proc's cpu+disk io "higher" than "dump"s helps
# prevent filling memory and thrashing
# prios c:1=real(don't use), 2=best-effort(timeshare); 3=idle
# in Best effort, -n=0-7 where 0=highest, 7=lowest, but not strict!

dump_cprio=-19
restore_cprio=-5

dump_dprio="-c3"
restore_dprio="-c 2 -n3"

#construct command for echo & running
cmd=" nice $dump_cprio ionice $dump_dprio \
xfsdump -b $xfs_bs -l 0 -p $xfs_report_interval -J - $1 |
nice -1 mbuffer -m $mbuffer_size -L |
nice $restore_cprio ionice $restore_dprio \
xfsrestore -b $xfs_bs -B -F -J - $2"

echo $cmd

sudo bash --norc -c "$cmd"

#end xfscopy



--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups