[mythtv] AutoExpire carnage due to correctly ageing automount
Andrew Meredith
andrew at anvil.org
Sat Mar 18 13:53:31 UTC 2006
Hi Folks,
I posted to the mythtv-users list on the 16th March about a problem I am
having with autoexpire. I had this problem before and simply stopped
using the feature. This has in turn led to other problems due to the
disk filling up :)
I have attached a simple and benign patch that will block the issue but
would like to expand on the logic behind it.
I have two mythbackend server machines and a number of clients, all
using FC3 or FC4 on 32 bit Intel/AMD hardware. The two servers share the
same 100GB disk volume using autofs. I have now realised that it is
autofs that is at the heart of the problem.
The database element RecordFilePrefix is set to "/vols/mythtv-rec" in
both cases. In both cases "/vols" is the automount point. In both cases
the mount is to "coliseum:/export/mythtv-rec" with the --ghost option
set in auto.master. However, on coliseum (one of the two mythbackend
machines) this reverts to a bind mount. On zebedee, (the other
mythbackend machine) the mount is a standard NFS based automount.
Using the automounter provides a degree of resilience to the system such
that if the network funks out or the server is rebooted, the slave
server can recover without itself needing any actions taken. This
approach works fine if no programs are set to autoexpire and has been
doing so for well over a year.
The issue seems to kick off if the automount ages out. If there is no
recording or playback activity on the slave backend for more than the
time-out period, the automount does and should age out. Given that
--ghost flag is set, the directory /vols/mythtv-rec is always present,
irrespective of whether the mount is active or not. If the statfs test
is run on /vols/mythtv-rec under this condition, the result returned is
as follows:
f_type = 391
f_bsize = 4096
f_blocks = 0
f_bfree = 0
f_bavail = 0
f_files = 0
f_ffree = 0
f_fsid = 0
f_namelen = 255
However, if the statfs is run on /vols/mythtv-rec/. ie it encourages the
automount to become active, the result is (currently)
f_type = 26985
f_bsize = 32768
f_blocks = 3276480
f_bfree = 751436
f_bavail = 751436
f_files = 96185600
f_ffree = 96185462
f_fsid = 0
f_namelen = 255
Please note that this behaviour is perfectly correct. Please also note
that the mythbackend will then try to resolve the perceived 'disk full'
condition by deleting the oldest member of the autoexpire queue. As the
deletion requires access to the filesystem proper, the automount
activates and the deletion completes.
For perspective, the result when the same tool is run on the file server is:
f_type = 1481003842
f_bsize = 4096
f_blocks = 26211840
f_bfree = 6011484
f_bavail = 6011484
f_files = 96185600
f_ffree = 96185462
f_fsid = 64768
f_namelen = 255
(Please note that the f_fsid is different, so the "delete programs"
screen will be fooled into thinking these are two separate disks. Not
sure how to get round this other than some kind of additional flag.)
The above is one possible scenario, but others may exist. The purpose of
the patch is to guard against the times when the statfs call returns
f_blocks = 0. Plainly the user would/could not create a filesystem with
a total space of zero and even if they did, it could not store anything,
so the autoexpire could not delete anything. Either way, if f_blocks = 0
no further action should be taken.
I would suspect that a stale NFS mount would return a similar result,
but have yet to prove this.
Could I please urge the developers to include this patch or equivalent
for those of us trying to use autofs. Without it, autoexpire is like
playing russian roulette with 5/6 chambers loaded :)
Having puzzled about the random disappearance of apparently recorded
programs long and hard until I made the link with autoexpire, it would
also be very useful indeed if the non verbose logging included a line of
output naming the program deleted under autoexpire. Without this there
is no clue as to where it went.
Thanks
Andy M
-------------- next part --------------
A non-text attachment was scrubbed...
Name: util.cpp.patch
Type: text/x-patch
Size: 413 bytes
Desc: not available
Url : http://mythtv.org/pipermail/mythtv-dev/attachments/20060318/f294d408/attachment.bin
More information about the mythtv-dev
mailing list