Feature #5334
Storage Management
0%
Description
Currently, there is no storage management. Storage locations are set individual in recording profiles and the "storage space" info in the webif is pretty much useless if you have multiple profiles using multiple locations. Having some storage management in one central location storage can be managed much easier/better. For instance, a tab where admins can select a default storage location and multiple other possible locations. Then the recording profiles can either use the default, or select one of the alternate locations. Optionally, a user "with permission" could override and specify a full path if desired.
Possibilities:
Admins could specify alternate locations if default location becomes full.
Admins could implement storage quotas for users, but still allow them to create their own recording profiles.
Storage quotas could still be implemented for individual profiles.
Admins/users could quickly see through the webif storage space used and available.
Possibly each storage location could show "read only" information about which recording profiles are using it and possibly how much space each profile is using.
Admins could be emailed if storage becomes full.
Timeshift location(s) could also be managed.
Individual users could be restricted to certain locations.
Considering that recordings take gigabytes/terabytes of disk space, proactive management seems appropriate.
I know there is this wiki, but there is no space to discuss actual implementation.
[[https://tvheadend.org/projects/tvheadend/wiki/Tvheadend_recording_management]]
Would also be related to recording management:
[[https://tvheadend.org/issues/3763]]
History
Updated by
Updated by Hanspeter Müller about 6 years ago
Updated by IMHO, this is a more complex "dupe" of https://tvheadend.org/issues/3506
"Sure, you can do this with https://romanrm.net/mhddfs (which transparently stores complete files distributed on multiple disks, wherever there's room) or any kind of real RAID, but IMHO it does not belong on application level..."
and even if someone would implement it on application level, how would you ie represent the free space, if there are exeptions for every user, with fallback exeptions on full user storage etc. At some point you need storage for recordings, and the application should not have to bother with a thousand rules...
My 2 cents (before trump taxbreak).
/hp
Updated by Joe User about 6 years ago
Updated by Disk management and storage management are different things. Why is it so strange for an application to manage where it stores its data??? Just because management "could" get very complicated if you want to "micro" manage it, does not mean you should not even begin to try...
Updated by Mark Clarkstone about 6 years ago
Updated by Tvheadend should try to record and if the disk gets full it should fail. Which I think is what it does now. With an option somewhere - of what to do when "no space" - to keep or delete the failed recording.
Management of the space IMO shouldn't be up to Tvheadend but the host machine.
Updated by Em Smith about 6 years ago
Updated by Some filesystems (like zfs) support most of the features built-in.
So you create a filesystem "recordings", then sub-filesystems of "alice", "bob", "eve", and can set individual quotas for each of the filesystems, and have instantaneous details of how much they are using (no need to traverse filesystem with du). You can even create sub-sub-filesystems, such as alice/tvmovies and alice/tvshows and have separate quotas.
I know btrfs was heading towards those features, but last time I looked there were far too many caveats.
The idea of allowing directories to be only selected from a pre-defined list sounds good.
Updated by Em Smith about 6 years ago
I've no problems with new features since I guess many people use low-spec devices and probably only have ext4 or even exfat for their recordings, so don't have access to modern fs features. But, it might end up that btrfs gets decent quota support (is it available on the Pi?) making the changes less useful long-term?