vinski
-
Posts
5 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by vinski
-
-
Clear and neat anwsers : thank you so much
-
7 minutes ago, johnnie.black said:
Yes, you could just run the array with one disabled disk, second parity would protect you from another failure or you could manually unassign the second parity and assign it to the failed disk slot and rebuild.
I noted the remotely operated "manual" process of
- unassignment of second parity
- assignment of this disk to the failed slot
Can this process be automated on unRAID ?
-
Thanks so much for your detailed answer.
To summerize the drive error management on unRAID with btrfs data drives :
- electrical, mechanical, electronical data/parity drive failures are detected and logged by unRAID : drive to be replaced
- limited bitrod error transparently corrected by drive firmware ECC
- heavy bitrod error, leading to read error, corrected by unRAID with parity rebuilt, which then try to write the data onto the failed drive
just logged as error if write completes, or disk is disalbled and emulated by unRAID until replaced
- btrfs metadata checksum error corrected by btrfs (default) metadata DUP attribute
- btrfs data checksum error (without data DUP) : error indicated and logged during scrub, data copy is prevented, backup process necessary
One more question regarding unRAID+btrfs :
> is to possible to run a double parity array and to use the second parity drive to fix any failed drive ( ideally remotely until the failed drive is actually replaced) :
- either use the second parity drive as a replacement data drive
- keep the remaining parity drive in case of failed parity drive
Is this a manual process ? can it be automated on unRAID ?
-
I am considering complementing my old Synology NAS with a dedicated archive server and this topic deals with the core issue regarding using unRAID : providing a storage suitable to write-once-read-rarely archives with both disk-level checksum scurb and failure parachute with parity.
I would consequently appreciate the expertise from johnnie.black or other mature members regarding my newbie questions :
> Is unRAID able to manage simultaneously on a unique system two arrays, each consisting in n disks + parity ?
> are the disks data displayed on unRAID frontpage logged or loggable on a regular basis, including disk spun-off status ?
> considering btrfs on each data disks, how do btrfs an unRAID manage a checksum error detected on either metadata or data : is the issue autohealed with parity disk ? is the issue logged in details ?
> read/write errors on disks managing SMART, pending and reallocated sectors , with or without TLER settings :
- whatever the data file system/s is/are, how does unRAID manage the parity computing / checking when facing a read/write error on a data disk ? on a parity disk ?
- considering btrfs on each data disk, does unRAID and/or btrfs manage the failed disk and the disks array after a read/write error is detected on one of the data disk ?
I would greatly appreciate your detailed anwsers
unraid-tunables-tester.sh - A New Utility to Optimize unRAID md_* Tunables
in User Customizations
Posted
Dear Pail
I am considering using UnRAID for a large archive (write once, read rarely) system, typically 15-25 drives per server. I already clarified with Johnnie.black the failure management for any kind of failure on unRAID+btrfs system with single and dual parity. I am now considering the power and thermal aspect and as you mentionned you worked out on the Staggered Spin-up (SSU) matter, I dare contact you straight forward :
The core idea with SSU is to level in time the peak load at drive spin-up and this basically can be driven by the drives and/or the OS.
The normal use of unRAID within an archive system is to deal with one drive at a time (+parity/ies during write).
Question 1 : Hows does unRAID cover corectly this matter at the system start-up and mount : all drives remains off until a read or write request is send?
or do all the driveshave to be spun-up at the array mount ? Which are the parameters for unRAID ? for each drive ?
The worse case scenario for SSU is then in case a parity check or drive failure :
Question 2 : How does unRAID deals with SSU in case of parity check with all drives in operation
Questions 3 : in the case of single parity :
- with parity drive failure : please confirm only the data drive is then spun-up on read/write request
- with data drive failure : please confirm all data and parity drives are spun-up considering SSU on read/write request
Questions 4 : in the case of dual parity :
- with one parity drive failure : please confirm only the data drive (+ remaining parity drive for write) is then spun-up on read/write request
- with single data drive failure : please confirm all data and parity drives are spun-up considering SSU on read/write request
Your detailed experience is much appreciated
vinski