NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Beating a dead horse

    Date:        Mon, 23 Nov 2015 11:18:48 -0553.75
    From:        "William A. Mahaffey III" <>
    Message-ID:  <>

Much of what you wanted to know has been answered already I think, but
not everything, so....

(in a different order than they were in your message)

  | Also, why did my fdisk 
  | choose those values when his chose apparently better ones ?

There's a size threshold - drives smaller get the offfset 63 stuff,
and drives larger, 2048 ... the assumption is that on small drives
you don't want to waste too much space, but on big ones a couple of
thousand sectors is really irrelevant...

I suspect the threshold is somewhere between your 1TB and the other 2TB

  | If so, is there any way to redo that w/o a complete reinstall :-) ?

Since you're using raid, there is, but it would take forever, so you may
not want to do it...   The upside is that the correction would just
slow down your system slightly, leaving it operational the whole time.

I suspect you're not going to want to bother, so I won't give all the
steps, but the basic strategy would be to use your spare disc - stop that
being a spare for now, and repartition it the way that you want all of the
drives partitioned.  Then add that back as a hot spare for the raid array.
Then use raidctl to "fail" one of the other drives - raidframe will then
reconstruct the "failed" drive onto the hot spare (the one that is now
correctly divided up).   Once that process finishes, the one that was failed
is no longer in use, and can be repartitioned.   Do that, then add it as a
hot spare, and then fail another of the drives.   Repeat until done...

Expect the whole process to take a week (not continuously, but you're
only likely to do one drive a day, once the reconstruct starts you'll
just leave it to work, and go do other stuff - on that system or whatever).
Actual human time would be about 10 minutes per drive.

If it was me, I wouldn't even think to look see if it was finished till
the next day...

Doing a complete reinstall of everything would probably be done in a
few hours, so ...

Note that none of this is relevant unless you really decide that it
is needed, and you work out first exactly what all the numbers should
be.   Also note that (ab)using raidframe this way wiil only fix the
alignment of the raid arrays, if any of the raidframe params ought to be
altered, or the filesystem(s) built on the raid array, then that method
won't help at all, and starting again is definitely the best option (and
doing that before you get too invested in data on all those TBs)

  | The machine works well except for horribly slow I/O to the RAID5 I setup 

What is your definition of "horribly slow" and are we talking read or write or
both ?

Raid5 is not intended to be fast, it never will be - for writes, it should
be reasonable for read.

What really matters is not some random benchmark result (my filesystem is
faster than yours...) but whether it actually gets your workload done
well enough or not - I have used raid5 for home filesystems, and pkgsrc
distfiles, and other stuff like that (mostly read, occasionally write)
and have never even wondered about its speed - that's all simply irrelvant.
I use raid1 for filesystems with lots of writes (/usr/obj, ...) where
I want write speed to be good.

  | Partitions aligned to 2048 sector boundaries, offset 2048 <------ *DING 
  | DING DING* !!!!

Note that that "2048" is an internal fdisk default, for how it will
help you align stuff.  Of itself, it doesn't mean anything to partitions
that have been made.   And:

  | When I used fdisk to check my drives (well, 1 of them, all are 
  | identically fdisk-ed & sliced), I see the following:

  | Partition table:
  | 0: NetBSD (sysid 169)
  |      start 2048, size 1953523120 (953869 MB, Cyls 0/32/33-121601/80/63), 

What really counts there is the "start 2048".   That's what you want.
2048 is a nice multiple of 8 ...   1953523120 is also a multiple of 8,
so everything there should be nicely setup for 4K blocks.  What the
default alignment were to be if you were to change things, is irrelevant.

That is, there is absolutely no need to repartition the drives, the current 
layout is fine, and is not the problem (if there even really is a problem).

So, now if your I/O really is slower than it should be, and slower than
raidframe's raid5 can reasonably be expected to achieve, I think the issue
must be with either the raidframe or ffs parameters.

Those you haven't given (here anyway, I don't remember from when this
discussion was going on earlier.)

What is your raidframe layout, and what are your ffs parameters?


Home | Main Index | Thread Index | Old Index