Hi - is there a way of keeping the contents of a share on either the cache or an SSD whilst it's still part of the protected array (ie, probably duplicated)?

 

I'll explain what I'm aiming for and somebody might be able to offer a solution...

 

I basically want my music folder to be available immediately.  That is, if Plex/Squeezebox/client etc., wants to play music then there is no spin up delay.  I could always put it all on one drive that never spins down, but I'd rather it be a low power SSD like the cache I have.  I still want the share to be protected.

 

Any ideas?

Not currently supported, but being discussed by community members.  Accelerator Drives.

 

edit: fixed link

I have 2 x 120GB SSD in btrfs raid1 cache pool. Files on my cache pool are not protected by parity but they do have reduncancy from btrfs raid1.

 

In addition to my appdata, I also have Music and Pictures shares as cache-only. That way any of the computers or other devices on my network can easily access those shares without spinning anything up.

 

The Music is just mp3. Other devices on my network play these files, including my Squeezebox alarm clock. I don't want a drive spinning for this. I also sync this share to my phone. I have my lossless music collection on another share in the parity array.

 

The Pictures are just jpg. Other computers on the network use these for wallpaper and screensaver slideshow so I don't want a drive spinning for this. The original raw files are on my wife's computer, and also backed up to a share in the parity array.

 

Getting files from lossless or raw to those cache-only shares is done totally manually. I don't really want all of the raw photos or all of the lossless music constantly available anyway.

 

Thanks guys - great information

 

Of course, yes, I could easily create some cache only shares and duplicate the data manually for now.  I'm guessing it wouldn't be too difficult to schedule a sync (although it's no hardship to copy twice.  Most of my music is in MP3 (haven't got around to redoing it in FLAC, although some is), so it's no big deal.  I have three squeezeboxes, one of them being the alarm clock, that don't really need to spin anything up.  Wish you could still get them, great things.

 

Like the idea of raiding the cache too.  I've likely got the hardware spare on my mobo with a bit of rejigging to do that.

 

@tdallen - the link didn't work I'm afraid

I'm guessing that in theory one could add an SSD drive to the array and set relevant shares to only use it, whilst all other shares to ignore it.  That would leave data in a protected state and give instant access to data.  The only things I've read so far suggest that this should theoretically work though.

Lime Tech recommends against using SSDs in the main array, AFAIK. I don't know the reasoning behind this however.

Lime Tech recommends against using SSDs in the main array, AFAIK. I don't know the reasoning behind this however.

I understand there could be a technicality with using it to rebuild the array in the event of a drive failure, but that's pretty much where my understanding starts and ends.  I'll read more though.

Lime Tech recommends against using SSDs in the main array, AFAIK. I don't know the reasoning behind this however.

I think the recommendation has evolved to "use at your own risk". Software trim is disabled for array drives, but there is some uncertainty about how SSD firmware trim and garbage collection might play with parity.

 

Some users have tried it and reported no problems, and it does seem to make sense that SSD manufacturers wouldn't want to break parity for the many different raid implementations out there.

 

In any case, if you just want redundancy of some SSD storage, btrfs raid1 is the official method. And unless you are planning for a complete SSD parity array write performance benefits of SSD would be lost due to parity disk speed.

 

In any case, if you just want redundancy of some SSD storage, btrfs raid1 is the official method. And unless you are planning for a complete SSD parity array write performance benefits of SSD would be lost due to parity disk speed.

I'm only thinking about read performance, which parity wouldn't affect, no?

 

But yes, I get the point about RAID storage outside of the array.

btrfs Raid 1 on the cache is all very well, but I've yet to actually read an official procedure for how to replace one of the drives should the worst happen. The UnRaid manual appears to have a hole with regards to this. I'm guessing it's not as easy as pulling the drive out and shoving a new one in like you would do with traditional Raid.

btrfs Raid 1 on the cache is all very well, but I've yet to actually read an official procedure for how to replace one of the drives should the worst happen. The UnRaid manual appears to have a hole with regards to this. I'm guessing it's not as easy as pulling the drive out and shoving a new one in like you would do with traditional Raid.

johnnie.black has posted about this. Here's one

btrfs Raid 1 on the cache is all very well, but I've yet to actually read an official procedure for how to replace one of the drives should the worst happen. The UnRaid manual appears to have a hole with regards to this. I'm guessing it's not as easy as pulling the drive out and shoving a new one in like you would do with traditional Raid.

johnnie.black has posted about this. Here's one

 

Excellent, thanks for that. Apparently it IS almost as simple as I said.