May 27, 201214 yr With the drop in price of SSD using SSD as a cache drive is even more viable. Obviously SSD can be used this now but without EXT4 there is no TRIM and I am not sure if the current alignment code is optimized for SSD. So I am proposing: EXT4 with TRIM support EXT4 choice for cache drive Alignment if necessary Likely a tick box that says SSD that automatically uses these settings would be the most convenient route.
May 27, 201214 yr Are there any thoughts about using an SSD as a block cache drive as opposed to a filesystem-based cache drive (like ZFS supports and BTRFS is going to be supporting soon) ? Obviously 5.1.... 5.5.... 6.0 type stuff, not 5.0 It'd just be nice to be able to put in a fast device and have things go faster without worrying about space for said cache device.
May 30, 201214 yr You would still be limited by your network. Assuming you're running a GbE network, that's 125 Mb/s max. And it's very unlikely you'll reach that speed anyway, even with a SSD. Speed is an issue for me as well and I'm seriously considering going for a dedicated 10GbE link between my workstation and my server. As for future unRAID devs, I think a native link aggregation is much more useful. My 2 ct though...
May 30, 201214 yr It not only what's coming over the wire to the cache drive. Ex. Sab DL to the cache drive over the wire Handbrake encodes running, iso's unpacking. Fixing a DL with quickpar, remuxing a few mkv's, watching a recent DL, deleted BR iso's after unpack, etc all this happening at the same time. I have personally brought my cache drive to a turtles pace, were you could see I/O waits. So an SSD would be very welcomed. Not large enought yet, unless there was a way to have several under raid 0 as one cache drive.
May 30, 201214 yr Author It would also be a big boost for things like XBMC central art cache where there are hundreds of thousands of small files. As madburg points out its not only about throughput over the wire.
May 31, 201214 yr Or make the coffee and brush your teeth... Just kidding. Good points. I'm not using any of those applications so I somehow missed the point.
May 31, 201214 yr It would also be a big boost for things like XBMC central art cache where there are hundreds of thousands of small files. As madburg points out its not only about throughput over the wire. Sorry could you clarify this? Would you need to create a hidden directory on the cache drive and specify with XBMC where the art cache is stored or would XBMC benefit natively?
June 6, 201214 yr I think this is a really good idea. SSD's become cheaper every day, and for me it would be great to have my MediaPortal Artwork Cache and SQLite DB's on that cache drive so every HTPC could access it. Btw. that maybe a dumb question, but till now i dont use any cache drive. Is a share on a cache drive already possible today? And would that share also be protected by unRaid. In my opinion this shar would be out of the Array, and so not protected, what wouldn't be a problem for me in this case.
June 6, 201214 yr Yes. No. The contents of the cache drive are not part of the array and thus are not protected.
June 6, 201214 yr I think this is a really good idea. SSD's become cheaper every day, and for me it would be great to have my MediaPortal Artwork Cache and SQLite DB's on that cache drive so every HTPC could access it. Btw. that maybe a dumb question, but till now i dont use any cache drive. Is a share on a cache drive already possible today? And would that share also be protected by unRaid. In my opinion this shar would be out of the Array, and so not protected, what wouldn't be a problem for me in this case. Data on the cache drive will not be protected by the array however could be protected independently if you were to use hardware RAID1 (two mirrored drives acting as a single cache drive). The unRAID wiki explains a couple of ways you can use the cache drive for other purposes, based on how the mover operates: Link: http://lime-technology.com/wiki/index.php/Cache_disk#The_Mover - The mover will not move any top-level directories which begin with a '.' character. Such directories will not exist in normal use, but an advanced user may use this knowledge to create directories which won't get moved. - The mover will not move any files that exist in the root of the cache disk. Such files will not exist in normal use, but an advanced user may use this knowledge to create files which won't get moved (for example, a swap file). If you created a folder on the cache drive called ".stuff" then this folder would never be moved to the array by the mover and could be used to store metadata. Alternatively any files stored directly on the cache drive (not in folders) will also not be touched by the mover.
June 6, 201214 yr No need anymore to use a leading "." in 5.0 (since beta 8 iirc). When you create a share you can designate it right from the GUI as "cache only"
June 6, 201214 yr That sound good. By the way it would be possible to write a shell script which could run every now and then compress the data and copy it to the array. So also the data on the cache drive would atleast be backed up. I mean for the data i would store there, that would be safe enough.
June 6, 201214 yr HA, I was going to add that but didn't bother. Why even bother compressing, just use rsync ... unless you were looking to just keep snapshots. Otherwise I can't imagine the compression itself is that important, or even effective for pix/vid
June 20, 201214 yr Slightly related ... anyone have thoughts about my other thread here: http://lime-technology.com/forum/index.php?topic=20931.0
Archived
This topic is now archived and is closed to further replies.