It should be noted that mythtv is a badly behaved IO application, it does a lot of sync calls that effectively for the most part makes linux's write cache small. That code was apparently done on the idea that the syncs would take too long when too many recordings were being done and a few would timeout and then kill a few of them so that at least some recordings will work. A number of people believe its usage of sync is badly designed (me included) but last a saw the dev's were arguing for it. It is a decent assumption if recordings we being done on a single spinning disk, but it is not so good when there are multiple spindles under it and the disks would be able to cache up. I had recordings being killed when a single spinning disk in the array with the SCTERC set to 7seconds happened, and that is part of the reason why I went to SSD. With old disks the disk block replacements is going to happen often enough that with the sync/kill crap recordings aren't reliable. On Mon, Sep 14, 2020 at 9:37 AM Ram Ramesh <rramesh2400@xxxxxxxxx> wrote: > > On 9/14/20 6:40 AM, Nix wrote: > > On 1 Sep 2020, Ram Ramesh uttered the following: > > > >> After thinking through this, I really like the idea of simply > >> recording programs to SSD and move one file at a time based on some > >> aging algorithms of my own. I will move files back and forth as needed > >> during overnight hours creating my own caching effect. > > I don't really see the benefit here for a mythtv installation in > > particular. I/O patterns for large media are extremely non-seeky: even > > with multiple live recordings at once, an HDD would easily be able to > > keep up since it'd only have to seek a few times per 30s period given > > the size of most plausible write caches. > > > > In general, doing the hierarchical storage thing is useful if you have > > stuff you will almost never access that you can keep on slower media > > (or, in this case, stuff whose access patterns are non-seeky that you > > can keep on media with a high seek time). But in this case, that would > > be 'all of it'. Even if it weren't, by-hand copying won't deal with the > > thing you really need to keep on fast-seek media: metadata. You can't > > build your own filesystem with metadata on SSD and data on non-SSD this > > way! But both LVM caching and bcache do exactly that. > Agreed, all I need is a file level LRU caching effect. All recently > accessed/created files in SSD and the ones untouched for a while in > spinning disks. I was trying to get this done using a block level > caching methods which is too complicated for the purpose. > > My aim is not to improve the performance, instead improve on power. I > want my raid disks to be mostly sitting idle holding files and spin up > and serve only when called for. Most of the time, I am > watching/recording recent shows/programs or popular movies and typically > that is about 200-400GB of storage. With ultraviolet, prime, netflix and > disney, movies are more often sourced from online content and TV shows > get deleted after watching and new ones gets added in that space. So, > typical usage seem ideal for popular SSD size (with a large backup store > in spinning disk), I think. This means my spinning disks are going to > wake up once a day or two at most. More often I expect it to be once a > week or have periods of high activity and die down to nothing for a > while. Instead, currently they are running 24x7 which does not make sense. > > Regards > Ramesh >
