Announcement

**Snowhog** · Dec 18, 2024, 08:12 AM

Originally posted by jfabernathy View Post

Thoughts??

"IF it ain't broke, DON'T fix it."

Sorry. Couldn't resist.

**jfabernathy** · Dec 18, 2024, 08:19 AM

Originally posted by Snowhog View Post

"IF it ain't broke, DON'T fix it."

Sorry. Couldn't resist.

It's been 3 years and It's killing me not to be "improving" it. I do need more TV storage and un-RAID-ing those drives helps big time.

**Snowhog** · Dec 18, 2024, 08:37 AM

My quip was speaking to:

Originally posted by jfabernathy View Post

I've had people comment in the past that BTRFS should not be used for media stream recording, but I've had 000.000 problems in 3 years so I don't know where that was coming from.

As I have zero experience/knowledge on/of what you have been doing with your setup using BTRFS, I'll defer to the experienced among us: oshunluvr

**oshunluvr** · Dec 18, 2024, 12:35 PM

IMO you really don't need BTRFS unless you're going to use at least some the advanced features. So unless you use snapshots, backups via send|receive, or RAID/JOBD then EXT4 or XFS may be a better option. I haven't "studied" the speed comparisons between them lately but historically EXT4 could be tuned for slightly better performance than BTRFS and XFS has better parallel operation speed and handles large files very well. I know some of the newer compression settings for BTRFS have drastically improved it's performance over the last couple years so that may no longer be an issue and there's the added benefit of extra storage

LVM could be used instead of BTRFS for JBOD if you decide on EXT4/XFS you're stil good-to-go.

Here, my media server uses BTRFS exclusively and has for many years. Currently media on 3 HDs - 22,16,6 TB with the 22 as the storage and 16+6 as backup. I did have a backup drive fail a few months back but it was an easy hot swap replacement and a couple days of re-aligning the subvolumes because the drive that failed was a 10TB and the 22TB replaced it. I was at about 80% capacity when the backup drive failed. Ubuntu server is on an SSD so the platter drives are media only. BTRFS fits my needs and is so easy to use it feels like cheating.

Back to your use-case, you said: Redundancy/backup not needed, increased space desirable, recording live videos the main use. My choices:

LVM+XFS. XFS supports parallel operations better than most which means recording a show while watching another or multiple simultaneous recordings should work well. The biggest deficit to LVM+XFS would be 1 fail = 100% data loss. Less important, you cannot shrink an XFS file system but you can expand it.

BTRFS - with the caveat that you would want to test the multiple thread streaming performance - is the easiest choice. Another advantage is adding or subtracting disks without taking down the server.

I think the main unanswered question is performance of the file system itself regarding the planned usage. If BTRFS is on par, or at least good enough, performance wise vs. XFS , I'd stick to BTRFS.

**jfabernathy** · Dec 18, 2024, 01:59 PM

Thanks, oshunluvr. I don't think performance is a problem. On my present Core i5 backend that does the recording, I can record 4 HD (1080i,720p) shows at the same time while it streams 2 previously recorded shows to 2 different TVs with FireTV sticks. So my new configuration would be the same as my past but without the RAID1 mirror. I'd just be a JBOD if I stick with BTRFS. I'm still looking into EXT4, so something like /mnt/recordings1 and /mnt/recordings2. By added those 2 directories to MythTV's recordings Storage Group, it will ping pong simultaneous shows to different directories if you have them.

If I have shows that I want to keep in an archive, I edit out the commercials and compress from MPEG2, the original recording format, to MP4 (x264) and put on a NAS where it's backed up there and in the cloud.

**jfabernathy** · Dec 19, 2024, 08:21 PM

So I've been building up test systems to test some of these concepts and I had an issue with having large number of GBs of recordings that had been deleted but I was not freeing up space. I examined what I had done I have questions and maybe some answers.

When you install mythtv on a system you need a directory to store recordings. My test system was a single 1TB SSD with 2 btrfs subvolumes, @ and @home. So Timeshift can work with this. Since I created my recording directory as /mythtv I think that it is a part of the @ subvolume. So if a snapshot was taken prior to deleting a bunch of recording, the disk space not going down may be caused by this snapshot. I'm thinking I should have created a @mythtv subvolume and mounted /mythtv to that. That would eliminate any snapshots of mythtv recordings.

Does this sound right?

**oshunluvr** · 2024-12-20T16:36:12

If I read you correctly, yes. A snapshot would retain all data that the source subvolume contained, and will actually grow the amount of space used as more changes are made to the source.

If your goal is to NOT snapshot the /mythtv at all then yes, using a subvolume instead of a folder within @ will prevent all that data from being part of the @ snapshot. A nested subvolume is not included in a snapshot of the host subvolume. So if @mythtv is mounted at @/mythtv it will not be included in a snapshot of @.

If you want to keep space usage at a minimum while still retaining snapshots, take the snapshots more often and remove the older ones immediately.

**jfabernathy** · 2024-12-20T18:40:28

Thanks for the confirmation. I must have totally spaced out when I didn't create the @mythtv subvolume when I first built the system.

So what about the case when you have a second btrfs drive with no subvolumes on it, and you mount it at /data. My experience tells me that drive will not be included in the snapshot taken of @/.

**oshunluvr** · 2024-12-20T22:03:07

Let's find out... BRB

**jfabernathy** · 2024-12-20T22:13:17

I just looked into my timeshift snapshots that are done daily. the one for today shows nothing in the /data directory under the @ subvol snapshot, but on the drive that's mounted on /data there's 600GB.

So I think other BTRFS drives mounted on a / level directory are considered like a nested subvol and not snapshotted.

**oshunluvr** · 2024-12-20T22:31:04

OK, so I:

Created a new btrfs on a partition
mounted it at /mnt/test
created some files in it
made a new subvol on /mnt/backup called @testsub
made a folder in @testsub called testmnt
bind mounted /mnt/test at /mnt/backup/@teststub/testmnt
ls showed the files that are on /mnt/test
took a snapshot of /mnt/backup/@testsub

The snapshot contain the folder testmnt but it was empty. /mnt/test still showed it's folders.

I then:

unmounted all that and remounted the test partition directly to /mnt/backup/@testsub/testmnt
ls revealed the files I had previously made
took a snapshot of @testsub again

Results were the same - no files in /mnt/backup/@testsub/testmnt in the snapshot

Conclusion: Any nested BTRFS file system will not be included in a snapshot of the host BTRFS fs/subvol.

**claydoh** · 2024-12-21T01:45:47

Note that Timeshift will only snapshot @ and @home (if configured to ) so the new @mythtv won't be included.
I am sure this is already known or been mentioned.
In this case, Btrfs Assistant may be a useful replacement for Timeshift.
it is now available in the standard repos for 24.10 and up

Announcement

BTRFS and video recordings

BTRFS and video recordings

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment