Re: RAID-1 and disk I/O
On 7/18/21 2:29 PM, Urs Thuermann wrote:
David Christensen <dpchrist@holgerdanske.com> writes:
You should consider upgrading to Debian 10 -- more people run that and
you will get better support.
It's on my TODO list. As well as upgrading the very old hardware.
Currently, it's a Gigabyte P35-DS3L with an Intel Core2Duo E8400 CPU
and 8 GB RAM. It's only my private home server and performance is
still sufficient but I hope to reduce power consumption considerably.
I ran Debian on desktop hardware as a SOHO server for many years, but
grew concerned about bit rot. So, I migrated to low-end enterprise
hardware and FreeBSD with ZFS. The various SATA battles made things
tougher than they should have been, but I fixed several problems and
everything is now stable.
# diff -U20 <(smartctl -x /dev/sda) <(smartctl -x /dev/sdb)
Why limit unified context to 20 lines? You may be missing information
(I have not counted the differences, below). I suggest '-U' alone.
20 lines are just enough to get all. You can see this because there
are less than 20 context lines at the beginning and end of the diff
and only one hunk. GNU diff doesn't allow -U without a line count.
Sorry -- I do not use the -U option and misread the diff(1) man page.
Yes, the old Gigabyte mainboard has only 3 Gbps ports. I wasn't aware
of this but have just looked up the specs.
SATA2 should be plenty for Seagate ST2000DM001 drives. Two PCIe x1
SATA3 HBA's or one PCIe x2+ SATA3 HBA might improve performance slightly
under specific workloads, but I would just stay with motherboard SATA2
ports (unless you find problems with them).
And the server is about 8 years old, initially with only 1 hard drive
which crashed while my backup was too small to hold everything. This
meant a lot of work (and quite some money) to get everything running
again and to recover data which wasn't in the backup.
I think we have all been burned by trying to "make do" with inadequate
backup devices. I threw money at the problem after my last significant
data loss, and now have backups several drives deep. The funny thing
is: when you're prepared, the gremlins know it and stay away. ;-)
The smartctl(8) RAW_VALUE column is tough to read. Sometimes it looks
like an integer. Other times, it looks like a bitmap or big-endian/
little-endian mix-up. The VALUE column is easier. Both 119 and 117
are greater than 100, so I would not worry.
Hm, in some cases the RAW_VALUE looked somehow "more readable, and the
VALUE looked suspicous to me. And here I found the explanation in the
smartctl(8) man page:
Each Attribute has a "Raw" value, printed under the heading
"RAW_VALUE", and a "Normalized" value printed under the
heading "VALUE".
[...]
Each vendor uses their own algorithm to convert this "Raw"
value to a "Normalized" value in the range from 1 to 254.
[...]
So to summarize: the Raw Attribute values are the ones that
might have a real physical interpretation, such as
"Temperature Celsius", "Hours", or "Start-Stop Cycles".
Thank you for the clarification. As usual, I am guilty of inadequate
RTFM...
Thanks for all your answers, hints, suggestions. With that, and
reading the man page more carefully (mostly motivate by your and
other's answers) I learned quite a lot new about SMART and how to
use/read it.
YW. I am learning too.
David
Reply to: