Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: MythTV: Users

Unionfs [was: Multiple Directories for Recordings]

 

 

MythTV users RSS feed   Index | Next | Previous | View Threaded


mythtv-users at phipps-hutton

Sep 22, 2006, 2:31 AM

Post #1 of 2 (558 views)
Permalink
Unionfs [was: Multiple Directories for Recordings]

On Friday 22 September 2006 07:52, Lincoln Dale wrote:
> [.i wasn't subscribed to mythtv-users but saw this thread in the mailing
> list archives. hence reviving a 2 week old thread :)]
> > was wondering if it is possible to spread TV show recordings across
> > multiple directories or disks rather than a single directory.
> if you're prepared to run a SVN-head tree or patch MythTV, YES, this is
> possible. i've been running a multiple-directories-recording patch now for
> over 5 months.
> the plan is for this to be (hopefully) incorporated into myth 0.21.

I've been playing with unionfs as a way of merging multiple directories into
one. It's available in Debian testing in the unionfs-modules-2.6.17-2-686
package now that 2.6.17 is the kernel.

root[at]hal:/tmp# mount -t unionfs -o dirs=/myth:/home unionfs store
root[at]hal:/tmp# df -h
Filesystem Size Used Avail Use% Mounted on
rootfs 9.9G 3.7G 5.8G 40% /
udev 1.0G 2.5M 1022M 1% /dev
/dev/hda2 9.9G 3.7G 5.8G 40% /
/dev/hda3 214G 170G 42G 81% /home
/dev/hdd1 111G 88G 23G 80% /myth
unionfs 324G 257G 65G 80% /dev/shm/tmp/store

The advantages would be:
*) Works with unpatched MythTV.
*) Losing a disk will just lose the recordings on that disk.
*) Migration from the original single disk doesn't require reformatting the
original disk.

But these things stop me using it:
*) All new files get put in the first writeable branch.
*) I don't know what happens when the first branch fills up (autoexpire won't
help if other branches have space).
*) Can't move files from one branch to another without unmounting the union.
That requires shutting down all of Myth.
*) Deletion only supports "whiteout" mode so you end up with a .wh file for
every file ever created. Not sustainable.

I might try it out with the first branch being what was the original store and
the other branches being directories with old "precious" recordings in
loopback filesystems sized to be 100% full and autoexpire turned off for
those recordings. My worry is that autoexpire will get it wrong and either
delete too much or too little (Prime directive: never lose a Coronation
Street episode).

Cheers,
Tim.
_______________________________________________
mythtv-users mailing list
mythtv-users[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


ltd at interlink

Sep 22, 2006, 3:02 AM

Post #2 of 2 (495 views)
Permalink
Re: Unionfs [was: Multiple Directories for Recordings] [In reply to]

> I've been playing with unionfs as a way of merging multiple directories
> into
> one. It's available in Debian testing in the unionfs-modules-2.6.17-2-686
> package now that 2.6.17 is the kernel.

unionfs has been around for a while. while i haven't tracked linux-kernel
recently, it was previously in a state where linux-vfs folks wouldn't accept
it..

> The advantages would be:
> *) Works with unpatched MythTV.

well - not as if patching mythtv is hard. :)
i run all sorts of custom patches anyhow.

> *) Losing a disk will just lose the recordings on that disk.

the patch in trac ticket #1744 also means this.

> *) Migration from the original single disk doesn't require reformatting
> the > original disk.

neither does the patch in trac ticket #1744

> But these things stop me using it:
> *) All new files get put in the first writeable branch.

the trac patch in ticket #1744 will write across all directories.

> *) I don't know what happens when the first branch fills up (autoexpire
> won't help if other branches have space).

the trac patch in ticket #1744 won't break auto-expire.

> *) Can't move files from one branch to another without unmounting the
> union.
> That requires shutting down all of Myth.

no shutdown of myth is necessary. the only clueful thing is to avoid moving
a file as it is being written to or read from.. not exactly too hard..

> *) Deletion only supports "whiteout" mode so you end up with a .wh file
> for every file ever created. Not sustainable.

sounds like you _should_ be running my patch. :)

> root[at]hal:/tmp# df -h
> Filesystem Size Used Avail Use% Mounted on
[..]
> unionfs 324G 257G 65G 80% /dev/shm/tmp/store

well - here i just have RecordFilePrefix set to
/media1,/media2,/media3,/media4,/media5:

# df -k
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/hdc1 307663800 256848532 50815268 84% /media1
/dev/hda5 159963408 18832852 141130556 12% /media2
/dev/hdb1 192292124 182551740 9740384 95% /media3
/dev/sda1 292994784 243960524 49034260 84% /media4
/dev/sdb1 292994784 243565088 49429696 84% /media5


cheers,

lincoln.

_______________________________________________
mythtv-users mailing list
mythtv-users[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

MythTV users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact lists@gossamer-threads.com
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.