Re: Suggestions for building new 44TB Raid5 array

[Zygo Blaxell <ce3g8jdj@umail.furryterror.org>]

On Mon, Jun 13, 2022 at 10:46:40AM -0700, Marc MERLIN wrote:
> On Mon, Jun 13, 2022 at 02:21:07AM +0500, Roman Mamedov wrote:
> > On Sat, 11 Jun 2022 07:52:59 -0700
> > Marc MERLIN <marc@merlins.org> wrote:
> > 
> > > On Sat, Jun 11, 2022 at 02:30:33PM +0500, Roman Mamedov wrote:
> > > > > 2) echo 0fb96f02-d8da-45ce-aba7-070a1a8420e3 >  /sys/block/bcache64/bcache/attach 
> > > > >    gargamel:/dev# cat /sys/block/md7/bcache/cache_mode
> > > > >    [writethrough] writeback writearound none
> > > > 
> > > > Maybe try LVM Cache this time?
> > >  
> > > Hard to know either way, trading one layer for another, and LVM has
> > > always seemed heavier
> > 
> > I'd suggest to put the LUKS volume onto an LV still (in case you don't), so you
> > can add and remove cache just to see how it works; unlike with bcache, an LVM
> > cache can be added to an existing LV and then removed without a trace, all
> > without having to displace 44 TB of data for that.
> 
> Thanks. I've always felt that LVM was heavyweight and required extra
> steps and tools, so I've been avoiding it, but maybe that wasn't
> rational.
> bcache by the way, you can set it up without a backing device and then
> use it normally without the cache layer. I think it's actually pretty
> similar, but you have to set it up beforehand (just like LVM)

You can trivially convert from lvmcache to plain LV on the fly.  It's a
pretty essential capability for long-term maintenance, since you can't
move or resize the LV while it's cached.

If you have a LV and you want it to be cached with bcache, you can hack
up the LVM configuration after the fact with https://github.com/g2p/blocks


> Marc
> -- 
> "A mouse is a device used to point at the xterm you want to type in" - A.S.R.
>  
> Home page: http://marc.merlins.org/                       | PGP 7F55D5F27AAF9D08
>