[GLLUG] Link two RAIDs in one LVM?

Dr. Axel Stammler axst at users.sourceforge.net
Sat May 9 11:03:47 UTC 2020


Thank you for your detailed look at possible setups. I remembered my old setup incorrectly, though, so that I am not sure everything is applicable. My original (2016) setup included two hard disk drives of not 4 TB but 8 TB capacity in a RAID-1 that has reached 92 per cent capacity.

On Tue 2020-04-28 13.19.10, James Courtier-Dutton wrote:

>First for RAID, avoid SMR HDDs. (Shingled magnetic recording)
>I would probably RAID 5 them.
>4+4 = 8 for the first disk, against the two other 8 disks.
>So, say disks are A(4TB), B(4TB), C(8TB), D(8TB)
>Partitions the 8TB in half.
>A(4TB), B(4TB), C1(4TB), C2(4TB), D1(4TB), D2(4TB)
>RAID 5: A,C1,D1
>RAID 5: B,C2,D2
>Then put the two RAID arrays in the same LVM VG, so that they look
>like one big disk for the OS.
>Another alternative is using XFS or BTRFS and configure them with replicas.
>That is where the filesystem does the replication, thus not needing RAID at all.

As 8 TB hard drives still seem to be the best value for money per TB, I have ordered two more, making sure they use perpendicular magnetic recording. The existing drives look fine both in SMART logs and tests (I even have a 1 TB from 2009 in perfect working order, cannot imagine how.), so my first idea was to create a new RAID-1 and to combine the two resulting systems via Logical Volume Management. What do you think?

>Or, you could take the approach I take. I remove the old 4TB disks and
>only copy the few files I need on to the 8TB disks going forward.
>I can always plug the old 4TB disks in if I need an old file.
>I have written my own indexer for this. It scans the whole disk,
>creating an index and thumbnails and then only store the index and
>thumbnails on the 8TB disks.
>The index is stored in Elastic Search, so makes it easy to find the
>files again, and also which disk they are on.
>So, files I hardly ever need are stored on powered off disks.

Unfortunately, in my case, I cannot tell which data are going to be needed more often or sooner.

Kind regards,

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mailman.lug.org.uk/pipermail/gllug/attachments/20200509/6f808b77/attachment.sig>

More information about the GLLUG mailing list