1

I have a Synology NAS (DS416play running DSM 6.2) configured as SHR with 1 drive redundancy.

One of the drives has been flagged as failing but is not yet showing any kind of errors. I could simply pull it out and insert a new one but, from past experience, I'd then have perhaps a week of no redundancy during data scrubbing.

The NAS has USB so I wonder: could I temporarily attach a new drive externally and "pre-clone" onto it somehow in order to minimise the amount of time with no redundancy?

In case it is relevant, the new drive is different/larger (8TB vs 6TB).

2
  • Be careful to make sure that the new drive does not use SMR, which has proven troublesome for NAS devices. Commented Jul 13, 2022 at 18:27
  • Thanks, yes I won't be buying more WD since their shenanigans with Red (I narrowly avoided ending up with an SMR a couple of years ago but managed to cancel the order). I'm slowly replacing with Toshiba N300. They do run several degrees hotter but they also don't cost as much...
    – jhnc
    Commented Jul 13, 2022 at 21:30

2 Answers 2

1

As an alternative option, temporary changing some parameters can drastically speed up the raid expansion in some cases (for example, from 10 days to 16 hours).

You can use cat /proc/mdstat and mdadm --detail /dev/mdX to find the raid device you are expanding. Often it is md2, while other are ~2GB mirrored system partitions.

Write down current values first to restore them later.

$ cat /sys/block/md2/md/stripe_cache_size
$ cat /proc/sys/dev/raid/speed_limit_min
$ cat /sys/block/md2/queue/read_ahead_kb
$ cat /sys/block/md2/md/sync_max

$ echo 32768 > /sys/block/md2/md/stripe_cache_size
$ echo 50000 > /proc/sys/dev/raid/speed_limit_min
$ echo 32768 > /sys/block/md2/queue/read_ahead_kb
$ echo max   > /sys/block/md2/md/sync_max

stripe_cache_size is the max value, and it takes up 32Mib to synchronize read/write operations while the array is degraded.

speed_limit_min is a hint that you want more focus on the sync-expansion task. It also exists as a GUI option in DSM 6 and 7.

read_ahead_kb is how far ahead of a read request the drive array will preload.

sync_max is the numbers of sectors that indicate a range within the array where check/repair will operate (there is also a sync_min). This one seems to give the most impact for some.

Sources:

3
  • thanks, although this doesn't address my question (method to clone disk without degrading the array at all, rather than how to minimise rebuild time after degrading it), your answer may help others. I guess it should be all disks not just md2? sync_max=max is the default now and my speed_limit_min=300000. Is such a large read_ahead_kb useful (eg. my max_sectors_kb is 512 and the default read_ahead_kb is different for each of my disk models)?
    – jhnc
    Commented Oct 4, 2023 at 2:51
  • I couldn't find an easy way to pre-clone the drive myself, so this was the next viable option. I was surprised with the results it had in the gist and its comments, but did not try it myself yet. My example was taken from a raid5 configuration, where md2 was the actual raid5 that was expanding, while md0 and md1 were ~2GB system partitions, so configuring them too is most likely unnecessary. Commented Oct 4, 2023 at 11:45
  • In theory, large read_ahead_kb can be useful, since it increases read-speed for workloads where you're scanning most of the drive. But I did not see cases of it being used and measured by itself during the expansion, so it might be a case of "trying a bit everything". Commented Oct 4, 2023 at 11:45
0

DSM 7 adds a "replace drive" feature.

If I had a spare drive bay, this would do what I asked for.

Sadly, it doesn't appear to work with a USB-attached disk.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .